Architecture Domains

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

We covered Data Architecture in depth in Information Management.

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:

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.

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:

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”.

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]:

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:

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:

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.

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:

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.

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.

The premise of domain-driven design is that:

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:

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.

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.

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:

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.

Limitations

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