• bhablutzel

Post-Modern Enterprise Architecture

The history of Enterprise Architecture (EA) has been described in three phases: Business Systems Planning, Early EA, and Modern EA. 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 Post-Modern era of Enterprise Architecture.


For detailed background of the three phases, I'd recommend Svyatoslav Kotusev's excellent paper on The History of Enterprise Architecture. In that paper, the author documents three phases:

  1. Business System Planning (1960s-1980s)

  2. Early EA (1980s-1990s)

  3. Modern EA (1990s-present)

Let's look at each of these in context.

Business Systems Planning

Business Systems Planning, or BSP, was an IBM methodology for implementing technology systems. The methodology had a set of structured activities executed by trained BSP experts in behalf of a customer.

Contextually, BSP came out of an environment with 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 in order 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 $17,270,438 in November 2022 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). Remember too that 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 flip side 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. So planning was the name of the game.

Early EA

The Early EA period is characterized by the first attempts to create an EA 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. Later during this period other frameworks (NIST, EAP) appears, seeking to add some process structure on top of the categorical breakdowns that Zachman championed.

The context for Early EA builds on top of the success of the BSP era. Information technology is becoming well established as a necessary for a competitive company, and the talent pool has increased dramatically. Agile programming is still a ways away however, and the traditional waterfall methodology reigns supreme.

The information technology 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 meant more incremental approaches were 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 department muddied the waters of where and how decisions were being made. Where in the BSP era the value of EA was often in deciding which parts of the business would be adopting IT, in the EA era it started to become about understanding where there were overlaps and gaps.

Modern EA

The modern EA 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, etc. - are brought together in a "best of breed" approach. What's lost in this translation is an understanding of the fundamental shifts in the relationship between technology and the business. Where in the early days technology was esoterica, in the modern EA era it became ubiquitous. Where in the early days the cost-curve for capital expense was deeply stepwise, in the modern EA era the curve continued to smooth (and today with the cloud is effectively continuous). Where in the early days most systems had to start from scratch, in the modern EA era the palette of available vendor and open-source software has dramatically impacted the time to market. Agile development cycles have cut waste from the system by enabling flexible, experimental cooperation between product owners and engineers.

In many ways, the predominant EA 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" EA, as described in the paper, is the perfect realization of what was needed back when mainframes were king. Had we had Modern EA in the 1960s, we would have killed the competition. Today, however, we need to go back and question the assumptions that went into the fine tuning of EA frameworks: the cost structures, availability of talent and tools, and breadth of problems that were being addressed.

We need Post-Modern EA.

Post-Modern EA

Post-Modern EA 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 build 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 we, and our business partners, can adapt for use in our latest customer experience.

In this post-modern world, we need an enterprise architecture function that is built for today. Good news: We don't have to start from scratch. There is a lot of good that has been developed in the journey to Modern EA. But we do have to consider how to use those tools cost effectively.

The Post-modern EA framework has five major components: Platform, Technology, Operations, Enablement, and 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 becomes a backward flow in older ones.

The Post-Modern EA Framework

The first component, Platform, defines the landscape of what we should (and shouldn't) be building. The focus here is on the customer experience and how we can support it. We will explicitly prioritize capabilities that we differentiate ourselves on and exclude those that we can attain from the marketplace. We will also focus on the inter-relationship between the platforms - their 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 all these three architectures are deeply interconnected. This component also includes 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 and we need to have well-defined operating model for periods of increased traffic, interruption of service, 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 that you expect your teams to use. Since technology is in constant motion, we also include structured models for innovation, and for harvesting & hardening emerging new best practices from the teams.

Finally, though we don't always love this part of the role, there is Governance to consider. The focus here isn't on being punitive, but on being transparent. Governance is where we define the architectural operating models, create the as-is and to-be heatmaps, and provide for escalations. As in the top tier, the bottom tier is highly cyclic. Governance without guidance is just mean so we focus on Enablement first, when then enables Governance as needed. This component also takes and combines all the metrics from the others, giving the business visibility into how well the organization as a whole is performing.


Modern EA has a traceable history back to the days when information technology was rare, expensive, and risky. Post-modern EA reconsiders what is actually 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.

Next time: Post-modern EA in a multi-line of business organization