Area Description

Regardless of starting off as a digital startup, or as an older organization now digitally transforming, the digital world is complex and getting more so.

The prior decisions that might have been made quickly and casually by a product or project team become harder. The increasing challenges are due to both internal and external factors. Decisions made years ago come back to haunt current strategies with a vengeance. With scale, management needs some way of making sense across digital operations of mind-numbing complexity. Should a firm invest in 15 new internally developed microservices, or sunset 12 existing ones and implement a commercial package developed by a trusted partner? When there are 1,500 applications or services in the digital portfolio, how do we know that the proposed number 1501 is not redundant or outright conflicting with existing services?

Architecture provides tools to manage such problems, but doing so is difficult and controversial. Is the architecture merely the drawings of HiPPOs? How can the organization maintain an experimental and hypothesis-driven approach in the midst of all the complexity? How do we know that their understanding of the digital operation is current and up-to-date? How much should an organization spend on keeping it so? What happens when management decides to set direction using these same abstractions, and architects find themselves now enforcing what had originally started as mere explanation and sense-making?

Vendor relationships become a two-edged sword, providing increased value with access to higher levels of vendor resources, but at the cost of greater lock-in. Pure open-source strategies inevitably give way to monetized relationships, as the risk of not having support becomes unacceptable.

Portfolio management in terms of IT means looking at long-lived IT investments regarding their overall benefit, cost, and risk to the organization. This can and should be done regardless of whether the IT investment is external or internal-facing. Products, services, and applications are the most useful portfolio constructs, although assets, technology products, and even projects also figure into longer-horizon value management. Enterprise Architecture benefits from a tight alignment with IT portfolio management, as well; it is not clear that a firm boundary between them could be drawn.

This Competency Area is, in a way, summative: it reflects all of the concerns discussed in the previous Competency Areas. Every Competency Area represents topics of interest to the architect. Now, we discuss a language and way of thinking to merge these concerns.

As with other Competency Areas in the later part of this document, we are going to introduce this topic “on its own terms”. We will then add additional context and critique in subsequent sections.

Why Architecture?


The word “architecture” is usually associated with physical construction: buildings, landscapes, civil infrastructure, and so forth. It was appropriated by systems engineers at IBM around 1960 to describe the problems of designing complex information processing hardware and software. This leads to some confusion, and occasional questions from “real” architects as to why IT people are calling themselves “architects”. Perhaps a different choice of word would have been advisable.

In our journey to date, we have covered:

We have also covered the practices by which ideas and intentions are established and translated by investment into actions, including:

As we have progressed in our journey and scaled our company up, all these areas have continued to evolve. Specialization emerges. You have people with deep experience in cloud architectures and individuals with deep experience in e-records management and compliance. You do not have too many who are deep in both.

Your product portfolio (internal and external) is now in the hundreds or thousands. Some were built with the latest technology, and others run on older technologies now perceived to be dead ends. However, investing in rewriting or re-platforming them would not provide as much value as other uses of the funds, so you have to manage the risk of the older technology.

Investment decisions become harder. You are far beyond the days when you had a one-product focus. You have multiple interacting products and multiple interacting teams, and the relationship between the teams and outputs is not one-to-one. Understanding the business case for the investment gets harder; when you have a thousand services over multiple business units, how do you know if someone is proposing a redundant new one?

Moreover, there are the big headaches. A major commercial product version is going off support, and it is the perfect time to think about a rewrite or re-platform (say into the cloud). However, the moving pieces and interdependencies are formidably complex, and if you get the analysis wrong, the business impact will be severe. You acquire another firm, with a lot of overlapping activities, and start to see the need for “Business Architecture” to clarify your understanding of business processes, organizations, and capabilities. Alternatively, a major outage hits the business hard, and all of a sudden the organizational priority (from the Board on down) is “fix this, so it never happens again”. Everything else is to go “on hold”. Except, of course, it cannot.

In response to these and a thousand other complexities of digital management as organizations scale up, a general-purpose coordination capability emerges sometimes called Enterprise Architecture. In this Competency Category, we will discuss its definition, organizational dynamics, and value proposition.

Defining Enterprise Architecture

The fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution. [157]
— ISO/IEC/IEEE 42010
The Enterprise Architecture is the organizing logic for business processes and IT infrastructure, reflecting the integration and standardization requirements of the company’s operating model. The Enterprise Architecture provides a long-term view of a company’s processes, systems, and technologies so that individual projects can build capabilities - not just fulfill immediate needs. [237]
— Ross
Enterprise Architecture (EA) is the representation of the structure and behavior of an enterprise’s IT landscape in relation to its business environment. It reflects the current and future use of IT in the enterprise and provides a roadmap to reach a future state. [28 p. 35]
— Bente et al.
Collaborative Enterprise Architecture
The purpose of Enterprise Architecture is to optimize across the enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment that is responsive to change and supportive of the delivery of the business strategy.
— The Open Group
The TOGAF Standard, Version 9.2

“Architecture” as a term by itself is something you have encountered since your earliest days as a startup. Perhaps you used it to describe the choice of technologies you used for your products. Or the most important components in your application. Or the common services (e.g., authentication) you developed to support multiple products. The architecture concept is therefore not something new or foreign. But what does it mean to say we have an “Enterprise” Architecture? Enterprise Architecture is nothing but the unification of this document’s topics into a common, formalized, scalable framework for understanding. It means we are “doing architecture” comprehensively, considering the enterprise itself as a system to be architected. It also may mean we have a program for sustaining the work of those doing architecture in the technical, application, solution, data, process, or business domains.

In terms of our emergence model, Enterprise Architecture assumes multi-product, “team of teams” problems. As an overall domain of practice, Enterprise Architecture encompasses a variety of specialist domains (some of which we have already encountered) as we will discuss in the next Competency Category. Some of those domains do make sense at smaller, single-product contexts (e.g., software architecture).

There are numerous definitions of Enterprise Architecture. See, for example, [157], [237], [28 p. 35]. It can be defined as:

  • An organizational unit

  • An organizational capability

  • A formalized program

  • A professional discipline or set of practices

  • A process or process group; an ongoing activity or activities

  • A large-scale artifact (i.e., an integrated model consisting of catalogs, diagrams, and matrices) maintained on an ongoing basis for communication and planning

  • An integrated and standardized language for reasoning about complexity

In general, definitions of Enterprise Architecture characterize it as a coordination and problem-solving discipline, suited to large-scale problems at the intersection of digital technology and human organization. An important function of architecture is supporting a shared mental model of the complex organization. We were first introduced to the importance of shared mental models in Work Management and this need has only increased as the organization became more complex. Enterprise Architecture provides the tools and techniques for sustaining shared mental models of complexity at scale.

It may be useful to compare architecture to the activity of map-making. In map-making we have:

  • The actual terrain

  • The capability of map making: surveying, drawing, etc.

  • The process of surveying and mapping it

  • The resulting map as a document (i.e., artifact)

And once the map is made, you might use it for a wide variety of purposes, and you also might find that once you start to use the map, you wish it had more information. Similarly, in Enterprise Architecture, it is important to remember that there are different concerns:

  • Operational reality

  • The capability of representing it for planning and analysis (“being” an architect or an architecture organization; having the skills and tools)

  • The process of representing and analyzing the operational reality (“doing” architecture)

  • The actual representation (the “architecture” as a “thing” — a model, an artifact, etc.; recall our previous discussion of information representation)

And, like a map, once you have the architecture, you can use it for a wide variety of purposes, but also you may find it incomplete in various ways.

Architecture Organization

There are three major themes we will discuss in terms of the overall organizational positioning of Enterprise Architecture:

  • The line versus staff concept and its origins

  • Contrasting the concepts of “business model” versus “operating model”

  • The other major organizational units of interest to Enterprise Architecture

Architecture as Staff Function

We saw in Governance, Risk, Security, and Compliance how governance emerges, as a response to scale and growth, and the concerns for risk and assurance in the face of increasing pressures of the external environment. One important response has been the emergence of the line _versus staff_ distinction. As Christian Millotat (and many others) have noted: "[m]any elements that have become integral parts of managerial economics and organizing sciences can be traced back” to military staff systems [197 p. 7]. These include:

  • Collecting and combining knowledge so that decisions are as well informed as possible

  • Supporting specialized roles and functions (e.g., legal experts, engineers)

  • Operating supply chains and other services that function best when shared

Staff functions in the enterprise include planning, coordination, and operations; broadly speaking, and with key differences depending on the industry, the following are considered “staff":

  • Financial management

  • Human resources management

  • Legal services

  • Purchasing and vendor management (varies w/company and industry; for example, in retail “merchandising” is a line function)

  • IT (however, with Digital Transformation this is increasingly overlapping with R&D and driven directly by line management)

  • Facilities management

  • Strategic planning and forecasting

While the following are considered “lines” (analogous to the warfighting units in the military):

  • Sales

  • Marketing

  • Operations

  • R&D (varies w/company and industry)

