Webinar to discover the CAFCR model through an everyday system challenge
On July 7 ’26, 2 PM – 3 PM, High Tech Institute organizes a webinar on “Thinking in CAFCR – From Chaos to Clarity“. The webinar will be presented by Ger Schoeber, an experienced trainer within our Systems Architect(ing) courses.
We’ve all been there: you walk into a meeting room, laptop under your arm, and the next ten minutes are a frustrating puzzle of cables, adapters, and settings — while your audience waits.
But what if this everyday problem could teach you a powerful way of thinking about system challenges?
In this hands-on 30-minute workshop, we use the surprisingly rich case of connecting a laptop to a screen or projector to explore the CAFCR model* — a structured approach to understanding and designing systems from multiple perspectives.
You will discover how a simple question like “why won’t my screen work?” touches on business goals, user needs, functional requirements, technical architecture, and infrastructure — all at once.
A practical, recognizable case that everyone has lived through
An interactive introduction to the CAFCR model
Immediate insight into how the model applies to your own work
A few surprises along the way
No prior knowledge required. Just bring your curiosity — and maybe your adapter.
Target audience The CAFCR model is especially valuable for professionals involved in designing, developing, and managing complex systems and products. It helps align customer needs, business goals, and technical solutions across different abstraction levels.
Typical users include:
Systems architects
Systems engineers
Product managers
R&D managers
Technical project leaders
Software and hardware architects
Innovation managers
Multidisciplinary engineering teams
The model is particularly useful in high-tech industries such as semiconductors, automotive, healthcare, aerospace, and industrial automation, where complex systems require strong communication between stakeholders and engineering disciplines.
Presenter Ger Schoeber has built an extensive career in software development, systems engineering, and systems architecting, holding leading and innovation-focused positions at companies including Philips, ASML, Lightyear, and Vanderlande. In addition to his industrial career, he is internationally active as a trainer in Systems Architect(ing) and Systems Thinking through High Tech Institute and previously served as president of INCOSE NL.
INCOSE NL was founded in 1996 by 25 engineers who believed complex systems needed a discipline of their own. Thirty years and nearly 500 members later, technical director Bart van Luling and chairman Bas Leijser take stock — of what SE has become, where it still falls short, and why the next two days in November might matter more than any event in the organization’s history.
In November, the High Tech Institute will co-organize the Dutch Systems Engineering Days — the largest SE gathering in the Netherlands to date, and the centrepiece of INCOSE NL’s 30th anniversary. To understand what that milestone actually represents, we spoke with technical director Bart van Luling and chairman Bas Leijser across a range of questions: the discipline’s origins, its spread into new sectors, the honest reckoning with AI, and what Dutch industry still consistently underestimates. Their answers are reproduced here in full.
Why SE needed its own organisation
INCOSE NL started in 1996 with 25 people in a country that already had a strong engineering culture. Looking back, why did it take a separate organisation to make Systems Engineering happen here?
Bas Leijser
I can mainly speak for the past decade, but one thing is clear, regardless of when you joined: Systems Engineering seldom emerges organically, even in strong engineering cultures.
SE requires deliberate effort and coordination, rooted in common practices and a shared language. That’s precisely where an organization like INCOSE NL is essential. We provide that foundation and, in addition, serve as a neutral platform connecting industry, government, and academia.
Our network member meetings, workshops, and now the Dutch SE Days facilitate knowledge sharing and networking. Our INCOSE handbook, the work of our Special Interest Groups and international Working Groups, and our certifications together form the backbone of SE practice and professional recognition, ensuring that the discipline grows into something shared and sustained across the field.
The discipline’s evolution
Systems Engineering was originally developed in defense and aerospace, yet INCOSE NL has always attracted members from public infrastructure, process industry, and the high-tech sector. Thirty years on — how would you describe the place Systems Engineering holds in the Netherlands today?
Bart van Luling
SE by now has a strong foundation in multiple sectors. In the 2000s, SE was implemented broadly in the Dutch infrastructure and civil engineering sector and evolved to standardized ways of working for the major public employers like Rijkswaterstaat, ProRail, multiple provinces, municipalities, and water authorities — and the big contractors and engineering companies. In past years, within the energy sector, multiple organisations like TSO TenneT, DSOs Alliander, Stedin, and Enexis have been implementing SE following the trend in infrastructure. Recently there have been first steps within the health sector and urban area development. The SE community is significantly growing across multiple sectors.
Bas Leijser
Systems Engineering in the Netherlands has evolved well beyond its roots in defense and aerospace. We now see strong adoption across energy, infrastructure, and high-tech, and are expanding into new territory like healthcare, driven by a growing recognition that complexity is increasing across all sectors, and that SE plays a key role in managing it.
But perhaps the more interesting evolution is in how people identify with the discipline. Not everyone calls themselves a systems engineer, but more and more people recognize themselves as system thinkers, integrators, system architects, and so on. The boundaries of who “belongs” in SE are widening, and we welcome that at INCOSE NL. The discipline is finding people as much as people are finding the discipline.
The membership curve — and what drove it
Membership grew from 25 at the start to 100 in 1999, 270 in 2005, and over 350 by 2021 — now exceeding 400. Are there moments in that curve that stand out as genuinely pivotal?
Bart van Luling
The growth in the period between 1999 and 2005 resonates directly with the introduction of SE in the civil engineering sector. Since joining as technical director in 2023, our strategy has focused on attracting younger engineers and reaching new sectors — and that paid off. The community is still growing in numbers, in the range of sectors involved, and with younger members.
Bas Leijser
As of March 2026, we had over 490 members and expect to surpass 500 this year.
On the growth itself, the honest answer is that there’s no single pivotal moment. It’s more of a combination of inflection points. What we see is a gradual but accelerating shift in how organisations perceive SE. It used to be something almost niche, but now we see people from a much wider range of sectors and roles joining.
The underlying drivers are clear: systems are becoming more software-intensive, more interconnected, more complex. AI adds another layer of uncertainty on top of that. Better MBSE tooling has lowered the barrier to applying SE in practice, which brings in people who might have found it inaccessible before. The net effect is that SE has shifted from a ‘nice to have’ to something organisations increasingly treat as a prerequisite. That’s what the membership curve reflects as well.
'SE has shifted from a 'nice to have' to something organisations increasingly treat as a prerequisite.'
AI meets SE — including what doesn’t work
One of your recent member events focused on “AI meets Systems Engineering — what works, what doesn’t, and what’s coming.” That framing — acknowledging what doesn’t work — is refreshingly honest. What have been the genuinely disappointing early experiences?
Bart van Luling
For me, there is no disappointment. Results with the use of AI for systems engineering are very promising. But it’s all about expectations. If people expect AI to take over their SE tasks just like that, they come home empty-handed. There is a lot of thinking, experience, and creativity needed in applying systems engineering for complex assignments. AI can reproduce what has been done before and what’s documented, and do easy tasks much faster than people. But it cannot do that without clear instructions and without someone doing the thinking for it — at least, not yet. Just uploading a bunch of SE documents and trying AI to give good advice is a bit short-sighted. We have to treat AI as a very fast-working intern with a photographic memory.
Bas Leijser
Most of the disappointing experiences turned out to be a matter of patience. I’ve had more than a dozen conversations where someone said “AI can’t do X yet” — and then six to twelve months later, that point was moot.
Of course, there are the expected technical limitations, like hallucinations or AI struggling with more complex tasks.
But the toughest disappointment is on the human side: coming to terms with the fact that AI can be genuinely capable, and that the real challenge is adapting ourselves. The disappointment isn’t in AI failing but in AI succeeding, and realizing that many things we thought only we could do with our expertise turned out to be perfectly manageable by AI — with a little guidance. Accepting that and learning to work with it can turn that disappointment into excitement, but that’s not a one-time shift; it’s a continuous process.
'The disappointment isn't in AI failing but in AI succeeding — and realizing that many things we thought only we could do turned out to be perfectly manageable by AI, with a little guidance.'
From document to model
Your MBSE Special Interest Group has been active for years. How far along is Dutch industry actually in making that shift in practice, and where do you still see the biggest barriers?
Bart van Luling
There is not one answer to this question — it differs a lot per sector. In high tech and automotive, MBSE is well developed and broadly applied. In infrastructure and civil engineering it’s still in its infancy, but first steps are being made, for example in the Dutch national standard for tunnel systems. In the energy sector there is a big transition ongoing from a document-based way of working to a data-centric approach, but I personally haven’t seen real MBSE examples yet. I do believe Dutch industry is a bit behind on MBSE developments compared to other countries.
Bas Leijser
The shift from document-based to model-based working is less of a technical challenge and more of a change management and people challenge. It requires a fundamental mindset change. We often hear at INCOSE events that we should get better at social sciences, because that’s really what drives adoption.
As for maturity across Dutch industry, it’s uneven. Some organisations have embedded MBSE and are quite far along. Others are still finding their way — it can genuinely be a multi-year process to get from document-heavy practices to capturing requirements in a structured database.
Across the board, the biggest barriers are not the tools themselves, but adoption at scale: aligning stakeholders, integrating MBSE into existing processes, and making the value visible early enough to sustain the transition.
The Dutch SE Days — who should be in the room
The Dutch Systems Engineering Days in November are shaping up to be the biggest SE gathering in the Netherlands in years. What are you most excited about — and who should be there?
Bart van Luling
I’m especially excited that we are bringing sectors together to learn and get inspired by each other’s SE experiences. We need to share knowledge to bring SE to the next level in the Netherlands. Also, I really like that we have a student track to stimulate our young and new professionals to share their thoughts and research on systems engineering. My personal ambition is to get more young professionals involved in INCOSE, so all the experienced systems engineers with grey hair can transfer their knowledge to the SE community of the future — but also to include new fresh ideas from our younger colleagues. We can all learn from each other.
Bas Leijser
What excites me most is that this is our first two-day event. That extra day changes the dynamic. It creates space not just for more presentations and workshops, but also for more informal interactions. We’ve seen at international INCOSE events that this is often where the most valuable insights emerge — or just plain having fun, which matters too. INCOSE NL is also a community after all.
As for who should be there: I often say that many people are already practising systems engineering, or following SE principles, without identifying themselves as such. So almost anyone is welcome: engineers, architects, managers, policymakers, and anyone dealing with uncertainty, integration, or complexity. Whether you work in healthcare, infrastructure, high-tech, defence, or finance, there’s value here for you.
Why a New Space engineer and a sustainability professor share a stage
The event features keynotes from a New Space startup engineer and a sustainability transitions professor on the same stage. What’s the argument for that combination — and what are you hoping actually happens in the room?
Bas Leijser
Sustainability and space exploration are more complementary than they might appear. Space exploration has driven technologies we now rely on for sustainability — solar panels being one example, in terms of scale and efficiency.
The AI and sustainability combination is another example. We know the energy and water footprint of data centres is significant, but AI also has enormous potential in tackling sustainability challenges. That tension is worth exploring.
More fundamentally, SE is not sector-specific, and one of the things I value most about INCOSE is that it bridges sectors and lets them learn from each other. Defence can learn from how healthcare approaches systems engineering, and vice versa. The same core challenges exist across all of them. What we’re aiming for is that people step outside their own domain and get inspired, or inspire others.
Bart van Luling
Sustainability is one of our biggest societal challenges. It’s INCOSE’s vision to apply SE to solving our societal challenges — not only technical ones. Jan Rotmans’ keynote will be very interesting to follow from a systems engineering perspective. The keynote from Jon Reijneveld will show how The Exploration Company applied SE to their own company growth — another perspective on systems engineering beyond the common technical approach. Both keynotes will be refreshing and also thought-provoking about our daily challenges. I’m really looking forward to them and the audience’s response.
“What we’re aiming for is that people step outside their own domain and get inspired, or inspire others.” — Bas Leijser
The next 30 years — what Dutch industry still gets wrong
The Netherlands faces some of the most complex systems challenges in the world — water management, energy transition, semiconductor supply chains, defence modernisation. What is the single most important thing Dutch industry and government still consistently underestimate?
Bart van Luling
That’s really about applying systems thinking to our big societal challenges. We still approach them as single manageable assignments — but they’re not. Everything is connected and the world is getting more complex. Systems thinking will be an indispensable competence to get anything done in the future.
Bas Leijser
The core underestimation is twofold. First, we underestimate how non-unique our problems are. There’s a persistent tendency to treat complex systems as utterly unique, leading to excessive customisation and reinvention. In reality, we can often lean far more on existing reference architectures and proven approaches than we do.
Second, we underestimate the value of critical early-phase activities, and chronically underinvest in them — particularly validation, simulation, and modularisation. Validation is often grouped with verification as “V&V,” but in practice only the verification gets done. Modularisation is essential to managing complexity by breaking a system into manageable pieces. And on simulation: at the last INCOSE International Symposium, even an astronaut wondered aloud why non-space projects don’t simulate more, compared to how rigorously they simulate before every mission. They have a point.
'Everything is connected and the world is getting more complex. Systems thinking will be an indispensable competence to get anything done in the future.'
About the Dutch Systems Engineering Days 2026
On 12 & 13 November 2026, INCOSE NL will host the Dutch Systems Engineering Days at Van der Valk Eindhoven-Best. This two-day event marks the 30th anniversary of INCOSE NL and is the largest systems engineering gathering the Netherlands has seen.
The programme includes keynotes by Jon Reijneveld (The Exploration Company) and Jan Rotmans (Professor of Sustainability and Transitions), alongside sector tracks covering High-Tech, Defence, Energy, Infrastructure, AI & Systems Engineering, Sustainability, SE Fundamentals, and a dedicated Student Track.
Contributions are still open. You can submit yours via EasyChair.
High Tech Institute and INCOSE NL
The High Tech Institute is a proud partner of INCOSE NL. Many of our systems engineering training courses are INCOSE-certified, meaning participants can earn internationally recognised INCOSE credits as part of their professional development.
Unambiguous requirements are important for successful validation, but they’re difficult to establish in practice. By more clearly defining, structuring, and tracing the development process of a system, many problems at a later stage can be prevented, TMC’s Bart van Liere learned at the System Requirements Engineering training from High Tech Institute.
When a surgical robot needs to place a suture at the microscale, the functional requirement seems clear: position and move with an accuracy of a few tens of micrometers. But when the type of tissue the suture should be placed in has not been specified, this immediately creates room for interpretation. Soft tissue requires a different force buildup than rigid or fibrous material, which affects both the required actuation and the choice of suture material. During validation, it turns out that a specification that looks correct on paper has been designed in practice with assumptions that were not made explicit anywhere.
‘Meeting the requirement’ is what Bart van Liere, Integration Engineer at TMC, seconded to MTA, deals with on a daily basis. He is at the back end of the development process, where he needs to demonstrate that a system does what it was designed to do. “During validation, we find out if a requirement is formulated too vaguely, a restraint has remained implicit or stakeholders have not been able to properly convey what they had in mind for the same ‘functional’ goal.”
Integrator
After completing his bachelor’s degree in mechatronics, Van Liere went on to obtain a master’s degree in AI for Engineering Systems at Eindhoven University of Technology. He is now active as an Integration Engineer through TMC. TMC deploys technically trained professionals, so-called ’employeneurs’, on a wide range of projects at various high-tech clients.
'We learned that clearly and unambiguously formulating the requirements starts with asking the right questions.'
At MTA, he’s currently involved in a project for Microsure, centered on a surgical robot that has to operate with an accuracy of 50 micrometers. In his role as a system integrator, he forms the link between design and practice. He works with engineers on the technical implementation and with stakeholders on translating requirements into concrete specifications and validation criteria.
Van Liere is no stranger to the role. Previously, he co-founded his own company, in which a drone was developed for deployment in high-risk areas. “In that process, we noticed how important it is to get a clear picture of exactly what you are trying to build right from the start,” he says. “If you miss the essence there, you will end up with an end product that does not fully meet the vision you had in mind.”
Difference in interpretation
In practice, this problem rarely arises from incompetence, but from the way in which requirements are established. A stakeholder formulates what the system must achieve, while an engineer tends to implicitly translate that into how the system could do it. These two perspectives are not automatically the same. Without an explicit definition of the primary function and the preconditions, a set of requirements emerges in which intention and implementation are intertwined. As a result, specifications appear to be comprehensive, but on closer inspection allow for multiple interpretations.
To avoid different interpretations of requirements throughout the process, a more structured approach to drawing up these requirements is necessary. This means both documenting what a system should do and keeping track of why choices are made and under what conditions they apply. To get a better grip on this, Van Liere immersed himself in the “System requirements engineering” training course at High Tech Institute, taught by Cees Michielsen.
“In this System Requirements Engineering training, we learned that clearly and unambiguously formulating the requirements starts with asking the right questions,” explains Van Liere. “What is the primary function of the system, and which constraints are decisive? Everything you then put on paper must be tested against these conditions.”
This method forces you to make sharper choices at an early stage. “Engineers tend to include everything in a brainstorming session,” Van Liere says, amused. “You end up with a list that looks complete on paper, but with little focus. Moreover, everything seems important.” By first determining what is minimally necessary for the system to do what it is supposed to do, it becomes easier to distinguish secondary matters from essential requirements and the nice-to-haves. This provides more clarity in the design phase and takes the final validation into account.
Van Liere was able to apply the method from the training directly in an ongoing project where he was involved in drawing up requirements from the validation angle. “You notice that you look at it from a different perspective,” he says. “Instead of immediately formulating demands, you first go back to the core: What are we actually trying to achieve here?” By making that step explicit, the process became more focused and the distinction between which requirements were essential and which could wait emerged more clearly. “This takes a little more time at the start, but it’s still cheaper and faster than having to modify a prototype because the requirements were not properly formulated.”
'There was enough room to go into depth and bring in your own cases. Michielsen's extensive experience meant that he was able to accommodate the diversity of input well.'
In addition to asking the right questions, trainer Michielsen also addressed recording and keeping track of changes during the development process during the System Requirement Engineering training. He cited examples from his experience at DAF and ASML, among others. “During the development process, insights can change and choices are made for particular reasons,” Van Liere points out. “However, during validation, you want to know whether an outcome is the result of a mistake or a deliberate choice during the development process.” By systematically recording changes and underlying argumentation, the development of a requirement and the basis on which decisions were made remain transparent.
Universal principles
During the training, Van Liere was joined by participants from a variety of areas, from high-tech to the energy sector. “The context differs, but the problems are the same,” he notes. “The discussions I have with my stakeholders are the same as theirs. Apparently, that’s where the challenge often lies.”
For Van Liere, the main value of the training lay in the way it structured thinking around requirements. “You learn to ask more targeted questions and to better capture what is actually meant. It is precisely this structure that helps you make more conscious choices and have sharper discussions with stakeholders.” The course reader now has a permanent place on his desk, as a reference book for moments when he wants to apply that way of thinking again.
The pace started leisurely, but then picked up quickly. “It’s a two-day training on top of your regular work, so the balance is different than for a university course. But there was enough room to go into depth and bring in your own cases. Michielsen’s extensive experience meant that he was able to accommodate the diversity of input well.” The theory was immediately tested against real cases. “You truly learn to follow the entire process, so that later you can trace back why a requirement was established and what choices were made along the way.”
This websites uses cookies to function. Additionally, we would like your consent to include cookies from third-parties. For more information on our cookies, please read our cookie statement. ACCEPT
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
