Principle Based Enterprise Architecture

The Principle Based Enterprise Architecture (PBEA) Method is a proven approach for implementing an enterprise-wide architecture practice in large- and medium-sized technology organizations. 

The method begins with a set of architecture objectives linked to concepts that matter to the business. It then lays out how to build technology platforms from components we call assets and how to manage those assets over time, through the calculation and management of technical debt.

The PBEA method grew from the experience of watching how large technology organizations function (or do not function as the case may be). 

The Principle Based Enterprise Architecture is available in all publishing formats from Amazon.com and from Technics Publishing

Hierarchy and Boundaries

Architecting systems and data involves hierarchical decomposition.  In other words, when we refer to a thing, we must be very clear about what is inside the thing and what is outside, as well as how requests from the outside access data on the inside. Between the inside and the outside is the encapsulation boundary.

In the Principle Based Enterprise Architecture model, the fundamental building blocks of solutions are called assets. There are system assets and there are data assets. Assets may be as big or as small as you wish, but whatever granularity you decide, should be appropriate so that the inventory of assets are neither too many nor too few (They should be ‘just right’). 

Inside an asset are modules.  Modules are the logical, functional building blocks of the asset.  Assets are organized into larger groupings called asset domains.  A well-structured technology organization is organized by domain (so that an organization unit owns a domain) and a small group within that unit owns an individual asset, with a single individual named the asset owner, whose responsibility and accountability is the asset end-to-end and cradle-to-grave. 

Domains are grouped into platforms.  Applications are built upon a platform.  In other words, applications, which provide the end-user interface, use the platform to provide functions that are common across many applications.  Applications are not part-of a platform.  Applications call the service interfaces provided by the system assets in the platform.  An enterprise’s technology landscape is composed of one or more platforms and one or more applications.

Logically, from the top:

  • Enterprises have one or more platforms upon which run one or more applications
  • Platforms are composed of one or more domains.
  • Domains are composed of one or more assets.
  • Assets are composed of one or more functional modules.
  • Assets (and modules) talk to each other through one or more well-defined interfaces.

Physically (from the bottom):

  • Functional modules are implemented as one or more code modules.
  • One or more code modules are released as a package.  Packages are versioned.
  • Multiple packages (including software asset packages, such as operating systems) are built into an image.
  • One image is deployed onto one or more compute instances (which may be physical or virtual).
  • Instances are grouped into stacks (which may be inside other stacks) and are deployed in VPCs (Virtual private clouds).
  • Alternatively, packages may be deployed into serverless infrastructure, such as AWS lambda, in which case there are no images, instances or stacks required for physical operation.
  • Packages may also be downloaded by clients outside the enterprise.  For example, an application package may be downloaded and run in a client’s browser.  The application, in turn makes interface calls to the public interfaces of assets running inside the Enterprise.

Each hierarchical unit in the model has a boundary, through which public interfaces may be called by things outside, to get at the things inside. 

The above bears repeating.  The most important things represented by an architecture are encapsulation boundaries, what is inside the boundary, what is outside the boundary and which interface(s) pierce the boundaries.  In a logical diagram, enterprises, platforms, domains, assets and modules all represent boundaries, therefore they have insides and outsides.  In a physical diagram, packages, images, instances, stacks and VPCs all represent boundaries.

Why I wrote “Principle Based Enterprise Architecture”

I began my career as a software developer. I wrote code. I was only responsible for the code that I wrote, not for the complete system and not for the work of others. As I advanced in my career, I became a team leader and then a software development manager. I became responsible for the work of others. That is when I first started to notice the difference in output from different developers. Some developers produced code 10 times or even 100 times as fast as others. I do not mean that they produced 10 times as much code in the same time period. I mean they produced 10 times as much functionality, sometimes with one-tenth as many lines of code. Some people’s code was consistently the root cause of a software crash and other people’s code rarely was. And strangely, the people who produced the most functionality the fastest also tended to be the ones seldom responsible for system crashes. And when they were the ones responsible, the underlying cause was often found and fixed quickly.

As I advanced further in my career, not only was I responsible for the output of a reasonably sized team of software developers, but I was also the individual representing that team in larger company meetings. That was when I noticed there was something similar operating at the team level to what I had noticed at the individual level. Some teams’ systems easily adapted to new business requirements and some did not, and this did not seem to be dependent on the type of requirement. It seemed to be related to the way the teams operated, and the architecture of the system(s).
Eventually, I moved out of software development into architecture. My responsibility shifted from delivering a single component of a system to making the entire system work better, faster, more efficiently, and more effectively. I evolved my thinking around why some systems just seemed of higher quality and were more adaptable to change than others. I also noticed for the first time how much duplicate work was being done. So much money was being wasted producing the same component multiple times and fixing the bugs multiple times. I was fairly educated about object-oriented methodologies and the benefits of reuse, so facilitating reuse across groups made a ton of sense. Why would a team want to build something new, costing valuable time and money, if another team had already solved that problem?
This is when I began thinking about organizational dynamics, human behavior, and the often irrational belief under which many people operated: as long as they had ownership and control, everything would be fine – even if another group was clearly more proficient than they were.
This was when I learned of something called the optimism bias, which can be summarized as follows.

