Introducing the "Double Iron Triangle" of Enterprise Architecture
You have probably heard of the Iron Triangle of project management (Cost, Scope, and Time). Did you know that Enterprise Architecture has it's own iron triangle? It does, and understanding the EA triangle is a great way to understand and describe the role, mission, and value of Enterprise Architecture.
By Analogy
By now, most technologists are familiar with the concept of the Project Management "Iron Triangle:" Cost, Scope, and Time. (I hear that the Project Management Institute calls this the "Triple Constraint").
These are not really cast in iron. That implies that they cannot change. Far from being unchanging, the "Triple Constraint" of project management says that if you change one, the other two must change. If, for you example, you increase scope, you will need to adjust cost or time (or both).
That said, I know many creative project managers who conspire to make minor changes in scope or time or cost, and manage, through skill and magic, to avoid affecting the other two. This is not the three laws of thermodynamics, here. They can bend. The Project Management triangle is a concept and a tool. It helps you to understand the impact of changes, and explain them to the business.
The Double Iron Triangle of Enterprise Architecture
There is a triangle in Enterprise Architecture as well, and it has many of the same characteristics. To be fair, it is not one triangle, but two, one embedded in the other. The sides are made up of Information, Business Process, and Functionality. If you change one side, then you have to change the other two.
There are three viewpoints on this triangle (which is one of the things that makes Enterprise Architecture so much fun). We have largely defined different roles and made them responsible for understanding each of these different viewpoints. Sometimes, they fight. Oftentimes, they forget the triangle. An Information Architect may change the way a business entity is modeled, but in doing so, he or she must then consider the impacts on process and functionality. (Not to pick on IA. We are all guilty, at one time or another, of this mistake).
So why two triangles?
I use two triangles to illustrate the "spectrum of variance" that exists along each of three axes. From each of the three viewpoints, there is a difference between "core" and "supporting" models.
The terms "core vs. supporting" is a pair that we (Microsoft IT EA) created by combining terms from the works of Geoffrey Moore and Michael Porter. I'm sure that purists will argue that the terms are not designed to be mixed. Perhaps. We went for simple terms that we felt were understandable on their face. This pair seemed to hit the mark. (special thanks to Gabriel Morgan, who did this analysis work for us).
Geoffrey Moore described in his book 'Living on the Fault Line' of identifying a business' core activities. In the book Moore writes "For core activities, the goal is to differentiate as much as possible on any variable that impacts customers' purchase decisions and to assign one's best resources to that challenge. By contrast, every other activity in the corporation is not core, it is context. And the winning approach to context tasks is not to differentiate but rather to execute them effectively and efficiently in as standardized a manner as possible."
Michael Porter described in his book “Michael E. Porter on Competition and Strategy”, “Primary activities create the product or service, deliver and market it, and provide after-sale support. The categories of primary activities are inbound logistics, operations, outbound logistics, marketing and sales, and support. Support activities provide the input and infrastructure that allow the primary activities to take place. The categories are company infrastructure, human resource management, technology development, and procurement.”
Our use of core vs. supporting is closer to Moore's view than Porter, but we are different than both, primarily because each of these esteemed gentlemen was taking one of the three viewpoints in the triangle. To be truly agnostic of the triangle is difficult. The closest I can come up with is this (Nick's definition):
For Core architectural elements, the goal is to describe those aspects of the business that are the closest to the value offered by the business to the customer. Core information describes things that the customer can see, and core processes affect the customer's experience, while core functionality directly impacts the customer's view of quality. ("Customer" includes many roles, including partners, investors, and employees, in addition to the traditional meaning). Therefore, businesses must differentiate themselves from their competition using variations in core elements. To compete effectively, businesses must master the art of being agile in their core elements.
Supporting architectural elements provide the support for the core elements. The goal for these elements is to be as efficient and inexpensive as possible. Supporting processes should be finely tuned and widely shared. Supporting information, likewise, must be widely available and unambiguous in meaning. Supporting functionality should be broadly available in the enterprise and consistently usable in many different ways. To compete effectively, business must master the art of self discipline to maintain consistency and uniformity in their supporting elements.
The Spectrum of Variance
I introduced a term above, 'spectrum of variance'. I don't believe that there is a clear dividing line, in any of the three architecture disciplines, between core and supporting elements. Information assets can certainly be supporting (like product information) and yet may have aspects that differentiate the business. Some processes can be involved with creating or delivering a product, yet aspects of those processes can be supporting in nature.
In the image above, I show the spectrum of core vs. supporting, and some of the stakeholder concerns that appear at different levels along the spectrum.
The impact of the Double Iron Triangle on EA models
When each of the three disciplines view the triangle, each must recognize both aspects of the triangle:
- Recognize that a change in one will probably affect the other two.
- Recognize which of their assets (process, functionality, information) fall in various places along that spectrum.
It is not enough to create a single view of the processes of an enterprise, or a single all-up information model, or a single application model, without recognizing the nuances added by this spectrum.
Alas, this is not an easy thing to do. There is a lot of complexity involved when you ask a person to be aware of two dimensions at once. How is an information architect to cope if business processes and applications change all the time, and if they have to keep track of the attempts of the business to differentiate themselves from their competition?
The answer is no different in architecture than it is in OO design: find a way to separate things that change from one another by using stable abstractions. (Think Strategy Pattern or Bridge Pattern... isolate change).
And there is the beauty of the double triangle. If you can stabilize the supporting triangle into a stable and consistent set of information, process, and functionality, then you can extend those supporting elements in each of the three directions quite independently of one another, and yet still achieve both interoperability and competitive advantage.
Call to Action
So take a long look at your models. Decide if you have a differentiation along this spectrum of variance. Then look at your architectural practices, and examine if you have a recognition of the interrelatedness of the three sides.
If you do not have both, consider adopting the double iron triangle. Consider using it to drive consistency to the center, and drive innovation and differentiation to the edge. You may just find that you can take your Enterprise Architecture to the next level.