Enterprise Architecture has as a key part of its mission the task of collecting and combining knowledge to support decision-making. Therefore, an Enterprise Architecture organization can be seen as a form of staff organization. Most often it is seen as a specialized staff function within the larger staff function of IT management, and with the increased role of digital technology, there are corresponding pressures to “move Enterprise Architecture out of IT” as we will discuss below.

The classic line/staff division is a powerful concept, pervasive throughout organizational theory. But it has important limitations:

  • Staff organizations can “lose touch”, become insular and self-serving and indeed accumulate power in dangerous and unaccountable ways; ror this reason, officers are rotated between line and staff positions in the US military

  • Staff “expertise” may matter less and less in complex and chaotic environments requiring experimental and adaptive approaches

  • If a feedback loop involves both line and staff organizations, it risks being delayed; the delay waiting for “headquarters approvals” has been a common theme in line/staff organizations

In the history of line versus staff relations, we see tensions similar to those between Enterprise Architecture and advocates of Agile methods. The challenges, debates, and conflicts have only changed in their content, but not their essential form.

But in many cases, centralizing staff expertise and the definition of acceptable practices for a domain is still essential. See the discussion of matrix organizations and even feature versus component teams.

Enterprise Architecture and the Operating Model

In terms of overall positioning, Enterprise Architecture is often portrayed as mediating between strategy and portfolio management (see EA Context, Based on Ross, derived from [237 p. 10], Figure 1-2).

EA context
Figure 145. EA Context, Based on Ross

Notice the distinction between Enterprise Architecture as a capability and as an artifact. The practice of Enterprise Architecture is not the same as the actual Enterprise Architecture. For the purposes of this document, we define Enterprise Architecture’s concerns as essentially the enterprise operating model: process, data, organizational capabilities, and systems.

One of the most frequently used visualizations of Enterprise Architecture’s concerns is the Zachman Framework (see A Variation on the Zachman Framework, loosely based on [313] and succeeding work).

Zachman Framework
Figure 146. A Variation on the Zachman Framework

We were exposed to the data modeling progression from conceptual to logical to the physical data model in Information Management. The Zachman Framework generalizes this progression to various views of importance to organizations, as shown in the columns:

  • What

  • How

  • Where

  • Who

  • When

  • Why

Overall, the Zachman Framework represents the range of organizational operating model concerns well. Certainly, sustaining a large and complex organization requires attention to all its concerns. But what good does it do to simply document the contents of each cell? Such activity needs to have relevance for organizational planning and strategy; otherwise, it is just waste.

Peer Organizations

It is reasonable to associate the Business Model Canvas with strategy, and the Zachman Framework with the Enterprise Architecture as an artifact (see Business Model versus Operating Model).

This distinction helps us position the Enterprise Architecture group with respect to key partner organizations:

  • Organizational strategy

  • Portfolio and investment management

  • I&O

Organizational Strategy

The operating model needs to support the business model, and so, therefore, Enterprise Architecture needs a close and ongoing relationship with organizational strategists, whether they are themselves line or staff. Defining digital strategies is a challenging topic; we have touched on it in Digital Context, Product Management, and Investment and Portfolio. Further discussion at the enterprise level will be deferred to a future edition of this document.

Portfolio and Investment Management

Architecture needs to be tied to the organization’s investment management process. This may be easier said that done, given the silos that exist. As Scott Bernard notes: “Enterprise Architecture tends to be viewed as a hostile takeover by program managers and executives who have previously had a lot of independence in developing solutions for their own requirements” [29], Case Study Scene 1.

Many organizations have a long legacy of project-driven development, in which the operational consequences of the project were too often given short shrift. The resulting technical debt can be crippling. Now that there is more of a move towards “you build it, you run it” the operability aspects of systems are (perhaps) improving. However, ongoing scrutiny and management are still needed at the investment front end, if the enterprise is to manage important objectives like vendor leverage, minimizing technical debt, reducing investment redundancy, controlling the security perimeter, and keeping skills acquisition cost efficient (more on this below in the section on Enterprise Architecture value).

Portfolio management is discussed in depth in a subsequent Competency Category.

Business model _versus_ operating model
Figure 147. Business Model versus Operating Model

Infrastructure and Operations (I&O)

Finally, the Enterprise Architecture group often has a close relationship with I&O groups. This is because in organizations where operations is a shared service, the risks, and inefficiencies of technical fragmentation are often most apparent to the operations team. In organizations where operations is increasingly distributed to the application teams (“you build it, you run it”) the above may be less true.

Other staff organizations that may develop close relationships with Enterprise Architecture include vendor management and sourcing, risk management, compliance, and security. Notice that some of these have strong governance connections (although we do not consider “governance” itself to be an organization, which is why it was not included in the discussion above).

The Value of Enterprise Architecture

Enterprise Architecture often struggles to demonstrate clear, quantifiable value to the organization. Architects are usually among the most experienced and therefore expensive staff in the organization. It may seem to make historical and intuitive sense that architecture as a staff function is necessary. Yet, demonstrating this takes some thought and effort. Statements like “promoting enterprise-wide thinking” easily provoke skepticism. What are the benefits of so-called “enterprise-wide thinking"? And who receives them?

The following outcomes are often asserted for Enterprise Architecture:

  • Shortening planning and decision-making (e.g., through curating information)

  • Curating a shared enterprise language and mental model

  • Increased speed of delivering new functionality

  • Reduced and simplified portfolios

  • Reducing duplication and rework

  • Reducing headcount (e.g., in processes)

Illustrated in Architecture Impacts on Enterprise Value is a high-level impact mapping representation.

Architecture value
Figure 148. Architecture Impacts on Enterprise Value

The diagram suggests a number of specific, measurable outcomes from typical Enterprise Architecture goals. Without exploring every line of value:

  • A reduced technology portfolio can and should result in improved sourcing, improved support, improved security, reduced IT staffing spend, and potentially reduced development time; for example, vendors may offer more favorable terms when their products are preferred standards throughout an organization - a smaller product portfolio is easier to secure

  • Better understanding of the current estate should reduce investigation times and outages, and reduce the risk of regulatory violations; for example, if regulators require evidence that employee medical records have not been removed from the country, architecture’s curating of that information will expedite the compliance response

  • Ensuring systems are adaptable (e.g., they have service interfaces) and resilient (they are designed for operability) should improve both time-to-market over the product’s lifecycle, and ultimately effectiveness in customer acquisition and retention

These are not intangible suggestions. We have previously studied the work and influence of Don Reinertsen, who emphasizes the critical importance of an economic model.

Some might say that architecture’s value is “intangible”. If you are tempted to say this, you should read Douglas Hubbard’s How to Measure Anything: Finding the Value of “Intangibles” in Business [134].

We close this section by discussing two current value concepts and how architecture contributes (or detracts) from them:

  • Cost of delay

  • Technical debt

Reducing Cost of Delay

We have covered the concept of cost of delay previously, at the team and product level. However, this powerful concept can also be applied at higher levels. Cost of delay is not a concept familiar to most architects. It poses two important challenges:

  • How can architecture help reduce the cost of delay within the product portfolio?

  • How can architecture not, itself, introduce un-economical cost of delay?

As we have discussed previously, the definition of cost of delay is intuitive. It is the opportunity cost of not having a given product or service available for use: the foregone revenues, the cost of the workarounds and inefficiencies. If the architecture process becomes the critical path for a product or service’s release (a common experience), then the architecture process is responsible for that product’s or service’s cost of delay.

The cost of delay can take various forms, some of them significant. For example, suppose there is a need to demonstrate a product to key clients at a trade show. This could be the company’s best opportunity to develop business; the sales team estimates $12 million in funnel opportunities based on previous experience that should result in at least $2 million in sales in the year, with projections of another $1 million in maintenance and renewals. However, if the product is not ready, these benefits will not materialize. If everything else is ready, but the architecture process is delaying product readiness, then the architecture process is incurring $2 million in the cost of delay. This is bad. The architecture process is clearly impacting significant business objectives and revenue.

But the question still needs to be asked: “what benefits do we receive from having an architecture process?”. We discussed such benefits above. Are these benefits adding up to $2 million a year? No? Then your architecture process does not make good economic sense. On the other hand, what if the architects were kept out of the picture, and the product team chooses an untested technology, instead of re-using a well-known and reliable approach already proven for that company? What if that decision were the cause of missing the trade show? What if it can be shown that re-usable components identified as architecture standards were increasing the speed of delivery, and reducing the cost of delay, because they are reducing the need for product teams to perform risky (and yet redundant) R&D activities?

Quantifying these benefits across a portfolio is difficult, but should be attempted. Cost of delay can and should be calculated at the portfolio level, and this can provide “enterprise-level decision rules” that can help an organization understand the cost and value of operating model changes [229 pp. 35-38] including instituting processes (such as change management or technology lifecycle management), or even the establishment of Enterprise Architecture itself.

Technical Debt Revisited