Take any arbitrary group of people and ask them an arbitrary set of questions where each person must rate themselves: below-average, average, or above average. Invariably, no matter the group, and no matter the questions, most of the group will rate themselves above average, most of the time; which of course, this cannot be true for everyone. Everyone cannot be above average.

I began to ask myself: “How can we increase reuse if everybody thinks they are doing it better than the next person?” The conclusion I reached is that there needed to be some unbiased assessment to prove a reusable component was of high quality. For people to feel comfortable reusing the work of somebody else, it would help to have sort of a good programming “seal of approval.” There also had to be a mentality that gave groups incentives to help one another, as well as an organizational environment where each group would realize they could not succeed by building everything alone.
Around this same time, I first read about the concept of technical debt, as espoused by Ward Cunningham in 1992. My initial reaction was that it was absolutely brilliant. But the more I read on the subject, the more I realized that – as currently understood – technical debt was about poor coding practices or systems that were poorly maintained. It was not as much about bad architecture or design, nor was there a way to put a real dollar amount to the technical debt associated with any system in a larger platform architecture.
My experience with software development and systems architecture told me that the hardest problems to fix were often the initial architecture and design issues, not the outputs of a poor programmer. Sometimes these decisions were set in stone in the first week of a year-long project. There had to be some way of objectively guiding these early decisions. It was imperative to quantify bad architecture and design decisions with dollar amounts, since they require real investments of money to fix.
I realized that if people were clear on terminology, definitions, and problem statements, and followed a few good rules, many bad architecture and design decisions could be avoided.

But life isn’t perfect. The realities of software delivery (including the need to make short-term delivery dates, and a dependence on others) made some non-optimal decisions inevitable – even when everybody agreed in principle that with a bit more time and money, a different decision would have been made. Life is compromise, and so is architecture and software development.
We may not be able to avoid compromise, but at the very least, we can meticulously track our compromises. The concept of technical debt seemed like an efficient way to track not only what compromises had been made, but also how big each compromise was. The concept that debt incurs interest the longer it remains unpaid also perfectly fits this analogy. The more compromises made in the design and implementation of any software-based system, the more “brittle” (or inflexible) that system becomes, and the more expensive to maintain and operate. The additional maintenance and operational cost required for a brittle system was like paying interest on the original debt. The longer the principle remained unpaid (i.e. kept incurring technical debt), the more money was spent on interest over the lifetime of the system.
The first time I explained my methodology (of defining a set of agreed-upon rules and measuring architecture and technical debt) to a technology audience, it went extremely well. There were lots of questions about who got to make which decision and how to ensure the process didn’t “get in the way” of getting the job done. But, in general, people understood.
The first time I explained my methodology to an executive business audience, it didn’t go so well. They understood that some systems and groups could deliver new features quickly and others could not. They liked the idea of measuring technical debt in dollars, but the first question I was asked was, “Is that real money?” I assured them that it was, but I didn’t have a very compelling way of explaining why or how. Most of the audience members had had the experience of technology groups demanding more time or more money to “do it right,” only to deliver disappointing results.
For the tool to be useful, tech people had to use it to explain to their less tech-savvy counterparts (who often controlled the budget) why one technology decision might be better than another for a valid business reason. It had to have something to do with a measurable impact on either company reputation, revenue, cost, and/or the customer. Merely being a “great technology idea – trust me, I’m an expert” was not a winning argument.
I started to do some research. I sought real-world examples of businesses being significantly impacted by some technology problems that everybody was aware of, but nobody could explain well enough to prioritize and fix. At the time, I was working for an organization in the legal industry, so I used the term body of evidence to describe these evidentiary stories behind the “golden rules.”
The next time I explained the methodology to an executive business audience, it went much better. I was able to use one of the key systems that everybody knew was important as an example. I pointed out a set of high-priority corrective actions that were required, how much was required to fix them, and why delaying the fixes would potentially lead to either revenue loss, increased cost, or unhappy customers. People understood that.

