Architecture Domains

In the last section, we discussed what architects do. The focus was primarily architects in a “team of teams” environment, not strictly at the level of a single product team. However, while this Competency Area has a strong Enterprise Architecture orientation, it is also about the practice of “architecture” more generally. In this Competency Category, we will break down the different forms of architecture and their relationships.

We have seen the Zachman Framework previously. The higher levels are considered “business” or “operating model” concerns. Meanwhile, the lower levels are more technical. In discussing the various domains of architecture, however, a simpler structure is useful. The numerous columns in the Zachman Framework do not necessarily translate to specific architecture domains (for example, there are many Data Architects representing the “what” column, but not many who specialize strictly in questions of timing – the “when” column). Similarly, we can simplify the number of rows by consolidating them into three.

The ArchiMate modeling language is discussed later in the Competency Area. It uses a framework that can be viewed as a simplification of the Zachman model; see Simplified View of the ArchiMate Framework.

Figure 1. Simplified View of the ArchiMate Framework

As we look at the overall structure of the architecture disciplines, we have three disciplines that correspond to the columns. We will call these “perspectives”:

  • Data Architecture

  • Process Architecture

  • Capability Architecture

And three disciplines that correspond to the hierarchical layers:

  • Business Architecture

  • Application Architecture

  • Technology Architecture

Does this mean that we have nine flavors of architecture, one for each intersection? Not necessarily. Some intersections make more sense than others, and some tend to merge with their neighbors. For example, see the DMBOK [DAMA 2010], which covers the gamut of information and data topics from high-level glossaries all the way down to physical database administration. Data architects can and do work across all levels in their perspective.

Architecture Perspectives

Data Architecture

From top to bottom, the Data Architecture (“what”) perspective includes concepts such as:

  • The universe or domain of discourse

  • Ontologies, semantics, and conceptual models

  • Logical data models

  • Data subjects and records

  • Classes

  • Entities/attributes/relationships

  • Tables/columns/constraints

We covered Data Architecture in depth in Information Management.

Process Architecture

Process architecture is concerned with why and how activities are performed. It includes the detailed, step-by-step understanding of activities, in a transparent way. From top to bottom, it includes concepts such as:

  • Value chain

  • Value stream

  • Business process

  • Algorithm

  • Workflow

  • Activity

  • Procedure

  • Task

  • Step

Importantly, processes cross organizations. An “onboard employee” process, as we have seen, may require participation from multiple organizations. We covered process management in depth in Coordination and Process.

Capability Architecture

The last column in Simplified View of the ArchiMate Framework represents steady-state activities. “Hire Employee” is a process; “Manage Human Resources” is a capability. We do not necessarily know all the steps or details; we just know that if we ask the function or capability for some result, it can produce it. This perspective includes:

  • Function and its relatives

  • Function

  • Capability

  • Service (sometimes)

We discussed functional organization previously in Competency Area 9. Note that there is little consensus (and as of the time of writing much industry debate) around whether functions are the same as capabilities; this document sees them as at least similar. Capability is an important concept in Business Architecture, as it has emerged as the preferred concept for investment. We do not invest in data, or process, except as they are realized by a supporting capability. A comprehensive graphical depiction of “capabilities” may be used to help visualize portfolio investments, sometimes using green/yellow/red color coding – this is called “capability heat mapping”.

Architecture Layers

Business Architecture

The Open Business Architecture (O-BA) Part 1, a standard of The Open Group [P161] defines Business Architecture as: “The formalized description of how an organization uses its essential competencies for realizing its strategic intent and objectives”.

The TOGAF Standard [C220] defines Business Architecture as: “A representation of holistic, multi-dimensional business views of: capabilities, end-to-end value delivery, information, and organizational structure; and the relationships among these business views and strategies, products, policies, initiatives, and stakeholders.”

The TOGAF® Series Guide: Business Models [G18A] covers the Osterwalder Business Model Canvas extensively. In so doing, it highlights that the concept of the business model is of interest for Business Architects. Because of this, it is helpful to view Business Architecture as the component of Enterprise Architecture most concerned with the business model, in addition to the operating model.