We touched on technical debt in Application Delivery's discussion of refactoring. Technical debt is a metaphor first introduced by Ward Cunningham [78] in the context of software, widely discussed in the industry. It can be applied more broadly at the portfolio level, and in that sense, is sometimes discussed in Enterprise Architecture. Debt exists in the form of obsolete products and technologies; redundant capabilities and systems; interfaces tightly coupled where they should be loose and open, and many other forms.

Technical debt, like the cost of delay, can and should be quantified. We will discuss approaches to that in the Competency Category on portfolio management.

Scaling the Enterprise Mental Model

We have often referred to the concept of common ground through this document. The architecture supports common ground understanding at scale, by curating a shared mental model for the organization. In doing so, it enables the “right emergent behaviors” (as Adrian Cockcroft suggests). It also enables communication across diversity and may improve staffing flexibility and mobility among teams.

Evidence of Notability

Architecture has been a metaphor for digital systems strategy and design since the 1960s. It has given rise to multiple professional organizations, and frameworks, and much literature.


Architecture (all practices) is encountering resistance from digital-first organizations and its messaging and value proposition needs to evolve.

Related Topics

Architecture Practices


Before we get into a detailed discussion of architecture domains, let’s talk in general about what architects do and some common practices and themes.

As we mentioned previously, architecture itself as a term shows up in many ways - as role, artifact, program, and organization.

In this Competency Category, we will look at:

  • The relationship of architecture and governance

  • Architecture as a management program

  • The importance of visualization as a practice in architecture

  • The IT lifecycles

  • Architecture and the quest for “rationalization”

Architecture and Governance

Enterprise Architecture has a clear relationship to governance as we discussed it in Governance, Risk, Security, and Compliance. It provides a framework for managing long lifecycle concerns and various forms of enterprise risk, especially as related to digital and IT systems.

Architecture is an important part of the governance equation. Architecture becomes the vehicle for technical standards that are essential risk controls; a risk management organization cannot achieve this alone.

Enterprise Architecture, therefore, may have a role in defining policies, especially at the mid-tier of the policy hierarchy — neither the highest enterprise principles, nor the most detailed technical standards, but rather policies and standards related to:

  • Choice of certain enterprise products expected to be heavily leveraged (e.g., common database and middleware products)

  • Design patterns for solving recurring requirements (e.g., user authentication, load balancing, etc.)

  • System of Record identification and enforcement

As discussed in Mission, Principles, Policies, and Frameworks, there needs to be traceability from tactical standards to strategic codes and principles. The preference for a given database should not be a policy, but having a process that establishes such a preference would be; that is, a policy should exist saying (for example): “there shall be a Technology Lifecycle Management process with the following objectives and scope”. Where appropriate, such policies might also be linked to specific risks as controls or governance elements.

As for all policies, it is important to have some sort of sunset mechanism for Enterprise Architecture guidance. As Bente et al. note: Many Enterprise Architecture-originated policies that appear obsolete today have not always been meaningless …​ A frequent example is the uncontrolled proliferation of newly-hyped technologies by the IT crowd, and the Enterprise Architecture group’s rigid attempt to reinstitute order. Once the technology has matured, the Enterprise Architecture rules often appear overly strict and suppress a flexible use of the appropriate technology [28], p.19.

The issue with the quote above is that the overall benefits of having (for example) a Technology Lifecycle Management process are not usually quantified in terms of cost and risk avoidance. Without an overall governance mandate and value proposition, Enterprise Architecture activities may seesaw in response to the “issue of the moment”. This is not a recipe for sustainable architecture, whose most important value proposition lies in the long term. Architecture, as a component of coherent governance, requires no less.

As we discussed in Governance, Risk, Security, and Compliance governance emerges in part as a response to external forces. Architecture often plays a consultative role when external forces become governance issues; for example:

Governance is also concerned with efficiency, which also becomes a key architecture concern with associated practices:

  • IT portfolio rationalization

  • Business process optimization

  • Shared services and APIs re-use

  • Master and reference data management

Finally, does Enterprise Architecture promote effectiveness? Effectiveness is often seen as the primary responsibility of “the line” in line/staff paradigms. However, as the impact model suggests, establishing a foundation of re-usability and limiting technical choices can increase the speed with which new products and services are delivered.

Architecture as a Management Program

Figure 149. Large-Scale Architecture Program

The above section discussed the relationship of architecture to governance. As we covered in Governance, Risk, Security, and Compliance, governance is not management. Here, we will cover the topic of architecture as a management program of activity, in part through examining an example large-scale architecture program.

Architecture as a program refers to a coordinated set of:

  • Processes

  • Job roles

  • Standards and practices

  • Artifacts

  • Organizations

  • Cadenced and ad hoc activities

intended to serve a key coordination role. Illustrated in Large-Scale Architecture Program is a large-scale, coordinated architecture program in a large enterprise. Notice that this is not a single organization. The Architecture Program in this example spans a centralized Enterprise Architecture group as well as teams of Line of Business (LOB) architects.

The Enterprise Architecture organization might report to a Chief Technical Officer (CTO), the Chief of Staff for the Office of the CIO, or the head of Corporate Strategy and Planning. It is a centralized organization with a small staff of domain architects and an Architecture Standards organization that owns two key cross-functional architecture processes.

LOBs have dedicated IT organizations, and these organizations have Chief Architects with their own staff. In terms of our discussion of line/staff organization, it is as if the line organization has its own staff function within it; another way to think about it is that the line/staff division is fractal (that is, it reproduces at different scales).

Within the central Enterprise Architecture organization, we have a number of director-level Domain Architects. These architects might focus on particular business problems (e.g., Supply Chain) or architectural domains (e.g., Data and Information, or Security).

It is the responsibility of the Domain Architects to create Domain Architectures, which are documents that lay out an overall point of view on a particular domain and often serve as standards. These architectures may be created according to a methodology such as the TOGAF ADM, with the support of a repository-based tool and language such as ArchiMate notation or various standards from the Object Management Group.

The domain architects also serve as a senior consulting pool and are assigned to significant programs and projects as needed.

The Architecture Standards organization is responsible for two organization-wide architecture processes:

  • Architecture Review

  • Technology Lifecycle Management

The Architecture Review process is part of the investment process, when initiatives are initially scoped and direction set. The process requires architects to review significant proposed investments in new systems for consistency with standards (e.g., the Domain Architectures and approved technologies). In terms of the previous section’s impact model, this process is attempting to support many of the lines of value through controlling redundancy and ensuring re-use and application of previously learned architectural lessons.

The Technology Lifecycle Management process is the means by which new vendor and open source products are approved as fit-for-purpose and/or preferred within the organization. In terms of the previous section’s impact model, this process is tasked with reducing the portfolio of vendor products which reduces cost and risk as shown.

Both of these processes are enterprise-wide processes. They are owned, defined, and modified by the Architecture Standards organization, but projects and products across the enterprise follow these processes.

Finally, the Architectural Governance Council brings together the senior architects from the central Enterprise Architecture organization and the LOB Chief Architects. It is a virtual organization operating on a quarterly cadence, responsible for setting direction and resolving the most difficult questions that may emerge from the architecture processes and domain architectures.

Overall, this may seem like a complex structure, but similar structures are in place in IT organizations with budgets of $1bn or more. It would be questionable to see comparable structures in much smaller organizations. However, this structure is useful to examine; organizations of various sizes might choose to use different parts of it.

Modeling and Visualization

We discussed the importance of visual management in Work Management. Making information visually available to help create common ground is an important Lean practice (see Andon).

The word “architect”, whether in a building or digital context, is often associated with visualizations: blueprints, sketches, specialized notations, and so forth. Drawings have been used to represent structures for likely as long as writing has existed.

Judging simply by its history, visualization is, therefore, an essential tool for humans dealing with large-scale complexity (and erecting buildings has always been one of the more complex domains of human activity). In digital and IT contexts, however, visualization has certain challenges and notable skeptics. Adrian Cockcroft, the former CTO of Netflix, stated: “Our architecture was changing faster than you can draw it …​ As a result, it wasn’t useful to try to draw it.” [37]

Even in construction and engineering trades that rely on blueprints as a source of truth, keeping them up-to-date requires considerable discipline and process. In faster-moving digital organizations, visual models are almost always out-of-date unless they have been specifically refreshed for a purpose, or unless there is a strong formal process in place (and the value of such a process may be difficult to establish). That doesn’t mean that diagrams will go away. Co-located teams use whiteboards and dry-erase markers and will continue to use them. There are important cognitive and human factor reasons for this that will not go away. Because of these facts, it is useful to understand some of the fundamentals of how humans interpret visual data.

Human Visual Processing

Dan Moody notes [199]:

