Link: https://www.eatransformation.com/p/20-years-in-enterprise-architecture
From Enterprise Architecture Transformation: A Practical Guide
I recently realized that I had quietly passed a milestone: 20 years working with enterprise architecture (EA).
The actual date was somewhere back in February. I missed it completely by several months. That tells you something about milestones in professional life—if nobody puts an alarm into the calendar, two decades can slip by without cake or speeches.
The beginning was partly accidental. I certainly did not have a master plan to build a career in EA. I barely knew what the term meant when I started. Still, that accidental start ended up determining the direction of my entire career.
Twenty years is long enough to see quite a few waves come and go. Frameworks, maturity models, service-oriented architecture, cloud, digital transformation, data, agile, AI. Architecture tools have changed. The terminology has changed. The things organizations are excited about have definitely changed.
My own view of EA has changed as well.
Early on, I was interested in how architecture should be described and how the work should be organized. Later, I became much more interested in a different question: what is all of this actually useful for?
Nowadays, I think of EA mainly as a way to understand the whole, the dependencies within it, and the impacts of change—and ultimately to help organizations make better choices about where they are going and how they get there.
The models still matter. So do methods, frameworks and tools. I use them a lot. They have just moved into their proper place.
From Research to Consulting—and From Models to Value
In early February 2006, I started working at the University of Jyväskylä in a research project focusing on EA quality management. There was just one small problem: I did not really know what EA was. Before my first day, I was given a book on EA frameworks to read. The book compared 14 different frameworks, which was quite an introduction to a subject I knew practically nothing about.
I did not let that bother me too much. I jumped straight into studying the theoretical background, collecting data from companies, and writing research papers. I was surprisingly productive, particularly when it came to writing. Looking back, perhaps that was an early indication of the writing career that would follow years later.
Our project worked closely with companies and covered topics such as EA maturity models, architectural risks, and the quality of architecture documentation. I also happened to enter the field during something of a golden age of EA enthusiasm. New frameworks, methods, and maturity models seemed to appear constantly, promising to bring order to increasingly complicated organizations and IT environments.
I found the subject interesting, but one question started to bother me. Having a mature architecture practice and high-quality documentation sounded good, but what did the organization actually gain from them? The research literature offered surprisingly few concrete answers. This eventually led me to start doctoral research on EA benefit realization.
When the research project ended, I was offered a funded PhD researcher position. Consulting seemed more interesting, so I turned it down and joined Accenture in May 2008. The PhD came with me, although completing it alongside consulting turned out to be a rather lengthy exercise.
From Models to Operating Models
My first years at Accenture were very practical. I created architecture models, collected information, interviewed people, prepared deliverables, and supported more experienced consultants in their projects. There were plenty of workshops, PowerPoint slides, and, of course, boxes and lines. Later, I also moved into more detailed application architecture and solution design, with identity and access management (IAM) becoming a new area of specialization.
It was also where I learned how different actual organizations are from the relatively tidy world of EA frameworks. Information is incomplete, responsibilities overlap, and application landscapes have often evolved through decades of local decisions and temporary solutions that somehow became permanent. Drawing an architecture model is fairly straightforward compared with understanding why things look the way they do.
In 2013, I moved to Coala, a small Finnish consultancy specializing in EA, where I eventually became a partner. My work gradually shifted toward EA governance and operating models: how architecture work should be organized, who should be responsible for what, and how EA should connect with development, portfolio management, and decision-making.
That also changed my thinking. Architecture documentation alone achieves rather little. Someone needs to use it, preferably before important decisions have already been made. Otherwise, even an excellent capability map may spend most of its life peacefully in some forgotten corner of an architecture repository.
Meanwhile, my doctoral research continued. I finally completed my PhD in 2016, almost exactly ten years after starting my EA career. The thesis examined how EA benefits emerge through architecture products, services, stakeholders, and, importantly, their actual use. In a way, it brought together my original research interests and what I had learned through consulting.
From Architecture Work to Managing Change
In 2022, I moved to CGI, where I have continued working with enterprise and solution architecture, operating models, transformation, as well as AI adoption and other practical client assignments. Over the years, my focus has increasingly moved from producing and organizing architecture toward understanding how it helps organizations plan and manage change.
These different experiences have gradually shaped my own view of EA. I see it primarily as a way to help an organization understand itself well enough to make informed decisions about change. Architecture makes structures and dependencies visible, connects different perspectives, and provides something concrete for planning and discussion. The architect’s role is as much (or even more) about bringing people together as it is about producing architecture content.
I still enjoy practical modeling work, though. Sometimes understanding an application landscape or a few important data flows is exactly what is needed.
Writing has also become an important part of my work during the past five years or so. My books and articles have given me an opportunity to develop these ideas beyond individual client assignments. Explaining something to readers forces me to organize my thoughts and occasionally reconsider things I thought I already understood. Feedback brings in perspectives I might otherwise miss.
In that sense, writing has become another way of learning about EA, alongside research and consulting. And after twenty years, there is apparently still plenty to learn.
What I Have Learned
After 20 years, a few ideas have become much more important to me than individual frameworks, tools, or modeling techniques.
1. The Main Job Is to Understand the Whole and the Change
These days, I see EA primarily as a way to understand the whole, the dependencies within it, and the impacts of change. Organizations are complicated systems. Capabilities are realized through processes, people, information, applications, technologies, suppliers, and many other things. Change one thing and something else usually moves with it. And some of the architectural elements occasionally have their own opinion about the matter.
EA helps make these dependencies visible and usable in planning and decision-making. The trick is to describe enough, but not too much. Trying to model absolutely everything is a good way to build an expensive repository that is already outdated when you finish it.
For me, this is probably the most enduring value of EA: helping people understand what depends on what before they start changing things.
2. Enterprise Architecture Is Largely About Dialogue
Earlier in my career, I thought about EA more through its outputs: models, principles, roadmaps, and other documentation. I now think much more about the conversations around them.
Business, IT, security, data management, and development projects all look at the same organization from different perspectives. Each has its own priorities, terminology, and understanding of how things work. Architecture provides a common structure for connecting these views. Sometimes an architecture workshop is simply a good excuse to get the right people around the same table and discover that their decisions depend on each other.
EA governance often receives a lot of attention, but I see architecture primarily as an enabler. An enterprise architect should be an integrator and facilitator rather than someone who dictates how everyone else must work. In practice, they do not usually even have the mandate for it. Models, principles, and governance practices can help bring different perspectives together and support informed decisions.
3. Models Are Just Tools—But You Still Need the Models
I have become quite pragmatic about architecture documentation. A technically perfect repository that nobody uses has limited value. A rough application map drawn in half an hour for the right discussion may be far more useful than a meticulously maintained model containing thousands of elements.
Still, I strongly recommend maintaining a reasonably comprehensive, coherent, and deliberately coarse description of the current state. Knowing which applications you have, what capabilities and processes they support, how information flows between them, and what technologies they depend on is useful in almost any development initiative. There is little sense in rediscovering the same things at the beginning of every project.
You need enough detail to support planning and decision-making, while keeping the architecture manageable. A handful of attractive PowerPoint diagrams will rarely be sufficient, but neither is there much point in modeling every database field or server. Keep the overall architecture broad and connected, then go into detail where needed.
4. Structure Alone Is Not Enough
Traditional EA focuses on structural elements and their relationships: capabilities, processes, information, applications, and technologies. This provides a useful foundation, but much of what matters in organizational change lies outside these structures.
People, money, and organizational power structures can have a considerable influence on what can actually be changed. An application may look perfectly replaceable on an architecture diagram, but the reality can be rather different once you consider its business criticality, costs, ownership, and the people who depend on it.
Fortunately, architecture models can be enriched with additional information. Attributes such as costs, lifecycle status, criticality, risks, and ownership make structural descriptions much more useful for planning. Organizational interests, informal power structures, and skills may require additional analysis and discussions with stakeholders.
I also see visualization as an important part of this. Heatmaps and other visualizations can turn rather technical architecture information into something that management can actually use to compare alternatives, identify priorities, and assess the impacts of change.
The structural model provides the foundation. The additional information helps turn it into something useful for decision-making.
5. The Value of Enterprise Architecture Comes From Use
If I had to pick one idea that connects most of my career, it would probably be this: architecture creates value through use.
A capability map, an architecture principle, or a target-state model has little value sitting in a repository. It becomes useful when someone uses it to understand a situation, compare options, coordinate work, avoid problems, or make decisions.
This sounds rather obvious. It also happens to be one of the main findings of my PhD thesis. Apparently, some obvious things still take a considerable amount of research to establish.
In practice, this simple observation has important implications for how EA should be organized. Start by identifying the decisions and planning activities that architecture should support, rather than the models you want to produce. Measure how architecture information is used instead of counting deliverables. And integrate EA with the activities where development is already planned, managed, and governed.
Ultimately, I see EA as a way to help organizations understand themselves well enough to manage change. The descriptions, methods, and tools are what make that possible.
6. Methods, Frameworks, and Tools Should Stay in Their Place
I started my career reading about EA frameworks, so perhaps it is appropriate that I have become increasingly relaxed about them. TOGAF, ArchiMate, reference architectures, maturity models, and architecture tools all contain useful ideas. I use many of them myself.
They are, however, merely supporting machinery. A good framework provides structure, and a good EA tool makes maintaining architecture information easier. Neither guarantees that the organization will actually benefit from architecture work.
I am therefore more interested in whether an organization’s EA practice works than whether it follows a particular framework. Is architecture information used? Does EA support development and influence decisions early enough to matter? Can people understand the relevant dependencies?
Those questions tell me considerably more than framework compliance or a maturity score.
7. EA Needs to Be Both Strategic and Very Practical
EA is often presented as a strategic discipline. Fair enough. It should connect with strategy work and major organizational change. But not every architecture task needs an executive steering group, a transformation roadmap, and three slides all containing the word strategic.
I still enjoy practical architecture work. Give me a confusing application landscape or a messy set of information flows and I am quite happy to start drawing. Sometimes the useful contribution is simply clarifying which system sends what information to which other system, who owns it, and what happens if one of them is replaced.
I also believe in being helpful. If someone needs a process mapped, an conceptual diagram, or some other practical support, an architect should be happy to help. These smaller assignments are also good opportunities to understand what is actually happening in the organization, build relationships, and make architecture useful to people who might otherwise have little contact with it.
The strategic view needs a sufficiently concrete understanding of the underlying architecture. More detailed process and solution architecture work, in turn, benefits from understanding the bigger picture. I see these as complementary activities, each with its appropriate level of detail.
The Next 20 Years
Predicting the next 20 years in technology is probably a good way to embarrass yourself later, so I will keep this on fairly high level.
AI, data, automation, and regulation will certainly change architecture work. AI can already help analyze large amounts of information, produce documentation, identify dependencies, support modeling, and act as a sparring partner for architects. I expect these capabilities to improve quickly, and there are plenty of architecture tasks I would happily delegate.
At the same time, the basic problem EA addresses seems remarkably persistent. Organizations keep changing their operations, technologies, business models, and structures, while regulation adds its own requirements. These changes create dependencies and consequences that someone needs to understand, preferably before the changes are implemented.
For the time being, I also believe we still need human architects. If EA is largely about dialogue between different people, organizational functions, and perspectives, the job is difficult to reduce to producing models or analyzing data. Someone needs to understand the context, ask the awkward questions, bring people together, and help them make sense of the proposed changes.
AI will probably become a significant part of this work, but I suspect the human side will remain the more difficult part. Technologies, methods, and fashionable terminology will come and go. The need to understand the whole and work across organizational boundaries is less likely to disappear.
So I suppose there is enough work left for another 20 years.
🔗 You May Also Like
Are you looking to dive deeper? Here are some related articles you might find useful:
👨💻 About the Author
Eetu Niemi is an enterprise architect, consultant, and author.
Follow him elsewhere: Homepage | LinkedIn | Substack (expert work) | Medium (writing) | Homepage (FI) | Facebook | Instagram
Books: Enterprise Architecture | The Senior Expert Career Playbook | The Senior Expert Pay Playbook | Technology Consultant Fast Track | Successful Technology Consulting | Kokonaisarkkitehtuuri (FI) | Pohjoisen tie (FI) | Little Cthulhu’s Breakfast Time
Web resources: Enterprise Architecture Info Package (FI)
📬 Want More Practical Enterprise Architecture Content?
Subscribe to Enterprise Architecture Transformation for real-world advice on architecture that supports strategy, change, and delivery.