More specifically, there are a number of concerns that Business Architecture includes, from the Guide to the Business Architecture Body of Knowledge® [BIZBOK® Guide]:

  • Value Streams

  • Capabilities

  • Organization

  • Information

  • Stakeholders

  • Vision, Strategies, and Tactics

  • Initiatives and Projects

  • Decisions and Events

  • Metrics and Measures

  • Products and Services

  • Policies, Rules, and Regulations

The reader might notice some overlap with governance elements, which also include Information, Policies, and Organization.

On the other hand, we do not expect to see in Business Architecture the following:

  • Specific technology products

  • Software architectures (design patterns, class models, etc.)

  • Detailed deployment diagrams

  • Specific project plans

  • Detailed flowcharts

  • Specific devices

Application Architecture

Application, or application systems, like data, process, and capability, is a fundamental and widely-used architecture perspective, as well as a layer. It can be defined as "a fixed-form combination of computing processes and data structures that support a specific business purpose” [Betz 2011]. An application system is practically relevant, obtainable, and operable. (You can buy, or realistically build, one of these.)

Application Architecture can have two meanings:

  • The architecture of a given application

  • The architecture of application interactions

For this document, we will leave the architecture of a given application for solutions and software architecture. Application Architecture is the interaction of multiple applications (which may include digital products and/or services, depending on organization terminology). In a complex, multi-product environment, Application Architecture tends to focus on the interfaces and interactions between the application systems. It is often a concern when systems are considered for retirement or replacement (for example, when a comprehensive ERP solution is brought in to replace several dozen home-grown applications).

Application Architecture is also concerned with the application lifecycle, as covered at the start of this section.

Technology Architecture

Where Business Architecture intersects with the business model, Technology Architecture overlaps with actual engineering and operations. In particular, Technology Architecture tends to be concerned with:

  • Identification of new technical platform capabilities: for example, does the organization need to bring in a NoSQL platform or private cloud?

  • Choice of vendor products, once a technical need is established

  • Establishing infrastructure services as appropriate

  • Defining appropriate usage, including infrastructure design patterns

  • Tracking the lifecycles of the selected products and dependent services, and making appropriate plans

Other Forms of Architecture

There are other kinds of architecture that do not fit neatly into this arrangement:

  • Solutions architecture

  • Software architecture

  • Information architecture (UX-related definition)

  • Adaptive systems architecture

Solutions Architecture

Solutions architecture, especially, is a loose term. In general, it is restricted to one product, or a few products which are working together, as a “solution” to a business problem. Within that scope, it may incorporate concepts from infrastructure to Business Architecture. It also connotes more technical concerns.

Software Architecture

Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.
— Grady Booch

The rapid evolution of software technology has fueled the growth of digital business. Following the lead of Internet giants, some enterprises from the old economy are framing themselves as tech companies; for example, Banco Bilbao Vizcaya Argentaria (BBVA): “If you want to be a leading bank, you have to be a technology company.”

Internet giants did succeed at retaining the agility of startups while they grow at a fast pace and operate at a global scale. They paid special attention to loose-coupling and team autonomy and they learned how to master distributed computing at scale.

Since loose-coupling and distributed computing at scale are software architecture concerns, digital enterprises have to develop robust software architecture capabilities.

Domain-driven-design has deeply influenced the software engineering discipline by shifting the attention to the domain. The most significant source of complexity of much software is not technical. It is in the domain itself, the activity or business of the user.

When this domain complexity is not dealt with in the design, it won’t matter that the infrastructural technology is well conceived. A successful design must systematically deal with this central aspect of the software. [Evans 2003]
— Eric Evans

The premise of domain-driven design is that:

  • For most software projects, the primary focus should be on the domain and domain logic

  • Complex domain designs should be based on a model

Domain-driven design provides strategy patterns that help design loosely-coupled systems. The modular nature of a software system architected with domain-driven design makes it cloud-native friendly by design. The code quality improves because domain concepts are made explicit.