Visual representations are effective because they tap into the capabilities of the powerful and highly parallel human visual system. We like receiving information in a visual form and can process it very efficiently: around a quarter of our brains are devoted to vision, more than all our other senses combined [63]. In addition, diagrams can convey information more concisely [27] and precisely than ordinary language [8, 68]. Information represented visually is also more likely to be remembered due to the picture superiority effect [38, 70] …​ Visual representations are also processed differently: according to dual channel theory [80], the human mind has separate systems for processing pictorial and verbal material. Visual representations are processed in parallel by the visual system, while textual representations are processed serially by the auditory system …​

As the above quote shows, there are clear neurological reasons for diagramming as a communication form. To expand a bit more on the points Dan Moody is making:

Human vision uses parallel processing. This means that a given image or visual stimulus is processed by many neurons simultaneously. This is how we can quickly recognize and act on threats, such as a crouching tiger.

A large percentage of our brain is devoted to visual processing. You will see figures quoted from 25% to 66% depending on whether they are “pure” visual tasks or vision-driven tasks involving other brain areas.

The old saying "a picture is worth a thousand words" is consistent with the science. Diagrams can be both faster and more precise at conveying information; however, this has limits.

Finally, pictures can be more memorable than words.

Visualization in Digital Systems
Figure 150. The First Software Flowchart

Architects and architecture are known for creating diagrams — abstract graphical representations of complex systems. The first known instance of applying graphical techniques to a digital problem was in 1947 (see The First Software Flowchart [1][294]), and visual notations have evolved along with the field of computing ever since. Notable examples include:

  • Early flowcharting templates

  • The Gane-Sarson data-flow diagram notation

  • The Chen entity-relationship notation

  • The Barker entity-relationship notation, including the “crow’s foot” to indicate cardinality

  • Harel state charts

  • The Unified Modeling Language™ (UML®)

(We touched on data modeling in Information Management). We will examine the ArchiMate modeling language, a standard of The Open Group, for a current and widely-used notation, in more detail in a future Competency Category.

Research at Microsoft suggests that developers use diagrams for four purposes:

  • Sharing

  • Grounding (defining ambiguous interpretations)

  • Manipulating

  • Brainstorming

They argue “diagrams support communicating, capturing attention, and grounding conversations [4]. They reduce the cognitive burden of evaluating a design or considering new ideas [13]” [58].

But visual notations have been problematic in the Agile community; as Fowler notes [103]. There is no question that some IT professionals, including perhaps some of the most skilled software engineers, find little of use in diagrams. As Martin Fowler says: “people like Kent [Beck, eXtreme Programming originator] aren’t at all comfortable with diagrams. Indeed, I’ve never seen Kent voluntarily draw a software diagram in any fixed notation”. However, it seems likely that Kent Beck and others like him are members of a programming elite, with a well-honed mental ability to process source code in its “raw” form.

However, if we are building systems to be operated and maintained by humans, it would seem that we should support the cognitive and perceptual strengths of humans. Because diagrams are more readily processed, they are often used to represent high-level system interactions — how a given service, product, or application is related to peer systems and services. Building such depictions can be helpful to fostering a shared mental model of the overall system objectives and context. The more complex and highly-scaled the environment, the more likely such artifacts will be encountered as a means to creating the mental model.

The strength of human visual processing is why we will (probably) always use graphical representation to assist in the building of shared mental models. Specialists in the syntax and semantics of such designs will therefore likely continue to play a role in complex systems development and maintenance. Currently, if we seek to hire such a specialist, we recruit some kind of architect — that is, the professional role with the skills.

Note that flowcharts, data models, and other such diagrams tend to be associated more with the idea of “solutions” or “software” architecture. We will cover the architecture domains in the next Competency Category, including examples of Business Architecture diagrams.

Limitations of Visualization

Visualization has a number of limitations:

  • It may be better suited for static structures than for dynamic processes

  • Diagrams may have no real information content

  • Diagrams are difficult to maintain, and there are diminishing returns the more they are elaborated and refined (e.g., for archival purposes)

  • Conversely, diagrams become less accessible the more complex they are

  • Visualization can result in distorted understandings

  • Ultimately, diagrams rely on deeper shared understandings that must be understood and managed

Despite the familiarity of simple flowcharting, visual notations don’t scale well in terms of representing program logic. Therefore, for dynamic or procedural problems, they tend to be used informally, as sketch or whiteboarding, or at the business analysis level (where the flowchart represents business logic, not detailed software). Dynamic processes also change more often than the static structures, and so must be updated more frequently.

More static structures, including data and class models and systems interactions, are still often represented visually and in the case of data models can be transformed from conceptual representations to physical schema.

However, any diagram, whether of a dynamic or static problem, can reach a level of density where it is no longer useful as a visual explanation. As diagrams become more complex, their audience narrows to those most familiar with them. Past a certain point, they exceed the limits of human visual processing and then are of little use to anyone.

This brings up broader concerns of the limits of human cognition; recent research shows that it is difficult for humans to hold more than four things in working memory — this is lower than previous estimates [204]. Diagrams with more than four to seven elements risk being dismissed as unusable.

Another issue with some diagrams is that they do not give a good sense of perspective or scale. This is sometimes seen in the Business Architecture practice of “capability mapping”. For example, suppose you see a diagram such as shown in Simple Capability Map.

Figure 151. Simple Capability Map

Diagrams like this are common, but what does it mean that all the boxes are equally sized? Are there as many lawyers as sales people? Operations staff? It is not clear what the advantage is to putting information like this into a graphical form; no interactions are seen, and the eight areas could more easily be expressed as a list (or “catalog” in the terms we will introduce below). This brings us to the final problem listed above: visualizations rely on some common ground understanding. If boxes and lines are used for communication, their meaning should be agreed — otherwise, there is a risk of misunderstanding, and the diagram may do more harm than good.

Regardless of the pitfalls, many architecture diagrams are valuable. Whether drawn on a whiteboard, in Powerpoint™ or Omnigraffle™, or in a repository-based architecture tool, the visualization concisely represents a shared mental model on how the organizations will undertake complex activities. The diagram leverages the human preference for visual processing, accessing the powerful parallel processing of the visual cortex. Ultimately, the discussions and negotiations the architect facilitates on the journey to driving organizational direction are the real added value. The architect’s role is to facilitate discussions by abstracting and powerfully visualizing so that decisions are illuminated and understood across the team, or broader organization.

Repositories and Knowledge Management

Artifacts are generally classified as catalogs (lists of things), matrices (showing relationships between things), and diagrams (pictures of things).
— The TOGAF Standard
Version 9.2

The question was asked above: “why put things into a picture when a report is all that is needed?”. We know that sometimes a picture is worth a thousand words, but not always. And sometimes the picture’s components need more description than can conveniently fit on the actual diagram. This brings us to the topic of Enterprise Architecture as knowledge management. Knowledge management is a broad topic, with a scope far beyond this document. But in the context of a digital organization, architecture can serve as an important component of an overall knowledge management strategy. Without some common ground of understanding, digital organizations struggle, and Enterprise Architecture can help.

Catalogs, Diagrams, Matrices

As the previous quote from the TOGAF standard indicates, architecture can elegantly be represented as:

  • Catalogs

  • Diagrams

  • Matrices

For example, consider the image shown in Process and Function Diagram.

Figure 152. Process and Function Diagram

It can be read as saying that the “Quote to Cash” process depends on the following functions:

  • Sales

  • Contracts

  • Accounts Receivable

Notice that a matrix (see Process and Function Matrix) can be read in the same way.

Figure 153. Process and Function Matrix

“Quote to Cash”, which appeared as a chevron in the diagram, is now one of a list:

  • Quote to Cash

  • Procure to Pay

  • Hire to Retire

This list can be called a “catalog”. Similarly, there is another catalog of functions:

  • Sales

  • Contracts

  • Accounts Receivable

  • Vendor Management

  • Accounts Payable

  • Human Resources

  • IT

  • Payroll

  • Benefits

The functions appeared as rounded rectangles in the diagram.

There are pros and cons to each approach. Notice that in about the same amount of space, the matrix also documented the dependencies for two other processes and six other functions. The matrix may also be easier to maintain; it requires a spreadsheet-like tool, where the diagram requires a drawing tool. But it takes more effort to understand the matrix.

Maintaining a catalog of the concepts in a diagram becomes more and more important as the diagram scales up. Over time, the IT operation develops significant data by which to manage itself. It may develop one or more definitive portfolio lists, typically applications, services, assets, and/or technology products. Distinguishing and baselining high-quality versions of these data sets can consume many resources, and yet managing the IT organization at scale is nearly impossible without them. In other words, there is a data quality issue. What if the boxes on the diagram are redundant? Or inaccurate? This may not matter as much with a tight-knit team working on their whiteboard, but if the diagram is circulated more broadly, the quality expectations are higher.

Furthermore, it is convenient to have data such as a master lists or catalogs of processes, systems, functions, or data topics. We might also want to document various attributes associated with these catalogs. This data can then be used for operational processes, such as risk management, as we have discussed previously. For these reasons and others, Enterprise Architecture repositories emerge.

Architecture Data Management

