Welcome to the postmodern enterprise architecture era

You can describe the history of enterprise architecture in three phases: Business systems planning, Early enterprise architecture, and Modern enterprise architecture. Looking at these three phases and the associated changes in the information technology industry, I propose that we've entered a new phase, which I'll dub the postmodern era of enterprise architecture.

I recommend Svyatoslav Kotusev's excellent paper on The history of enterprise architecture for a detailed background of the three phases, which are:

1. Business system planning (1960s-1980s)
2. Early enterprise architecture (1980s-1990s)
3. Modern enterprise architecture (1990s-present)

I'll look at each of these in context.

[ Learn how IT modernization can help alleviate technical debt. ]

Business systems planning

Business systems planning (BSP) was an IBM-developed methodology for implementing technology systems. The methodology had a set of structured activities executed by BSP experts on behalf of a customer.

Contextually, BSP came out of an environment with a limited understanding of the potential for implementing business automation. Programming languages (RPG-II, FORTRAN, COBOL) were complex, the development cycle was slow, and examples were rare. Some companies had in-house staff, but many still had to negotiate multi-year contracts to implement major systems.

Most importantly, consider the capital costs for systems in those days. When the IBM 370 was introduced, the typical entry-level model 155 cost $2,248,550, or more than $17 million in today's dollars. The model 165 was about twice that. That's a non-trivial amount of money (and that's just the raw hardware, not the maintenance agreement, software, or development costs). Also in those days, data processing was considered a cost center, not a strategic enabler.

These factors led to understandable caution. Mainframes tend to run best up to about 95% utilization; on the flipside, you are wasting money if you don't keep your mainframe at or above 80% utilization. The risks of failure were great, and failure was not just the implementation of the project itself but the opportunity costs of losing several years compared to peers. Planning was the name of the game.

Early enterprise architecture

The early enterprise architecture period is characterized by the first attempts to create an enterprise architecture framework separate from the planning process. The PRISM and Zachman frameworks sought to understand the stakeholders and drivers for a successful system and to codify those into a general form that could be used across projects and industries. Other frameworks (NIST, enterprise architecture planning [EAP]) appeared later in this period, seeking to add some process structure on top of the categorical breakdowns that Zachman championed.

Early enterprise architecture built on the success of the BSP era. Information technology became well-established as necessary for a competitive company, and the talent pool increased dramatically. Agile programming was still a ways away and the traditional waterfall methodology reigned supreme.

The IT landscape was also changing—slightly—by the 1980s. Departmental computers (VAXen, AS/400s) had arrived along with an opportunity to get more granular on acquisition costs. Lower costs made more incremental approaches available. The cost curve remained a step function, but now the granularity was in the thousands, not the millions of dollars.

The relatively lower costs of departmental computers created a new problem: portfolio management. More fragmentation between the central systems and the line of business or individual departments muddied the waters of where and how decisions were made. Whereas in the BSP era the value of enterprise architecture was often in deciding which parts of the business would be adopting IT, in the enterprise architecture era, it started to become about identifying overlaps and gaps.

Modern enterprise architecture

The modern enterprise architecture era is all about codification. TOGAF and DODAF codified approaches to enterprise architecture with opinionated process flows and dependencies. The Clinger-Cohen Act codified the need for enterprise architects in US government agencies—even when it wasn't completely clear what the value of that requirement was.

During this time, all the previous work—BSP, Zachman, NIST, and so forth—came together in a "best of breed" approach. What's missed in this translation is an understanding of the fundamental shifts that occurred in the relationship between technology and business. Whereas in the early days technology was highly specialized, in the modern enterprise architecture era it became ubiquitous. Where in the early days the cost curve for capital expense was deeply stepwise, in the current enterprise architecture era the curve began to smooth (and today, with cloud, it is effectively continuous). Similarly, in the early days most systems had to start from scratch, but in the current enterprise architecture era, the palette of available vendor and open source software dramatically impacted the time to market. In the early days, waterfall methodologies reigned but in the modern era, agile development cycles began to cut waste from the system by enabling flexible, experimental cooperation between product owners and engineers.

[ Learn more about TOGAF and the history of enterprise architecture. ]

In many ways, the predominant enterprise architecture frameworks (TOGAF, DODAF) are blissfully unaware of these modernizations. They still have a fairly structured approach, starting with an understanding of the business capability landscape, moving on to the information and technology architectures (which are distinct), and then on to operational concerns like implementation planning.

Modern enterprise architecture, as described in Kotusev's paper, is the perfect realization of what was needed back when mainframes were king. If a business had modern enterprise architecture in the 1960s, it would have killed the competition. Today, however, we need to go back and question the assumptions that went into the fine-tuning of enterprise architecture frameworks: the cost structures, availability of talent and tools, and breadth of problems being addressed.

We need postmodern enterprise architecture.

Postmodern enterprise architecture

Postmodern enterprise architecture is geared toward the computer science world as we understand it today. The talent pool has greatly expanded, and while there are still talent shortages, the ability to build and retain a high-performing team is within any company's grasp. The software and hardware building blocks have greatly matured; computing environments can be set up or resized in minutes, and complex user experiences can be built out of commodity parts.

The wall between the business and engineers is crumbling, with cross-functional agile teams working together to incrementally improve with each (anytime you need to) release. Instead of systems, we are thinking more and more about platforms that both architects and our business partners can adapt for use in the latest customer experience.

In this postmodern world, we need an enterprise architecture function that is built for today. Good news: We don't have to start from scratch. We have developed many great practices and utilities on the journey to modern enterprise architecture, and now we must consider how to use those tools cost-effectively.

[ Check out Red Hat Portfolio Architecture Center for a wide variety of reference architectures you can use. ]

The postmodern enterprise architecture framework has five major components:

• Platform
• Technology
• Operations
• Enablement
• Governance

These aren't cyclic, though there is some natural flow from platform through technology to operations. That flow is strongest in new systems, and is a backward flow in older ones.

Image

The first component, platform, defines the landscape of what architects should (and shouldn't) be building. The focus is on the customer experience and how architects can support it. It explicitly prioritizes capabilities that the organization differentiates itself on and excludes those that it can obtain from the marketplace. It also focuses on the interrelationship between the platforms—their service-level agreements (SLAs), APIs, and contracts.

The technology component embodies the entire engineering effort for creating a system. This includes data, software, and infrastructure, holistically building on the realization that these three architectures are deeply interconnected. This component also consists of the experimentation and validation cycles, both within an agile team and with the customer audiences.

The operations component focuses on running the site in production. Remember, this framework isn't a cycle; the operations component creates requirements for the technology component as much as the platform component does. (For example, there is a technology requirement around instrumentation in order for the operations functions of monitoring to work.) Realistically, though, this is a separate phase of the system's lifecycle. We need a well-defined operating model for periods of increased traffic, service interruption, and the like.

Where the top of the framework focuses on the systems, the bottom focuses on management. You can't expect teams to work at the highest level if you don't clearly articulate what you want them to do. Enablement focuses on creating and disseminating the standards, frameworks, and best practices you expect your teams to use. Since technology is in constant motion, the framework also includes structured models for innovation and for harvesting and hardening emerging new best practices from the teams.

Finally, though architects don't always love this component, they must consider governance. The focus isn't on being punitive but on being transparent. Governance is where you define the architectural operating models, create the as-is and to-be heatmaps, and provide for escalations. Like the top tier, the bottom tier is highly cyclic. Governance without guidance is just mean, so focus on enablement first, which enables governance as needed. This component also receives and combines all the metrics from the others, giving the business visibility into how well the organization as a whole is performing.

Wrap up

Modern enterprise architecture has a traceable history back to the days when IT was rare, expensive, and risky. Postmodern enterprise architecture reconsiders what is driving computer science today: platforms, cloud computing, agile development, and reusable libraries. The result is a more flexible framework that still gives the business visibility into the portfolio without creating friction with the modern engineering environment.

[ Learn about upcoming webinars, in-person events, and more opportunities to increase your knowledge at Red Hat events. ]