Enterprise Architecture Using the TOGAF Standard: Bureaucracy or a Catalyst for Transformation?

Enterprise architecture has an image problem. For many engineers and product teams, the term conjures up images of PowerPoint slides, committee meetings, and 800 pages of documentation that no one reads. At the same time, these same organizations struggle with slow decision-making, opaque IT landscapes, and silos that hinder any change. It is precisely this tension that is at the heart of the following interview.

I spoke with Christopher Schulz, CEO of palladio Consulting and one of the most experienced leaders in enterprise architecture management in the German-speaking world. Christopher has trained over 35,000 people internationally in EAM and TOGAF. Our conversation focuses on the question of when architecture work becomes an end in itself and when it actually makes an organization more agile.

Christopher Schulz

Since starting his career in 2007, Christopher Schulz has been managing projects and bringing an architectural perspective to them. He is now the managing director of Palladio Consulting. His experience dates back to the first EAM projects in 2008, when the framework was still a monolith. You can connect with him via LinkedIn.

EAM and TOGAF in Systems Engineering

Enterprise Architecture Management views an organization as a system. It integrates the business perspective, the process perspective, and the IT perspective into a comprehensive view and highlights the interactions between these levels. In the Systems Engineering This pattern is well known: Instead of a technical product, the organization itself is the system under consideration, with elements, properties, and interfaces.

TOGAF is the most widely used framework for this work. More than 170,000 architects worldwide are certified in this standard. It provides a unified conceptual framework, a method for architecture development, and a collection of templates and checklists. For systems engineers, TOGAF is thus what established process standards are for product development: a shared language and a toolkit that saves them from having to start from scratch.

Interview: Why Executives Should Care About Architecture

Michael: When we talk about competitiveness, many people first think of products, processes, or technology. Why should executives even be concerned with enterprise architecture?

Christopher: Because Enterprise Architecture Management (EAM) brings all three perspectives together. 😉 With EAM, executives view their company holistically: from the business model, through market products and business processes, to information technology. The focus is on the elements, their characteristics, and—in particular—their interactions. With this end-to-end perspective, strategy is translated into action, organizational silos are broken down, and business and IT are aligned.

Michael: Among many engineers and product teams, enterprise architecture has a reputation for being far removed from day-to-day business. Who actually needs enterprise architecture, and who doesn't?

Christopher: EAM views an organization as a system and is therefore particularly helpful for multifaceted and dynamic—that is, complex—organizations. In the world of project management, EAM supports me by encouraging a mindset focused on architectural stages. The focus is not on the project itself in terms of time, cost, and scope, but rather on the target state and the necessary intermediate steps from the current state to the target state. That is just like when building a house. Where are we headed? Where do we stand? What are the phases that will take us step by step toward the target architecture?

EAM and its up-to-date factual foundation are also helpful in day-to-day operations. How many IT systems do we have? What business processes do they support? Who is responsible for them? What changes with new business requirements, AI technologies, or legislative amendments? These are all key metrics regarding the enterprise architecture. Compare this to public life. No one questions our resident databases, real estate registries, or vehicle registries.

„No one questions our resident databases or vehicle registries in public life. The same standard should apply to our own enterprise architecture.“

Christopher Schulz

TOGAF: Between a Toolbox and an End in Itself

Michael: The TOGAF Standard is probably the best-known framework for enterprise architecture. What exactly is TOGAF, and what practical benefits does it offer?

Christopher: In fact, in the field of EAM, there’s no getting around the TOGAF standard; more than 170,000 enterprise architects worldwide are now certified in versions 9 and 10 of the framework. The standard structures the architecture work in my organization, establishes a consistent terminology framework, and accelerates the creation and maintenance of architecture descriptions. As an enterprise architect, I don’t start with a blank sheet of paper; instead, I find useful templates, instructions, and checklists in the TOGAF core documents and guides. Your readers can find details and an overview video on the TOGAF standard at palladio Impulse.