When we establish a catalog of architectural entities, we are engaging in master data management. In fact, the architectural concepts can be represented as a form of database schema (see A Simple Metamodel).

Figure 154. A Simple Metamodel
A data model that organizes data about data and its related systems can be called a metamodel.

Material that we first saw in diagram form can be stored in a database. Systems that enable this are called Enterprise Architecture repositories. Their data schemas are often called metamodels.

Architecture repositories require careful management. A common anti-pattern is to acquire them without considering how the data will be maintained. The concepts in the repository can be subjective, and if it is intended that they be of high data quality, investments must be made. Some kind of registration process or decision authority must exist for the creation of (for example) a new, official “system” record. Misunderstandings and disagreements exist about the very meaning of terms like “system” or “technology”. (We discussed some of the general issues in Information Management, with the ontology problem.) Such issues are especially difficult when Enterprise Architecture repositories and metamodels are involved. Frequent topics:

  • Is an “application” different from a “service"? How?

  • What is the relationship between a “capability” and a “function"? Or a “capability” and a “process?”

  • How can we distinguish between “systems” and “technologies"?

  • What is the relationship between a “product” and a “service”, especially if the service is a market-facing digital one?

  • What is the relationship between:

    • Value chain

    • Value stream

    • Process

    • Activity

    • Task

And so on. We might expect that there would be industry standards clarifying such issues, and in some cases there are. In other cases, either there are no standards, or the standards are obsolete or conflicting.

Finally, there are a number of other systems that may interoperate with the architecture repository. The most important of these is the CMDB or CMS that underlies the ITSM tooling. These tools also need to know at least about systems and technologies and may be interested in higher-level concepts such as business capability. However, they usually do not include sophisticated diagramming capabilities or the ability to represent a system’s future state.

Other tools may include project management systems, portfolio management systems, risk management systems, service-level management systems, and others. Application and service master data, in particular, is widely used, and if the Enterprise Architecture repository is a System of Record for this data there will be many outbound interfaces.

An Economic View
The discussion below also applies to the CMDB as well as other similar repositories.

Part of the challenge of any repository is what data to manage. How do we think more systematically about this? First, we need to understand why we want to assemble this data in a ready-to-query repository. There are two major reasons why we store data:

  • There are no other sources for it - if we don’t establish a System of Record, the data will go unmanaged, and we won’t know what servers we have, or what applications we are running

  • There may be other sources for the data, even System of Record, but we need an operational data store to bring the various data sources together in a way that makes them more efficient to query

For either kind of data, you need to have an economic understanding of why you want it. Suppose you need to find out what applications you are running because you want to rationalize them. You could invest weeks of research into the question, costing perhaps tens of thousands of dollars worth of yours and others’ time, to create a one-time spreadsheet.

But what happens when there are multiple purposes for the data? You find out that the security group also wants a master list of applications and has been compiling a different spreadsheet, for example. What happens when the same engineers and managers are asked for the same data over and over again because there is no repository to maintain this organizational memory?

The challenge is, when does it make economic sense to pre-aggregate the data? The economic graph shown in Economic Value of the Enterprise Architecture Repository may assist in thinking about this.

econ curve
Figure 155. Economic Value of the Enterprise Architecture Repository

The graph may be familiar to those of you who studied economics. On the left, you have the assumption of no architecture repository, and on the right, you have a comprehensive architecture repository. With a less comprehensive architecture repository, you are paying some cost in research and outage impacts. You also are incurring more risk, which can be quantified. On the other hand, with a comprehensive architecture repository, you incur more costs in maintaining it. You need processes that have a direct cost to operate, as well as imposing indirect costs such as the cost of delay (e.g., if updating the architecture repository slows down the release schedule).

But in the middle is a sweet spot, where you have “just enough” architecture repository data. This optimal architecture repository scope represents the real savings you might realize from instituting the architecture repository and the necessary processes to sustain it.

This is not a complete business case, of course. Your projected savings must be offset against the costs of acquisition and operations, and the remaining “benefit” needs to exceed your organization’s hurdle rate for investments.

The IT lifecycles

We have discussed products and the various ways digital organizations deliver them, from simple work management to more sophisticated project and process management approaches. Now, we need to refine our understanding of the products themselves and how they are managed.

We previously discussed the relationship between feature versus component teams in Competency Area 4. In Competency Area 9, we touched on the idea of shared services teams. Both of these ideas are now expanded into what is called the "four lifecycle model”.

The four lifecycle model was first documented in [31]. The four lifecycles are:

  • The application service lifecycle

  • The infrastructure service lifecycle

  • The asset lifecycle

  • The technology product lifecycle

Each of these lifecycles reflects the existence of a significant concept, that is managed over time as a portfolio. (More on IT portfolio management practices in Competency Area 12.)

First, bear in mind that services are kinds of products. Digital value is usually delivered as a service, and shares standard service characteristics from an academic perspective, including the idea that services are produced and consumed simultaneously (e.g., an account lookup) and are perishable (a computer’s idle time cannot be recovered if it goes unused).

The first two concepts (application and infrastructure service) below reflect these characteristics; the second two (asset and technology product) do not.

An application service is a business or market-facing digital product, consumed by people whose primary activities are not defined by an interest in IT; for example, a bank customer looking up her account balance, or an Accounts Payable systems operator. In terms of “feature versus component”, the concept of application is more aligned to “feature”. An example would include an Online Banking system or a Payroll system.

The application service lifecycle is the end-to-end existence of such a system, from idea to retirement. In general, the realization such a system is needed originates externally to the IT capability (regardless of its degree of centralization). SaaS usage is also tracked here.

An infrastructure service is, by contrast, and as previously discussed, a digital or IT service primarily of interest to other digital or IT services/products. Its lifecycle is similar to that of the application service, except that the user is some other IT service. An example would be a storage area network system managed as a service or the integrated networking system required for connectivity in a data center. Product as a Service and IaaS are also tracked here.

Note that in terms of our service definition discussion, the above lifecycle concepts are service systems. The lifecycle of service offerings is a business lifecycle having more to do with the go-to-market strategy on the part of the firm. We covered this to some extent in Competency Area 4 and revisited it in Competency Area 12.

An asset is a valuable, tangible investment of organizational resources that is tracked against loss or misuse, and optimized for value over time. It can sit unused and still have some value. Examples would include a physical server or other device, or a commercial software license. Whether assets can be virtual is a subject of debate and specific to the organization’s management objectives (Given the licensing implications of virtual servers, treating them as assets is not uncommon.)

The asset lifecycle is distinct from the service lifecycles, following a rough order including standard supply chain activities:

  • Forecast

  • Requisition

  • Request quote

  • Order

  • Deliver

  • Accept

  • Install/configure

  • Operate

  • Dispose

A contract reserving cloud capacity is also an asset.

Finally, a technology product is a class of assets, the “type” to the asset “instance”. For example, the enterprise might select the Oracle relational database as a standard Technology Product. It might then purchase ten licenses, which are assets.

The technology product lifecycle is also distinct from both the service and asset lifecycles:

  • Identify technical requirement or need

  • Evaluate options

  • Select product (may kick off asset lifecycle)

  • Specify acceptable use

  • Maintain vendor relationship

  • Maintain product (e.g., patching and version upgrades)

  • Continuously evaluate product’s fitness for purpose

  • Retire product from environment

Cloud services need to be managed in terms of their version and interoperability concerns.

The challenge in digital management is “lining up the lifecycles” so that transactional value flows across them (see Multiple Lifecycle Model, similar to [31]).

multi-lifecycle problem
Figure 156. Multiple Lifecycle Model

This can be very difficult, as each lifecycle has a logic of its own, and there may be multiple interdependencies. A technology product may come to the end of its market life and drive expensive changes up the stack. Conversely, new application requirements may expose deficiencies in the underlying stack, again requiring expensive remediation. Technology product vulnerabilities can prove disruptive, and the asset lifecycle (representing either physical depreciation and refresh cycles, or time-bound licensing) is a significant cost driver.

The “Rationalization” Quest

“Rationalization” is often listed as one of the major outcomes of Enterprise Architecture. What is meant by this? Let’s return to our scenario of one company acquiring another. As the newly merged company takes stock of its combined assets, it becomes clear that decisions need to be made. Among other areas, redundant systems exist for:

  • Marketing

  • Human resources

  • Accounting

The digital pipelines also are inconsistent, one being based on Github and Travis CI, the other being based on local Git and Jenkins.

Decisions need to be made as to which systems will be “go-forward”. While the teams involved will have strong input into the system decisions that affect them and will do most of the work, there is concern that some overall view and coordination of the effort is required. What if teams cannot come to a consensus? What if there is an opportunity to save money by standardizing on one vendor to support multiple diverse teams? For these reasons, the company assigns an architect to work closely with the overall merger program.

