Interestingly, there are even large companies out there that put very little to no effort in assessing, managing, and developing their business architecture within their enterprise architecture practice. It seems that, due to the very few benefits realized from business architecture in the short term, the focus of enterprise architecture has been more on technology solutions, information, and data. With the rediscovery of enterprise architecture during the past few years, this seems to be changing and the result is a high demand for business architecture expertise, including how to explain the benefits to the business, what to expect, and how to get started. In this post, I provide a brief overview of the artifacts (elements) that your enterprise architecture domain should start with to be able to provide added value to your organization.
1. Enterprise Architecture Principles
First, your practice must know its purpose. This is usually described in a vision and later in a strategy, and is concretized through a set of statements, call them paradigms, maxims, guardrails, guidelines, or principles. They may differ in their level of detail, but all of them have in common that they define the boundaries of what is in scope (e.g. a particular domain), what should happen with it, or what should be kept (e.g. harmonize, keep, clean), and provide some more information that makes them more tangible than a simple vision (e.g. which technology or platform is targeted). Compared to a vision, they have just the right level of detail to provide guidance but are not too detailed and complex to be understood. They need to be accepted by top management and provide a high-level direction and decision-making support for everything that comes after it.
2. As-Is Architecture
Secondly, an enterprise architecture practice must know the current status of what it is supposed to improve to be able to derive measures. Therefore, the most important components must be assessed, and the results must be documented in such a way that they are used to draw insights from. The components to be assessed should be the applications, data, and technologies of your organization. The way to document the results should be a business capability map that has all relevant components mapped to it. If you are not sure what an IT architecture landscape is, consider reading this article first.
For instance, the Marketing capability “insights from customer segments” might have a Marketing application mapped to it, as well as data about the different customer segments defined, and tracking information from website cookies. However, you might also map your application to your marketing communication capability as you use it to provide adapted pop-ups to visitors of your website. This exercise can take a lot of time and effort, so you do not want to just start mapping everything that you have at the same time. It is important to understand which mappings provide the most value to your organization so that you can start with those.
3. Reference Architecture
Having some principles of where you want to go is a good start, but it is not enough for daily business. While principles are typically more generic and common across your organization, a reference architecture provides a target state for your domains. (The main difference between a target architecture and a reference architecture is that the latter does not take constraints into account. Learn more about different architectures in one of my next posts.) The reference architecture is therefore an operationalization of the principles and shows the direct indication of applying the principles to the architecture. In the end, the reference architecture is a target state for the company that is still far in the future and therefore does not consider drawbacks or problems from the current architecture.
A reference architecture could be illustrated with the help of a target business capability map that does not show too many details (they would change too often) but that illustrates for instance which applications and technologies are the references for a particular capability. During a demand management process, this reference would then be the default solution and one would have to argue to deviate from this standard. In addition, the reference architecture could include information, such as the strategic importance of a capability to identify which areas should be prioritized or information about whether a capability should move to the cloud, to a particular platform, etc.
4. Roadmap
The purpose of a roadmap is to provide the way from the as-is architecture to the target (or reference) architecture. There are two major types of roadmaps. Displaying projects, initiatives, or programs would show when the organization works on a particular topic and hence needs the resources, can impact the results, etc. Displaying technologies or applications would emphasize at what point in time which applications or technologies are active in the organization, when it is not available anymore, or when technologies run in parallel. It will depend on your stakeholders which type of roadmap you should create.
In the end, if your enterprise architecture practice focuses on these four concepts, it will be able to add value to your organization by improving alignment with the business and with the strategic targets, as well as by decreasing complexity, duplications, and driving down costs with an affordable amount of effort.