By Dr. Mathias Kirchmer, Managing Director and Co-CEO, BPM-D

Organizations Struggle to Realize the Full Potential of Enterprise Architecture

Some time ago, I had a check-up session with the enterprise architecture (EA) team of a consumer goods company. A team member proudly announced that they had captured more than 600 process, application architecture, data and other information models in their EA repository. “We think, we have created a major asset for our company,” the team lead stated. “We just have one problem: Last month not one person looked at our models.” This is a big, and unfortunately, very common issue. Organizations tend to create many information models to describe business and technology aspects of their organization without having clearly defined the desired benefits. A great deal of time and money is spent without realizing the full potential of an EA.

“To realize the full potential of EA it must be integrated into a larger management discipline”

It is important to start the EA journey with the desired outcomes in mind. The definition of “usage scenarios” is the basis for all other architecture activities. You must define which context you use the EA content, how you use it, and which value it has to deliver. This allows for development of the entire architecture in relation to the targeted value. Typical examples for usage scenarios are process-led improvements and transformations; standardization and harmonization of processes; business-driven technology management; implementation and maintenance of application software systems, such as ERP systems; governance, risk and compliance management; or training. There are many more such scenarios. It is important that you select those that provide the best benefits to your organization. Start with a few, and add others as time goes on.

Today’s EA integrates business and technology aspects to provide appropriate transparency over the organization, which is necessary for systematic strategy execution. Frameworks like the Architecture of Integrated Information Systems (ARIS), developed by Scheer, or the Zachman Framework help to identify the content. In the end, the company-specific usage scenarios determine the EA content an organization requires.

Define a Pragmatic Structure

Once it is clear what to capture in the EA, you must define how to do that. For example, which overall structure to establish, which modeling methods to apply, or on which levels of detail to define the different components of the EA. Formal modeling methods allow the integrated representation of different EA components.

Don’t Forget the Enterprise Architecture Governance

For most organizations it is challenging to keep an EA up to date and useful. This is where structured EA governance is useful. It defines, for example, how a planned change in the business or technology reality is reflected in the EA, who approves and who executes those changes, or who simply needs to be informed.

Tools are just Enablers

In many cases, organizations start with the procurement of an architecture tool, simply to find out later that it does not support all their usage scenarios or that, it is too complex for the intended use. Tools are important – but just enablers. Usage scenarios, resulting EA content, and structure should at least be defined at a high level before selecting the supporting tools. Even then you may only use a fraction of the available functionality, as the tools will need to be configured appropriately.

Value-driven Enterprise Architecture – Part of the BPM-Discipline for Strategy Execution

To realize the full potential of EA it must be integrated into a larger management discipline, such as a business process management discipline that focuses on strategy execution. EA delivers the transparency to identify high impact processes and define the appropriate transformation approaches, leveraging the opportunities of our digital world.