A merger is a dramatic example of a rationalization scenario. Established, ongoing companies, even without mergers, find that redundancy tends to accumulate. This is a normal outcome of the innovation and commoditization cycle; when technologies are new, organizations may experiment with several providers. When they become more standardized, and commoditized, the desire for efficiency drives rationalization.

One of the challenges for rationalization is whether the economics and business context of any given rationalization effort are well understood. Consistency as an end in itself is not necessarily valuable. The impacts on enterprise value must be established: will the organization actually benefit from improved vendor leverage, operational integration, or a reduced security attack surface? If not, perhaps seeking “rationalization” is not the best use of organizational resources.

Evidence of Notability

Architecture implies a set of practices that can be controversial. Its use as a management program, its use of repositories, and its emphasis on visualization are all notable aspects that are often debated as to their value.


Architecture practices such as those discussed here are typically seen only in large organizations requiring institutional continuity.

Related Topics

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 don’t 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, a standard of The Open Group, 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 157. 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 [80], 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 the figure 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 Group Open Business Architecture (O-BA) Standard 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, Version 9.2 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 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:

  • 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

from [50 p. 2]. 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” [32 p. 125]. 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.

Technical Architecture

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

  • Identification of new technical platform capabilities: for example, does the organization need to bring in a NoSQL platform? 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 don’t 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 Internet giants’ lead, 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.

DDD 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.
— Eric Evans

The premise of DDD 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

DDD provides strategy patterns that help design loosely-coupled systems. The modular nature of a software system architected with DDD 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." 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 DDD 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. [130]
— 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.

Figure: Toward an Adaptive Enterprise Model represents an evolution of the classical enterprise model. It complements it with concepts borrowed from Agile requirements, Lean Start-up and LPPD.

Figure 158. Toward an Adaptive Enterprise Model

Let’s 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" [61] 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).

Figure: The Customer Experience’s Paradigm Shift illustrates the shift toward an outside-in approach. It 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 expectation

Figure 159. 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 [279] 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

Agile and Architecture


The relationship between architecture (both “enterprise” and other forms of architecture) and current Agile, DevOps, and digital product development approaches is too often troubled. However, the hope is that this document has given you a set of tools for resolving these concepts in a productive way.

The Agile Critique of Architecture

The goal of Enterprise Architecture is to act as a guide, perhaps a pathfinder, who takes the enterprise on a transformational journey - from an incoherent and complex world with LOB separation, product-specific stovepipes, legacy systems estate, and costly operation to a more rationally organized and useful state with multiservice, revenue-generating platforms and an efficient operational regime. On the way, radical surgeries may be required to eliminate duplication, reduce costs, improve reliability, and increase agility in the business. Enterprise Architecture acts as a strategic foundation for business enablement. [28 p. 9]

Product development organizations often experience architecture and its goals as unwarranted interference, imposing a high cost of delay with little apparent return on investment. Architecture approvals can be required on:

  • Application designs

  • Database designs

  • Selection of technology products

and other such topics. When development cannot proceed without those approvals - or if the approvals come at the cost of expensive rework - the experience can often be challenging. Bente et al. warn: “if Enterprise Architects claim to be the only decision-making body in technical matters, there is a huge risk that they create a bottleneck …​ The practical consequence is that projects deliberately circumvent the Enterprise Architects …​” [28 p. 19].

Enterprise Architecture has presented itself as a solution to complexity, long IT time scales, business frustration, and other various IT problems. These issues are at this writing being solved, but not by architecture — at least not visibly. Instead, visible and publicized progress has come through the increasing adoption of Agile and DevOps practices rethinking open-loop, slow feedback, batch-oriented delivery. Architecture has been challenged on several fronts:

  • It failed to realize the emergent issue of too much enterprise work-in-process, instead championing the proliferation of enterprise processes and their associated queues

  • Architects' motivation for “efficiency” and interest in capability mapping did not help the cause of cross-functional teams

    • Instead, functional silos were reinforced as supply-centric “capabilities”, and the project-centric anti-pattern of “bringing the team to the work” was promoted as enterprise standard operating procedure — despite the growing evidence of Scrum and Agile success. The iterative, experimental narrative of Lean Startup did not originate from Enterprise Architecture.

  • Despite a professed interest in systems theory, architecture has failed to adopt a workable systems perspective on digital delivery

    • It did not recognize the fundamental problems of stage-gated delivery, big bang releases, queue proliferation, and so forth. Architecture “gap” analysis resulted in project recommendations, again “bringing the team to the work”.

  • Architecture has often deserved the criticism of “top-down planning”, which in complex systems domains too often doesn’t work

    • Architects frequently fall into the trap of the HiPPO. A sense of Lean Startup experimentation, of placing bets on options and testing hypotheses, is not part of the mainstream Enterprise Architecture culture. Instead, the architecture is presented as an established fact, with “governance” to ensure conformity. Hypothetical “synergies” emerging from “common platforms” are often offered as justification for architecture, with little follow-up in measuring actual value delivered.

Justifications for architecture often invoke “complexity” in the portfolio of systems. In response, architecture has often given in to the desire for a complete “radical surgery” systems re-engineering, the temptation of the “clean slate”. But as Jez Humble accurately notes:

A common response to getting stuck in a big ball of mud is to fund a large systems replacement project. Such projects typically take months or years before they deliver any value to users, and the switchover from the old to the new system is often performed in “big bang” fashion. These projects also run an unusually high risk of running late and over budget and being canceled. Systems re-architecture should not be done as a large program of work funded from the capital budget. It should be a continuous activity that happens as part of the product development process. [137], Chapter 10.

Architecture methodology, with its focus on identifying capability gaps for feeding into the project portfolio process, has perhaps been too prone to supporting these large, troubled programs. As we know from our earlier Competency Areas, large system changes are inherently risky, and any intervention into a complex system is better undertaken as a series of smaller, incremental changes with frequent monitoring and assessment.

The Architecture Critique of Agile

The Agile community has its own blind spots and challenges. Speed is seen as a good in itself, too often without an economic model. Agile teams often clash with enterprise governance processes that have sound compliance and financial benefits. Phrases like “you aren’t gonna need it” are used to justify lapses of due diligence on critical capabilities, and standard platforms and vendors are seen as unreasonable limitations on team autonomy — to the point where it seems some teams' interest is primarily in padding their resumes with as many new technologies as possible, regardless of the long-term consequences for the organization.

The Limitations of Cost of Delay

Cost of delay is a real and often overlooked issue, in understanding the net value of architecture. But it is only a factor and does not eliminate the value proposition of architecture. If the cost of delay is only a few hundred dollars a month, but the risk or technical debt represents millions, then the delay may be appropriate. Don Reinertsen, who has done more than anyone to promote the idea of cost of delay, emphasizes that all decision-making must take place within an economic framework and that means that the other architectural impact factors on organization value must also be considered [230], Chapter 2.


Documentation has been a core concern of the Agile movement, being mentioned in one of the four core principles of the Agile Manifesto:

"Working software over comprehensive documentation.” [8]

When documentation primarily takes the form of secondary artifacts, it is appropriate to question the need for it. “The code is the documentation”, some will argue. While it is true that good coding practices result in easier-to-understand (and maintain) source code, the code cannot be the only documentation. As Ruth Malan notes:

…​ for systems of sufficient scope and complexity to warrant teams (of teams) working on (incremental) implementation and evolution, the sheer mass of code can make it hard to discover the essential structure from bottom-up decisions made entirely through the medium of code. [186]

In terms of systems theory, a complex software system has emergent behavior, not obvious from just looking at its components. Because the system’s behavior can’t be reduced to its pieces, “self-documenting code” can only go so far. The behavior of the assembled components as a system needs to be represented somehow, in a way that transcends the mere mechanics of the pieces. Abstraction is necessary to understand and communicate emergent behavior, and this leads inevitably to visual representation. Without some attention to documenting overall context and systemic intent and behavior, the effectiveness of the overall human/computer system degrades. For example, Alistair Cockburn reports that the Chrysler Comprehensive Compensation project, one of the first widely reported Agile projects, was eventually halted, and:

…​ left no archived documentation …​ other than two-sentence user stories, the tests, and the code. Eventually, enough people left that the oral tradition and group memory were lost. [65 pp. 41-43]

In short, failure to sustain a shared mental model of a complex system is a risk that may result in loss of that system’s value.

Sourcing and Technology Standards

Agile and DevOps are software development-centric, and have transformed that world. However, digital organizations don’t always build everything. There is a complex web of supplier relationships even for organizations with robust software development capabilities, and many organizations would still prefer to “buy rather than build”. Software may be consuming the world, but that doesn’t mean everyone employs — or should employ — software developers. Agile has not had a primary focus on sourcing, and evaluating commercial software is not a common Agile topic.

Suppose you have an idea for a digital product, and you know that you will be (at least in part) assembling complex services/products produced by others? Suppose further that these provided services overlap (the providers compete)? You need to carefully analyze which services you are going to acquire from which provider. You will need a strategy, and who is it that analyzes these services and their capabilities, interfaces, non-functional characteristics, and makes a final recommendation as to how you are going to bring them all into one unified system?