The Principle Based Enterprise Architecture is the methodology for enterprise architecture and architecture governance that I developed over the course of my thirty-five-year career. I did not do this alone. I stood on the shoulders of others who came before me, and had the assistance of many smart, dedicated people with whom I have worked. I hope this book will provide you with some useful tools and guidelines in your effort to be part of a great technology organization.

What is Enterprise Architecture

The term architecture, as it applies to technology, is tough to define. It simultaneously imposes structure upon a set of systems and data while also describing the structure of the systems and data-sets themselves. Let’s begin with a few definitions:

  • Architecture. The structure of components, their relationships, and the principles and guidelines governing their design and evolution over time.
  • Enterprise Architecture. An architecture whose scope is an entire organization.
  • Design.A technological solution to a given business problem according to and constrained by an architecture.
  • Component. An encapsulation of system functionality or data aligned to an implementation structure. Components are modular and replaceable. A component contains behavior, provides services, and makes them available through interfaces.
  • Component Behavior. The functionality provided by the component. In other words, what benefit it provides the system of which it is a part. The functionality of the component is provided as one or more services through one or more interfaces.
  • Service. The functionality of a component as provided through an interface.
  • Interface. The place at which independent and often unrelated systems meet and act on or communicate with each other; how interaction or communication is achieved.

Zooming in on the architecture of a system component and the data components it houses, we reveal greater and greater detail. As more detail is resolved, the scope of the architecture is narrowed to the point where we start talking about design rather than architecture. When we refer to an enterprise architecture, we mean the highest-level view of the technology and data landscape that makes sense to describe, as well as the methodology for producing that high-level view.

But why do we need an enterprise architecture? Can’t we let the software engineers just get on with writing the code, without all this structure and process? CEOs and architects alike commonly ask this question. But before answering, let’s ask a related question: Before the invention of the GPS, why did we need highway maps?

Imagine trying to drive from New York to Los Angeles using only the detailed street maps of all the cities in the United States. While you could certainly get there in the end, it would be neither easy nor quick. To solve the problem of driving from New York to Los Angeles, you simply don’t need the granular detail provided by these street maps. In fact, the detail gets in the way of understanding the “big picture” (and probably takes up the whole back seat as well). What you need is a context map that abstracts away the unnecessary detail, providing just enough so that the entire picture can fit in your brain at once, and you can see how to get from Point-A to Point-B. In other words, you need a map with a wider view: A United States map.

In an enterprise the size of the United States, at the most abstract level, we have states, cities within states, and interstate highways connecting them. To complete the mission (driving from New York to Los Angeles), all we need to know is which states we want to go through, and which interstates we want to take to optimize time. This is an architectural approach.

At this level of abstraction, even though we know that the road systems within each city are different, that level of detail is not immediately important. If we stop in a city for fuel or to stay overnight, we can always refer to the detailed map for that city, knowing how it fits into the overall United States context map. Using this analogy, the enterprise architecture is like the highway map of the U.S. It lays out the high-level structure of how all the states (systems) and interstate highways (system-to-system interfaces) fit together, so that the more-detailed state maps (system level architectures and designs) have context.

The key point to recognize is that enterprise architecture gains perspective of the whole enterprise, abstracting away detail to draw higher-level relationships. System-level architecture, on the other hand, is about zooming in to shrink scope and increase detail. System design takes the system architecture and further reduces scope, increasing detail. We can imagine “zooming out” to the architecture level, moving to a different part of the map, and “zooming back in” again. Patterns then capture similarities between groups of elements within the architecture, preserving a basic understanding of what is happening at a more detailed level even as that detail is abstracted away.

The Principle Based Enterprise Architecture (PBEA) Method provides a systematic, objective, metrics-based approach to the practice of enterprise architecture. In the PBEA method, we decompose the enterprise technology landscape into individual building blocks called assets. There are two types of assets: system assets and data assets. We often treat system assets as the houses in which data assets live. However, system assets and data assets are independent and are equally important. An asset is a component. But component is a general term and is used at all levels of granularity. The term asset is used to indicate the level of granularity at which these components are inventoried, managed, and governed.

At its core, the PBEA is based on a set of business objectives and guiding principles. The principles are the mission statements for the building blocks (i.e. the assets) of the architecture. Each principle is further described by a set of what we call “golden rules,” which define how to achieve the mission – and the consequences of deviation. These “golden rules” are the requirements for meeting the goal as defined by the architecture principles.

In order to maintain a governable architecture while avoiding the dreaded “death by governance,” it is important to limit the golden rules to only those that are truly essential. This allows us to avoid the clutter caused by trying to enforce every good idea.

The Principle Based Enterprise Architecture (PBEA) Method defines the key roles and processes for creating the Enterprise (technology and data) Architecture.