Why Further Simplifying ArchiMate? A Critical Analysis
Nicolas Figay
Model Manager | Enterprise Architecture & ArchiMate Advocate | Expert in MBSE, PLM, STEP Standards & Ontologies | Open Source Innovator(ArchiCG)
The recent ArchiMate NEXT proposals have sparked intense debate about concept deprecation and language simplification. Let's examine both sides of this argument, then look at what the numbers actually tell us.
The Case FOR Simplification
Adoption Barriers: New users are intimidated by ArchiMate's conceptual richness. The learning curve is steep, and organizations often abandon ArchiMate when faced with perceived complexity. Initial training becomes expensive and time-consuming.
The 80/20 Principle: If 80% of use cases only need 20% of the concepts, why maintain the other 80%? Standard maintenance costs are high, tools must implement rarely-used features, and certification covers concepts that practitioners seldom apply.
Semantic Clarity: Fewer concepts mean fewer difficult choices between similar elements. This reduces modeling inconsistencies and eliminates sterile debates about "which concept to use when."
Communication Focus: Forces concentration on truly important architectural distinctions, avoids over-modeling that hinders stakeholder communication, and improves model maintainability over time.
Market Alignment: BPMN succeeded without this conceptual complexity. UML showed the limits of over-comprehensive approaches. Successful standards are typically simpler and facilitate interoperability.
Economic Arguments: Simpler tools cost less to develop and maintain. Modeling projects start faster, require less training, and deliver ROI more quickly.
But Wait... Let's Look at the Numbers
Here's where the simplification argument falls apart completely:
ArchiMate is ALREADY the simplest major modeling language!
The Absurdity Revealed
We're Simplifying the Wrong Language
The irony is staggering. BPMN practitioners manage 150+ concepts perfectly well. UML users navigate 250+ concepts routinely. But somehow, enterprise architects can't handle 60 concepts?
Professional Competency Questions
If an enterprise architect cannot master 60 concepts, they're simply not qualified for the role. This is like saying a civil architect should only know 10 building materials instead of 60 to "simplify" their work.
We don't simplify medical terminology because some doctors find it complex - we ensure doctors are properly trained. The same principle should apply to enterprise architecture.
The Real Problem
The issue isn't that ArchiMate is too complex - it's that organizations hire under-qualified "enterprise architects."
Instead of dumbing down the language, we should:
The Dangerous Precedent
Reducing ArchiMate further would:
When "Philosophy" Becomes Ideology
But there's a deeper issue here. The push for extreme simplification reflects a questionable philosophical shift in how we view enterprise architecture.
The "ArchiMate Philosophy" taken to its logical extreme would eliminate ArchiMate entirely. If we consistently apply the principle that "simpler is always better" and "80% of users only need 20% of concepts," why stop at 40 concepts? Why not 20? Why not 10?
Following this logic:
This reductionist philosophy fundamentally misunderstands what modeling languages are for. They exist to enable precise expression of complex realities, not to make everyone comfortable with oversimplified abstractions.
The Consultancy Bias
Is this really about user needs, or about making ArchiMate easier to sell in short consulting engagements? A cynic might argue that simpler languages are easier to teach in 2-day workshops and require less deep expertise to deploy.
But enterprise architecture isn't meant to be a weekend hobby. It's a professional discipline dealing with inherently complex organizational and technological ecosystems.
The Real Question
Are we going to elevate the profession by developing better architects, or diminish the tools to accommodate current limitations?
ArchiMate's 60 concepts represent the minimum viable vocabulary for comprehensive enterprise architecture. Rather than reducing this further, we should focus on building the professional competency that can leverage this already-simplified language effectively.
The goal should be raising the floor of practice, not lowering the ceiling of capability.
What's your take? Should professional languages adapt to current practitioner limitations, or should we invest in developing more capable practitioners?
#ArchiMate #EnterpriseArchitecture #ModelingLanguages #ArchitectureProfession #TOGAF
Technology Lead at IAG Transform | Architecture Debt Advocate | Enterprise Architecture | Technology Architecture | SAP | Data & AI & Innovation | Digital Transformation
1dUnderstanding the core message is crucial for aligning architecture with strategic goals. How do you ensure that your architecture frameworks remain agile enough to adapt to evolving business needs?
In my side of the universe, I think many enterprise architects do not have the right tresleboard with the right set of plans. Many I know use diagramming tools instead. Many don't even know archimate exists. I was at a large company for many years, two people I met knew about archimate. The other challenge is how we present archimate to our audiences. We need to provide those viewpoints of a model in the simplest way for our audience to consume. Though something might make sense to us, we still need to make it real to others. The other thing with archimate, is that even though there exists beautiful modelling elements, these are also subject to interpretation. Also, there's a challenge with the way we name a function or a process or an event and others. Though I have a standard for these, another might have a different standard. Maybe these are some motivators for simplification. But I think it's fine the way it is. What's needed is the enterprise architects learn the language well and understand it. And most importantly, make the designs real to their audiences, with better communication (Simple and consistent viewpoints whilst using all the principles of archimate enterprise architecture), and thus maximising affinity.
System Engineer
1dThank you for the Brilliant read. You have helped pinpoint some issues clearly for me to think about. I would like to add that there is an angle not related to the modeling language itself, which they don't face for example in Business/BPMN, which is that disagreement in the community – perhaps attributed to the togaf over flexibility – about what EA is and what it should cover and how deep/detailed it should go, has natrually spilled over to the language used to describe EA.
Consumer Advocate and Author of How to Laugh at Death and Taxes: What Executors, Willmakers, Heirs and Beneficiaries Need to Know
2dI have no idea why you appeared in my feed, but your writing is so clear, what you are discussing has so much relevance to many things in life, and the cartoon is pure brilliance. Perversely in what I am working on - trying to simplify death bureaucracy for everyday people tasked with being an executor - the images would be reversed with masses of well-intentioned people led off by unintelligible legal wording into the wilderness needing someone with an enterprise architect's mind and discipline to lead them back into the light. Hmmm...