It is easy to say things like: “the teams get to define their own architecture”, but at some point, the enterprise must reckon with the cost of an overly diverse supplier base. This is a very old topic in business, not restricted to IT. At the end of the day, supplier and sourcing fragmentation costs real money. Open source, Commercial-Off-The-Shelf (COTS), cloud, in-house …​ the options are bewildering and require experience. In a sense, the supplier base itself is an inventory, subject to aging and spoilage. (We can consider this another way of understanding technical debt.) A consistent evaluation approach is important (preferably under an economic framework; see Reinertsen & Hubbard). And at some point, product development teams should not have to do too much of their own R&D on possible platforms for their work.

Architecture as Emergent

The Agile Manifesto is well known for saying: “The best architectures, requirements, and designs emerge from self-organizing teams” [8]. This is one of the more frequently discussed Agile statements. Former Netflix CTO Adrian Cockcroft has expressed similar views (quote above).

A key question is whether “architecture” is considered at the single product or multi-product level. At the single product level, collaborative teams routinely develop effective software architectures. However, when multiple products are involved, it is hard to see how all the architectural value scenarios are fulfilled without some investment being directed to the goals of cross-product architectural coordination. It helps when rules of the road are established; both Amazon and Netflix have benefited from having certain widely-accepted platform standards, such as “every product communicates through APIs”. Netflix had for a long time a long-term commitment to Amazon cloud services; it was not acceptable for teams there to decide on a whim to deploy their services on Google Compute Engine™ or Microsoft Azure™, so at least in that sense Netflix has an architecture. The question gets harder when layered products and services with complex lifecycle interactions are involved.

Microservices can reduce the need for cross-team coordination, but coordination needs still do emerge. For example, Mike Burrows of Google provides a detailed description of the Chubby lock service [49], which is a prototypical example of a broadly-available internal service usable by a wide variety of other products.

The purpose of a lock service is to “allow its clients to synchronize their activities and to agree on basic information about their environment”. Chubby was built from the start with objectives of reliability, availability to a “moderately large set of clients”, and ease of understanding. Burrows notes that even with such a cohesive and well-designed internal service, they still encounter coordination problems requiring human intervention. Such problems include:

  • Use (“abuse”) in unintended ways by clients

  • Invalid assumptions by clients regarding Chubby’s availability

Because of this, the Chubby team (at least at the time of writing the case study) instituted a review process when new clients wished to start using the lock manager. In terms of Competency Area 7, this means that someone on the product team needed to coordinate the discussions with the Chubby team and ensure that any concerns were resolved. This might conceivably have involved multiple iterations and reviews of designs describing intended use.

Thus, even the most sophisticated microservice environments may have a dependency on human coordination across the teams.

Towards Reconciliation

So how do we reconcile Agile with architecture practices, especially Enterprise Architecture and its concerns for longer lifecycles, aggregate technical debt, and governance? We need to understand why we look to architecture, what utilizing it means, and how it ultimately adds value, or doesn’t, in the organization.

Why: Creating the Context

One principle throughout this document has been “respect the team”, because true product value originates there. If teams are constantly fragmented and their cohesion degraded by enterprise operating models and governance mandates, their ability to creatively solve business problems is hampered. Command and control replace emergence, motivation declines, and valuable creativity is lost. Enterprise Architecture must first and foremost protect the precious resource that is the high-performing, collaborative, creative team. As we have discussed, imposing multiple governance checkpoints itself adds risk. And while it is inevitable that the team will be subject to organization-wide mandates, they should be given the benefit of the doubt when autonomy collides with standardization.

When Enterprise Architecture takes on true Business Architecture questions, including how digital capabilities are to be enabled and enhanced, Agile insights become an input or kind of requirement to Business Architecture. What capabilities require high-performing, cross-functional teams? What capabilities can be supported by project-based temporary teams? And what capabilities should be outsourced? The more valuable and difficult the work, the more it calls for the careful development of a common mental model among a close-knit team over time. Driving organizational capability investment into long-running team structures becomes a strategy that organizational architects should consider as they develop the overall organizational portfolio.

Architecture adds value through constraining choices. This may seem counterintuitive, but the choice is often between re-using a known existing platform or engaging in risky R&D of alternatives. R&D costs money, and itself can impose a delay on establishing a reliable digital pipeline. But ultimately, the fundamental objective remains customer and product discovery. All other objectives are secondary; without fulfilling customer needs, architectural consistency is meaningless. Optimizing for the fast creation of product information, tested and validated against operational reality, needs to be top of mind for the architect.

What: The Architecture of Architecture, or the Digital Pipeline Itself

The digital pipeline ultimately is a finely-tuned tool for this creation of information. It, itself, has an architecture: business, application, and technical. It operates within an economic framework. To understand the architecture of the digital pipeline is in a sense to understand the “architecture of architecture”.

As we have discussed above, architecture, like staff functions generally, is in part a coordination mechanism. It collects and curates knowledge and sustains the organization’s understanding of its complex systems. Architecture also identifies gaps and informs the investment process, in part through collecting feedback from the organization.

If architecture’s fundamental purpose is enabling the right emergent behavior, there are still questions about how it does so. Architecture adds value in assisting when:

  • Systems are too big for one team

  • Features are too complex to be implemented in one iteration

  • Features require significant organizational change management

As a coordination mechanism, it can operate in various ways including planning, controlling, and collaborating. Each may be appropriate for a given challenge or situation. For example, different approaches are required depending on whether the product challenge is flower or cog. A flower is not engineered to fill a gap. A cog is. Market-facing experiments need leeway to pivot, where initiatives intended to fill a gap in a larger system may require more constraints and control. And how do architects know there is a gap? It should be an hypothesis-driven process, that needs to establish that there is a valuable, usable, feasible future state.

How: Execution

As an executing capability, architecture operates in various ways:

  • Planning and analysis

  • Governance and approvals

  • Collaboration and guidance

Ideally, planning and analysis occur “upstream” of the creation of a product team. In that guise, architecture functions as a sort of zoning or planning authority — “architecture” is not a process or organization directly experienced by the product team. In this ideal, there is no conflict with product teams because once the team is formed, the architect’s job is done. However, this assumes that all the planning associated with launching a new product or capability was done correctly, and this itself is a kind of waterfall assumption. Some form of feedback and coordination is required in multi-product environments.

It is in the “governance and approval” kind of activity that conflict is most likely to emerge. Cadence and synchronization (e.g., coordination strategies) with the potential to block teams from pursuing their mission should be very carefully considered. If there is a process or a queue of architecture approvals, it at least should be operated on cost of delay of the work it is blocking. And more generally, across the organization, the process should be tested against an economic model such as establishing a nominal or portfolio-level cost of delay. Like other processes, architecture itself can be assessed against such a baseline.

Queued approvals are only one way of solving issues. A rich and under-utilized approach is using internal market-type mechanisms, where overall rules are set, and teams make autonomous decisions based on those rules. Don Reinertsen, in the Principles of Product Development Flow, discusses how Boeing implemented distributed decision-making through setting trade-off rules for cost and weight. Rather than constantly routing design approvals through a single control point, Boeing instead set the principle that project managers could “purchase” design changes up to $300 per unit, to save a pound of weight. As Reinertsen notes:

The intrinsic elegance of this approach is that the superiors didn’t actually give up control over the decision. Instead, they recognized that they could still control the decision without participating in it. They simply had to control the economic logic of the decision. [230 p. 42]

One particular work product that architects often are concerned with is documentation. The desire for useful documentation, as mentioned above, reflects architecture’s goals of curating a common ground for collaboration. As Bente notes: “In an Agile project, explicit care must be taken to ensure proper documentation; for example, by stating it as part of the condition of satisfaction of a user story or in the definition of done.” [28 p. 170]

Architecture Kata

Toyota Kata was discussed in Organization and Culture. In Lean Enterprise, Jez Humble et al. argue that it can provide a useful framework for architecture objectives. Toyota Kata emphasizes end-state goals (“target conditions”) and calls for hands-on investigation and response by participating workers, not consultants or distant executives. Architecture can benefit by understanding “gaps” in the sense of Toyota’s target conditions, and then support teams in their collaborative efforts to understand and achieve the desired state. The architectural impact model can assist in thinking through suitable target conditions for architecture:

  • Top-line impact through re-use (lowering cost of delay)

  • Bottom-line impact through portfolio rationalization

  • Risk impact through minimizing attack surface and re-use of known good patterns and platforms

Keeping the target operating condition specific is preferable. When architecture scopes problems too broadly, the temptation is to undertake large and risky transformation programs. As an alternative, Humble suggests the "strangler pattern”, proposed by Martin Fowler in 2004 [102]. This pattern uses as a metaphor Australian “strangler” vines that grow around trees until the original tree dies, at which point the strangler vine is now itself a sturdy, rooted structure.

