Anyone who has been involved in information technology has no doubt been involved in many attempts to understand business needs and translate that into workable technology solutions. I have been no different in my almost 40 years of work in this industry. Many business stakeholders don’t believe it is possible for the “Tech Heads” to understand what they do and their needs. That is because we as an industry have done such a poor job of demonstrating understanding.
The Open Group has been leaders in the thought space of defining Enterprise Architecture. However, with such a broad spectrum to cover it is hard to get much depth. The Open Group Architecture Framework (TOGAF) provides guidance on how to organize and collect data about an enterprise (organization). There is structure provided that can frame / organize information about the organization into sections such as:
- Business Architecture: This domain defines the business strategy, governance, organization, and key business processes. It ensures that the business vision and strategy are effectively realized.
- Data Architecture: This domain describes the structure of an organization’s logical and physical data assets and data management resources. It focuses on data storage, management, and maintenance.
- Application Architecture: This domain provides a blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organization. It ensures that applications are aligned with business needs and data architecture.
- Technology Architecture: This domain outlines the hardware, software, and network infrastructure needed to support the deployment of core, mission-critical applications. It includes the technical infrastructure and services required for the implementation of the business, data, and application architectures
TOGAF is not a prescriptive how-to book. It is a framework for developing your organization’s approach to developing and managing the enterprise architecture specific to your organization. It provides helpful guidance and, in some cases, helpful guidance on what to collect.
I have been searching for more depth in the domains and especially the business architecture domain. I found that when I was introduced to the Business Architecture Guild in 2017. I met one of the founders when he was brought in to talk to the architecture team at one of my former employers. He introduced us to the methodology for performing business architecture which the guild had developed and described in the Business Architecture Body of Knowledge (BIZBOK) guide which is available to the members of the guild. I joined and got access. What I saw was a well thought out approach to modeling the architecture of a business in a sustainable way.
The BIZBOK sees the world described in a set of domains that include:
- Capability Mapping: This involves identifying and defining the business capabilities required to achieve the organization’s objectives. Capabilities are the building blocks of the business and represent what the business does.
- Value Mapping: This domain focuses on understanding and mapping the value streams within the organization. Value streams represent the end-to-end processes that deliver value to customers and stakeholders.
- Organization Mapping: This involves mapping the organizational structure, including roles, responsibilities, and relationships. It helps in understanding how the organization is structured to support its capabilities and value streams.
- Information Mapping: This domain deals with identifying and mapping the information and data that support the business capabilities and value streams. It ensures that the right information is available to the right people at the right time.
- Strategy Mapping: This involves aligning the business architecture with the organization’s strategic goals and objectives. It helps in translating strategy into actionable plans and initiatives.
- Stakeholder Mapping: This domain focuses on identifying and understanding the key stakeholders and their relationships with the organization. It helps in ensuring that stakeholder needs and expectations are met.
- Initiative Mapping: This involves mapping the key initiatives and projects that support the organization’s strategy and business architecture. It helps in prioritizing and managing initiatives to achieve strategic goals.
- Product and Service Mapping: This domain deals with mapping the products and services offered by the organization. It helps in understanding how products and services align with capabilities, value streams, and customer needs.
The key here is that it does not rely on one dimension to understand the organization. Rather it uses all the domains listed above to describe aspects of the organization and how they relate to each other. This approach gives a complete view of the structure of the enterprise without leaning too heavily on one representation to represent the view of the organization.
I have come across many attempts at definiing business architecture where the only artefact being produced is a “capability model”. I put it in quotes because what comes out of the attempt is often not a capability model, but rather a compendium of organization and process. The artefact is often informed by process models. In the end, the model is brittle and does not identify commonality among business areas.
The Business Architecture Guild’s process is more involved, but the result is a model that is more stable and allows the business architect to start to see the areas of commonality. This can be critical to building understanding within the business areas that they are often not as different as they think. There are many common capabilities that can and should be leveraged.
My one extension will be to extend to add one more domain. That is the application. Applications often bring capabilities to life. Understanding the capabilities delivered by applications can assist in understanding where duplication lies. And thus, hopefully, lead to making the case for reducing the spend on software to provide the same capabilities over and over.
Many organizations are rife with this type of behavior. Inability to understand business needs leads business stakeholders to seek their own solutions. Often unaware that other stakeholders in the organization have done the same for possibly the same capabilities. This results in overspend on software and the requisite costs to support these different solutions.
I am currently working on tooling to enable capturing and analysing this information. There are lots of tools on the market. In my world, cost is a big factor. I am currently working on building customized tooling using a platform from Sparx Systems called Enterprise Architect. But, that is a story for another post.





You must be logged in to post a comment.