Michael: Critics see TOGAF primarily as slides, committees, and documentation. Where does this reputation come from, and is it justified?

Christopher: Up through Version 9, the TOGAF standard had a monolithic structure. It was a single document of over 800 pages covering all EAM use cases. The framework quickly became an end in itself. The focus of the analysis shifted from the EAM problem and its solution to the standard itself. I can confirm this framework-centric approach from my first EAM projects in 2008.

That has changed with the current modular TOGAF Standard, 10th Edition. Just like with a smartphone, I have the EAM operating system—specifically the Architecture Development Method—as well as various apps, the TOGAF guides, which I use on a case-by-case basis. The TOGAF Standard is thus a toolbox of combinable and flexible tools for architecture work.

„The TOGAF Standard is like a smartphone today: an operating system, plus apps that I use as needed.“

Christopher Schulz

Michael: When does enterprise architecture actually become a hindrance? What typical mistakes do you see in companies that implement architecture but still move slowly?

Christopher: I’d be happy to rephrase your question and list three key factors for the success of EAM. These are based on nearly two decades of research, consulting, and training.

• First: Support. EAM doesn't work by lecturing people, but by providing guidance and assistance.
• Secondly: Minimalism. EAM doesn't try to do everything; it simply highlights the architectural details that address stakeholders' concerns.
• Thirdly: Continuity. EAM is not a one-time project carried out by individual architects, but rather an ongoing commitment on the part of the entire organization.

Your readers can find more EAM tips in our Palladio Introductory Course, free of charge after registering via email.

Architecture as a Catalyst

Michael: With Product Velocity We're talking about quick decisions, short feedback cycles, effective platforms, and a high flow of knowledge. Where do you see the greatest points of overlap between these principles and a well-designed enterprise architecture?

Christopher: EAM touches on at least one aspect of every area. The discipline supports decision-making through techniques such as the trade-off method. When it comes to feedback, a „Just Enough Architecture“ mindset has now taken hold. Therefore: minimal architecture work, gather feedback, repeat. Platforms are socio-technical systems composed of organization and technology. Through architectural principles and standards, EAM ensures a holistic view and optimization. When it comes to knowledge flow, I like to refer to architectural representations such as business capability maps, IT system development plans, or technology portfolio matrices. These bring different stakeholders together and stimulate joint discussion, decision-making, and progress.

„Just Enough Architecture means: minimal architectural work, gathering feedback, repetition.“

Christopher Schulz

Michael: Many readers struggle with silos and complex IT landscapes. How does enterprise architecture highlight these bottlenecks, and what three specific steps do you recommend to resolve them?

Christopher: EAM makes architectural elements and their relationships visible. This allows for end-to-end optimization of decision-making processes. Here are three specific measures to address the challenges you mentioned: When decision-making is slow, architecture management recommends identifying stakeholder concerns and addressing them with appropriate architectural representations. To break down silos, EAM advocates promoting interoperability. We define and design organizational and technical interfaces. EAM addresses complex IT landscapes through architecture governance. The target landscape is agreed upon and pursued collaboratively. Instead of shadow IT, uncontrolled business growth, or technical debt, we pursue the managed evolution of the organization.

Conclusion

Enterprise architecture becomes bureaucracy when the framework takes precedence over the problem. Christoper Schulz shows that enterprise architecture that is guided by specific stakeholder questions remains minimal and is continuously maintained. Those with a background in systems engineering will find familiar principles here, applied to the organization as a system.

In practice, this means that before a company establishes a major architectural function, it’s worth taking a look at the three success factors Support, Minimalism and Continuity. And the modular TOGAF Standard 10 dispels the criticism that the framework is an 800-page monolith. It remains the architects’ responsibility to select the appropriate tools rather than using them all at once.

If you want to delve deeper, you'll find Palladio Consulting a free introductory course. For direct communication, you can reach Christopher Schulz at LinkedIn available.