To use the strangler pattern is not to replace the system all at once, but rather to do so incrementally, replacing one feature at a time. This may seem more expensive, as it means that both the old and new systems are running (and cost savings through sunsetting the old system will be delayed). But the risk of replacing complex systems is serious and needs to be considered along with any hoped-for cost savings through replacement. Humble and Molesky suggest:

  • Start by delivering new functionality - at least at first

  • Do not attempt to port existing functionality unless it is to support a business process change

  • Deliver something fast

  • Design for testability and deployability

The strangler pattern is proven in practice. Paul Hammant provides a large number of strangler pattern case studies, including:

  • Airline booking application

  • Energy trading application

  • Rail booking application

and others [120].

Of course, there are other ways architecture might add value beyond system replacement, in which case the strangler pattern may not be relevant. In particular, architects may be called on to closely collaborate with product teams when certain kinds of issues emerge. This is not a governance or control interaction; it is instead architecture as a form of shared consulting “bench” or coordination mechanism. Not every product team needs a full-time architect, the reasoning goes, so architects can be assigned to them on a temporary basis; e.g., for one or a few sprints, perhaps of the technical “spike” (discovery/validation/experimentation) variety.

The Challenge of the “Hands-On” Architect

Architect is a broad category. It includes individuals who are talented at single-product designs, as well as those tasked with managing the overall interactions between hundreds of systems.

The solution architect needs to have hands-on technical ability. Many Agile authors are dismissive of “ivory-tower” architects who do not do “hands-on” work and, in fact, if an architect is going to sit with a technical team as a solutions advisor they clearly need the technical skills to do so. On the other hand, not all architects operate at the solutions level, nor are the problems they face necessarily programming problems.

It is well and good for architects to maintain some technical facility, but in the case of true, portfolio-level Enterprise Architects, how to do so may not be obvious. What if someone’s portfolio includes multiple platforms and languages? It is simply not possible to be hands on in all of them. Some of the most challenging systems may be a complex mix of commercial product and customization; e.g., ERP or core banking systems. Choosing to be “hands on” may not even be welcomed by a given team, who may see it as meddlesome. And other teams may feel the architect is “playing favorites” in their choice of platform to be “hands on” with.

Clearly, if the organization is running primarily on (for example) Node.js, having strong JavaScript skills is important for the architect. But in more heterogeneous environments the architect may find strong data management skills to be more useful, as often interfaces between systems become their primary concern.

Another form of being “hands on” is maintaining good systems administration skills, so that the architect can easily experiment with new technologies. This is different from being adept in a given programming language. One recent positive trend is lightweight virtualization. In years past, experimenting with new products was difficult on two fronts:

  • First, obtaining high-performance computing resources capable of running demanding software

    • Sometimes these resources needed unusual OSs (e.g., “in order to try our software, you have to run it on a specific version of a well-known OS on a specific hardware platform” — not a capability most architects had in their back pocket).

  • Second, obtaining a demonstration version of software from vendors, who would usually start a sales cycle if you asked for it

Times have changed. Demonstration versions of software are increasingly available with little overhead or risk of triggering unwanted sales calls. Platform requirements are less diverse. And lightweight virtualization (e.g., the combination of Vagrant and Virtualbox) now makes it possible for architects to be hands on; modern laptops can run multiple virtual machines in cluster architectures. Significant experimentation can be carried out in working with systems of various characteristics. Being able to evaluate technologies in such a virtual lab setting is arguably even more useful than being a “coding architect”. Product team developers do the programming; the architect should be more concerned with the suitability and feasibility of the integrated platform.

Evaluating Architecture Outcomes

Finally, how do we evaluate architecture outcomes? If an organization adopts an experimental, Toyota Kata approach, it may find that architecture experiments run on long time horizons. Maintaining an organizational focus on value may be challenging, as the experiments don’t yield results quickly. Curating a common ground of understanding may sound like a fine ideal, but how do we measure it?

First, the concept of Net Promoter Score is relevant for any service organization, internal or external. Its single question: “Based on your experience, on a scale of 1-10 would you recommend this product or service to a friend?” efficiently encapsulates value in a single, easy to respond to query.

As digital pipelines become more automated, it may be possible to evaluate their digital exhaust impact on architecture services:

  • Are architecture standards evident in the source and package managers?

  • Are platform recommendations encountering performance or capacity challenges?

In a world of increasing connectivity and automation, there is no reason for architects in the organization to lack visibility into the consequences of their recommendations. Ultimately, if the cost of operating the coordination mechanism that is architecture exceeds the value it provides, then continuing to operate it is irrational.

Evidence of Notability

Agile, DevOps, and architecture often come into contact and even conflict. This friction carries many consequences for organizations wishing to digitally transform, yet not abandon the benefits of architecture.


The intersection of Agile and architecture is most significant in organizations that are performing their own digital R&D (i.e., software development).

Related Topics

Architecture, Digital Strategy, and Portfolio


The aggregate digital investments of any large enterprise are massive. Whether capital or expense, whether internally hosted or externally sourced, the IT portfolio consumes tremendous amounts of time, money, and expertise. In this chapter, we have discussed architecture in terms of catalogs, diagrams, and matrices, sometimes stored in architecture repositories. But architecture repositories are in general not analytic tools. Nor is architecture an analytic discipline (it is not usually strongly quantitative). Architecture too often relies heavily on interviews and expert opinions, approaches that are sometimes critiqued as relying on the “HiPPO”. Portfolio management can be a means to bring in a more quantitative approach.

We first discussed portfolio management in Portfolio Management. How do we define portfolio? [32] defines it as: “things of consequence managed over a long time horizon”. The concept of the TOGAF catalog is a good place to start. Frequently, portfolio management starts at the application level; the application portfolio can be seen as a sort of alternate “chart of accounts” by which digital investments can be grouped.

Portfolios are intended to provide a consistent basis for comparison and understanding. Items in the portfolio should be comparable. They may rely on both objective and subjective data points:

  • Objective data

    • Business revenue/value

    • Cost

    • Risks

    • Staffing

    • Service levels, changes, incidents

    • Product obsolescence (quantifiable technical debt)

  • Subjective data

    • Usability

    • Customer satisfaction (net promoter score)

    • Engineering assessments (subjective perceptions of technical debt)

Digital investments and costs typically include some or all of the following:

  • Hardware investment, depreciation or leasing

  • Software licensing (typically 15%-20% annually of initial acquisition, required for vendor support)

  • Floor space; i.e., real estate charges

  • Facilities infrastructure: power, High Volume Air Conditioning (HVAC), raised floor, racks, etc.

  • Network connectivity and related infrastructure (e.g., directory services software, security perimeters, and the like)

  • Operational software infrastructure: monitoring systems, batch schedulers, backup systems, and so on, all with their own associated costs

  • Operations and support staff; staffing typically can come in various flavors:

    • Data center operations monitors

    • Help desk operators

    • Application specialists

    • Senior engineers

    • Senior IT executives and customer relationship managers

    • Business-side lead users and process and information specialists

    • Vendor relationship owners and contract managers

Application Value Analysis

APM may concern itself with any or all of the following:

  • Business or financial value of applications in terms of what they support/enable

  • Application functions (examined for redundancy)

  • Application total cost of ownership

  • Application complexity

  • Fitness and currency of underlying technical products

  • Application service performance

  • Application customer feedback

A four-box is often used for application value analysis:

Table 31. Standard IT portfolio “4-box”
Low Technical Fitness High Technical Fitness

High Business Value

Re-engineer or replatform

Consider outsourcing carefully

Invest as needed to exploit value

Low Business Value

Retire if possible or outsource

Improve understanding of customer requirements

Retire service if no longer serving a purpose but reclaim/re-use platform, capabilities, and assets

Application Rationalization

What does it mean to rationalize"? There are three steps:

  • Take an inventory of the items to be rationalized

  • Categorize them to identify redundancy

  • Consolidate redundancy

This implies some basis for classification so that the investments can be compared. This is where industry taxonomies, such as found in industry reference architectures, may help. You may call your application “Peoplesoft HR”, “Workday”, or even an internal brand like “HR2020”, but a reference taxonomy categorizes it as simply a “Human Resources Management System”.

Data integrations may also be a way to identify redundancy. When two systems start exchanging more and more data, a useful question is whether there is still a need for both or if a more economical, integrated solution is possible. Just beware of the risk of overly ambitious consolidation efforts.

Through analysis and understanding of redundancy and business and technical value, applications (and related concepts such as services and capabilities) can be managed as a coherent investment strategy. For further information, see the books referenced at the end of this chapter.

Evidence of Notability

Architecture is often called on to rationalize complex assemblies of systems; for example, in the case of an organizational merger. This is some of the most challenging and high-value work in the digital/IT industry.


A fully rational, planned approach to portfolio rationalization is extremely difficult, as complex portfolios are dynamic sociotechnical systems and radical interventions frequently give rise to unexpected, emergent responses.

Related Topics

1. Public domain assumed.