The code is more readable (even by business people) and easier to maintain. Value objects drive a coding style that promotes immutability which makes distributed systems safer. Domain code is more immune from future technology obsolescence because it isolates and protects “domain” code from “technical” code which is more subject to technology obsolescence.

Marc Andreessen once wrote: “Software is eating the world” [Andreessen 2011]. Evidence of this is the increasing scope of software technology usage. For example, IT infrastructure is becoming a software discipline. Infrastructure as Code and SDNs handle computing and networking resources as software objects. From a domain-driven design perspective this opens domain modeling well beyond business into technology domains.

AI technologies such as Deep Machine Learning push the limits of automation. Software can now perform more and more activities that used to be exclusively performed by human beings, such as driving a car or performing a medical diagnosis.

Software becomes a key component of complex product and service systems; for example, an automated parking or a self-service system. This has two implications:

  • Software architecture is morphing into system architecture (systemic meaning of system)

  • Business people have to understand software engineering as they understand marketing or finance

Information Architecture (Alternate Usage)

Information architecture may mean the higher, more business-relevant levels of Data Architecture. However, the term also is used in relation to Application Architecture, in the sense of how the user understands the meaning and data represented by a website or application, or even just the navigation structure of a website.

Adaptive Systems Architecture

Complex Adaptive Systems (CAS) are composed of elements, called agents, that learn or adapt in response to interactions with other agents …​ The activities of semi-autonomous agents are only partially controlled by current input. So agents can examine different courses of action prior to execution. [Holland 2006]
— John Holland

In a digital world, aligning business and IT is no longer sufficient. You have to architect the enterprise in such a way that it can adapt to emerging customer and business needs.

The information systems of large organizations are becoming more complex which increases coordination efforts, raises failure rates of large transformation projects, or lowers the enterprise’s agility.

The CAS theory provides key concepts to help design systems that can evolve while complexity is maintained under control (i.e., co-evolution, interconnected autonomous agents, self-organization).

Enterprise Architecture needs to evolve toward an Adaptive Enterprise Model that facilitates its co-evolution with the environment and delegates decision-making to the lowest possible level.

The enterprise develops and delivers products and services that meet the ever-changing needs of customers and markets. Cross-functional features teams or squads led by product owners are given the autonomy to experiment and evolve products and services.

At the enterprise level, strategy defines the purposes that help align autonomous teams. Business models define how the enterprise will co-evolve within its eco-system. Operating models define how the required business capabilities will be supported.

The emergence of product platforms helps reuse capabilities that several products or services need. Product platforms accelerate the creation of new products and lower their development and production costs.

Toward an Adaptive Enterprise Model represents an evolution of the classical enterprise model, complemented with concepts borrowed from Agile requirements, Lean Startup, and LPPD.

Figure 2. Toward an Adaptive Enterprise Model

Let us now zoom in on customer experience. In the old paradigm the enterprise would capture customer requirements and build products and services that meet those. The approach is mainly driven by market studies that try to “guess” what customers need.

In the digital world, guessing is replaced by observation and experimentation. The focus shifts to modeling the “Jobs to be Done” [Christensen Institute] by customers. The rapid development and experimentation of an MVP helps the enterprise confirm its direction or pivot to a different concept.

The art of architecting itself moves from a pure top-down role to a coaching role where capability modeling and modularity principles help define the Minimum Viable Architecture (MVA).

The Customer Experience’s Paradigm Shift illustrates the shift toward an outside-in approach, which has the following benefits:

  • Distinguishing the problem space from the solution space opens innovation opportunities

  • Focusing on capabilities helps improve the enterprise’s business and operating models

  • Fast iterations transform the enterprise into a learning organization capable of adapting to changing customer expectations

Figure 3. The Customer Experience’s Paradigm Shift

Evidence of Notability

There are a wide variety of architectural practices and approaches frequently addressed and debated within industry. They are codified within the TOGAF Standard [C220] as well as other literature.


Architecture often manifests as an impulse to plan in advance; however, in complex situations it is difficult to plan before a full understanding of the problem is achieved. This is a well-known problem in software engineering.

Related Topics