Business complexities such as organizational structure, business processes, information systems, customer relationships, and others pose a significant challenge for enterprise architecture (EA). Managing complexity becomes crucial to enable an organization to respond quickly and efficiently to changes in markets, regulations, and innovations.
💡 Many EA initiatives tend to focus on how to manage complexity in IT, until it becomes evident that complexity is, for the most part, a direct consequence of business complexity.
Decomposition is a fundamental process in EA for managing complexity and uncertainty in an organization. It consists of dividing an entity or system into smaller, more manageable parts, making it possible to tackle business challenges more effectively. In the context of enterprise architecture, decomposition involves grouping functions into domains or functions according to synergy or autonomy.
Functional decomposition
The most natural approach to decomposition is to first understand the functions the organization performs (that is, the business functions).
A function is a collection of closely related data and decision points (for example, "Payments" is a function). These functions don't add much value on their own; rather, they are part of a macro-process that delivers value. For example, a payment by itself doesn't mean much — it usually happens in the context of a specific exchange of value or service.
The first action to take is to create a taxonomy (or, more precisely, an ontology) to consistently describe the functions performed across the entire enterprise. Then, various processes, products, or services can be described as a combination of those functions.
If we accept (though it's not accepted everywhere and I doubt it ever will be) that EA focuses on IT complexity, then EA is not responsible for the complexity related to the existence of processes, products, or services. The creation or elimination of these is generally a direct consequence of business decisions. However, EA must take charge of cataloging them and making sure they are incorporated into other business processes, such as disaster recovery or business continuity processes. In addition, EA must relate this to the functional taxonomy and the IT architecture.
This can get very complex very quickly due to the large number of processes, products, and services, including their many variations, that most organizations have. It is therefore important to divide or decompose the complexity into manageable parts to enable meaningful conversations.
Domain-based decomposition
One way to do this at the enterprise level is to group functions into partitions (domains) according to synergy or autonomy (as described by Roger Sessions in his book Simple Architectures for Complex Enterprises), for all the products/services that support a particular business. This approach is based on the mathematical concept of equivalence. Because different functions in different contexts can have distinct equivalence relations, functions may appear in multiple domains. One of EA's roles is to assess and validate whether those functions are truly autonomous or whether there is an opportunity to group seemingly duplicated functions into a new domain.
By grouping functions into domains according to synergy or autonomy, we can adapt quickly to changes in the business environment, evolve independently, and simplify the understanding of the architecture. In addition, we can reuse solutions, maintain consistency, and establish domain-specific strategies, which allows us to make more effective decisions and achieve a fast, efficient response to changing demands.
Once the domains are identified, it becomes possible to apply "traditional" EA thinking to a particular domain, because that domain has a manageable size. By "traditional EA" I mean applying Zachman, TOGAF, PEAF, or any of the many methodologies out there. More specifically, at that level, it's possible to establish a meaningful information systems strategy or objective for a particular domain that directly supports business agility goals.
The fallacy of functional decomposition
Once you get down to the domain level, functional decomposition is no longer as useful for solution architecture. What architects usually do is build reusable components or services that perform the different functions of the partition. But in reality, this can generate more complexity instead of less (and therefore less agility), as Juval Löwy demonstrates in his book The Zen of Software Architecture.
When we talk about software architecture, the real reason for modularizing is to manage volatility or uncertainty and to make sure that changes in one part of the architecture do not negatively affect other parts in the future. Doing this allows us to stay flexible, so that the changing areas of the application can be updated frequently with little impact on the rest of the application.
Looking at a software architecture from this perspective, you may discover a set of components/modules/services quite different from those that would be evident when decomposing it functionally. A key argument Juval makes in his presentation is that (paraphrasing him slightly) functions, in general, depend heavily on the context in which they are used, so having them in separate services could require making often-impossible assumptions about all the possible contexts in which the functions might be called.
In this sense, the identified components, modules, or services can be seen as options regarding what is done or how it is done, within the context of a larger system with changing parts.
Domains as Enterprise Architecture
When you consider each domain and its relationship to others, there is a lot of uncertainty about how they will evolve. To be flexible, each domain must assume that the others are a volatile part of the architecture and design accordingly. That way each one can evolve (more or less) independently, with few coordination points and without compromising the enterprise architecture by making different domains replicate the behaviors of their dependencies.
To be able to work around volatility we need the following:
-
Investment must be expressed in terms of impact on one or more domains.
-
Domains must establish their own implementation strategies.
-
Agile principles must be agreed upon on a per-domain basis.
-
Architecture standards must be agreed upon on a per-domain basis.
-
Domains must define internally reusable components relevant only to that domain.
-
Domains must expose their behavior to others in a consistent way across the organization
In startups, domains don't need to be organizationally aligned. However, in other (bureaucratic) organizational cultures, aligning enterprise architecture functions, such as IT or operations (at least), with the domains can help accelerate architecture changes (remember, we only have 2% of the time to do it, as I explained in the post The 2% problem) and the necessary cultural changes.
Some of the benefits of using volatility-based decomposition are:
-
Flexibility: By grouping functions into domains and designing with volatility in mind, you achieve greater flexibility to adapt to changes in markets, regulations, and innovations. This enables a fast, efficient response to the changing demands of the business environment.
-
Agility: Each domain can evolve independently, without compromising the enterprise architecture as a whole. This provides the ability to make changes faster and with less impact on other parts of the system.
-
Reduced complexity: Grouping functions into domains makes it easier to understand the architecture and hold meaningful conversations about it. This helps reduce complexity and address business challenges more effectively.
-
Easier decision-making: With smaller, more autonomous domains, decision-making related to each domain becomes simpler. Teams can establish domain-specific strategies, principles, and standards, which facilitates decisions and the implementation of changes.
-
Reuse and consistency: It allows defining internally reusable components within each domain. This fosters solution reuse and consistency within the organization. Domains can expose their behavior consistently across the organization, which facilitates integration and collaboration.
References
Taxonomías vs. Ontologías ¿En qué se diferencian las taxonomías y las ontologías?
Simple Architectures for Complex Enterprises
The Zen of Software Architecture - O'Reilly Media Free, Live Events
Pragmatic Enterprise Architecture Framework | The Transformation of Transformation