If you follow some IT commentary it might seem that ‘Enterprise Architecture’ is in a bit of a quandary. On the one hand there seems broad agreement that in order to drive IT advantages in line with business needs, at speed, then a sound architectural base is needed. What is also needed are efficient processes to drive this architecture.
On the other hand there is talk around Enterprise Architecture being broken, of business irrelevance of architectural frameworks as we know them today – a view of self-referential documentation which only the architecture community ever really read, while others “haven’t got time for this, we have a business to run and improve”.
As reliance on IT increases (it certainly isn’t going away), and while new models of IT consumption and service delivery are morphed all the time, I believe architecture will continue to become more important, not less. The problem, as with so many things, is one of communication. The challenge is to communicate relevance to business stakeholders and show how we are improving or introducing new and better services by solving business problems through architecture. There is a need to both create and communicate solid base architectures to achieve this.
A good base architecture should be flexible and responsive to business value and outcomes, not simply a prescriptive technical methodology checklist.
The aim of this post is not to compare and contrast the different frameworks and methodologies, but a brief mention of some of the options does highlight the problem we face.
If I likely lose you in the next section it just serves to illustrate my point – that the whole arena, while well meaning, has become technically too large and varied to be useful on a day to day level for a majority. “But that is why we have specialists on this stuff – to guide us”. Very true, but we also need need simple overarching principles and tools to squeeze the most out of whatever framework or methodology we choose. These principles at least must be easy to understand by anyone in the business.
Complexity and choice is a problem, and we have a LOT of choice around governance, framework, architecture, service and methodologies. (COBIT, Zachmann, Togaf, ITIL, Prince2, PMBOK, CMMI, MSP, FEA, DOGAF, ISO 20000, ISO 27000, Agile, Six Sigma/DMAIC, and Lean to name but a few). Of course you will notice that, while not all mentioned are directly comparable or specific to architecture (they overlap, and also address slightly different concerns), it does illustrate the landscape is far from easy to explain. Which specialist shall I employ? Which specialisation/qualification is the best to pursue? Which is the most relevant to my business? Which gives the most value?
As an aside, while it is not quite accurate and too simplistic to view COBIT as the “why” of Enterprise IT governance and ITIL as the “how” (or combined with other frameworks the “how” and “what”), asking these ‘why, what, how’ questions serves as a useful starting point in questioning what you can get out of each i.e. how to map overlapping functions and get them to work together. It is also interesting to note that ITIL (after not having a universally positive rep) has now shifted emphasis to incorporate much more of Lean and Agile thinking with value-based outcomes in ItilV4 (DevOps surely having an influence on the Service Value Chain as the most important part of the SVS – Service Value System).
I highlight this only to show how many frameworks struggle to square the circle of Enterprise Governance, IT Governance and Enterprise Architecture into a ‘go-to’ one-stop shop for guidance. COBIT 5 for example looks at managing Enterprise Architecture within the Align Plan and Organise domain of the Management area. Ultimately though, that is how you move a knowledge domain forward. Define it, see what is useful or what is missing through experience and then either update/include it, or reference something else that deals with it better.
Back to the problem of complexity
To illustrate the complexity problem let’s briefly go back to 1987 and the Zachman framework with its 4 domains and numerous sub-domains as an initial point of reference (After all he looks jolly enough, or is that confused?)
1) Process Domain – Business Context Engines, Planning Engines, Visualisation Engine, Business tools
2) Information/Knowledge Domain – Business Data, Business Profiles, Business Models, Data Models
3) Infrastructure Domain – Computers, Operating Systems, Display Devices, Networks
4) Organisation Domain – People, Roles, Organisational Structures, Alliances
Domains have been added in other frameworks and, as you can see, this isn’t getting any simpler even if the constructs are useful. Even a single domain can have mind boggling degrees of complexity.
If I take a sub-component of the Infrastructure domain with which I am familiar (Networks) there is a vast array of technology to architect around, each with their functional and deep technical specialists. From Software Defined Networking, Control Plane emulation and Policy creation, to layer 3 identity separation (LISP), OTV for layer 2 over Layer 3 tunneling, FabricPath and TRILL for layer 2 routing (MAC in MAC, MAC in UDP – no more spanning tree), and VXLAN (MAC in UDP) for extension of layer 2 segments over shared physical infrastructure, to name just a few recent headlining technologies. And this is just one small part of one sub-domain!
Avoid the weeds!
Remember, a good base architecture will not have to architect around each new technology, but flexibly identify solutions to fit seamlessly into the architecture to solve a business problem, enable a service, or support business functions. This is why architecture exists in the first place.
So we ask ourselves what business problem are we solving? What service are we enabling? and/or.. What function are we supporting? For example with Software Defined Networking are you gaining greater flexibility? more open platform support? better visibility? better policy control? more customisation? lower costs? better security? reduced risk? and does this let you roll out new services more quickly and robustly to serve the business? With other technologies, are you able to move workloads faster regardless of location and with less operational overhead and cost, or spin up services more quickly, reliably, cheaper? How does it aid mobility? Public / private cloud? Security?
Once you ask and find your own answers to such questions, the technology seems to slot naturally into a base architecture.
Given the complexities, how do we get everyone on the same page?
We could just throw around nebulous buzz phrases like “business outcomes” without defining what they are and hope everyone nods in agreement, but a more practical method might yield better results.
What I am not saying is that the Architecture Vision or Business Architecture phases of say TOGAF (to pick an architecture framework) does not accommodate this, more that it is all too easy to slip into the technicalities of a process and cognitively overload your stakeholders with detailed process to justify your approach. Simplicity is often a challenge.
With that in mind, below is one practical suggestion to get everyone on the same page (literally)
As all of the above frameworks, methodologies, processes etc. were (to a greater or lesser degree) born out of the Deming cycle (Plan, Do, Check, Act), it does allow some common ground to be established to serve as a foundation for getting all stakeholders on the same page. We can use this to simplify communication and create a common understanding.
The aim is the get business stakeholders involved as early in the process as possible to understand, and thus avoid, redundancy and time wasted from erroneous requirements.
If you allow the value stream to “pull” the process and architect with this in mind, it can really help in making architectures business relevant. By this I mean viewing the process from the perspective of customer value, business value, and demand, then working backwards to eliminate waste and improve service quality. Once you have this agreed information with stakeholder buy-in, it is then much easier to incorporate it into whatever your existing architecture, methodology or framework is. As obvious as this sounds, it is rarely done effectively.
This brings us to a practical example of a process/tool that literally gets everyone on the same page: the Lean A3 process/tool.
With the A3 report everything is discussed and agreed upon in one A3 sized document, which is highly visible, has agreed reference data, and follows a simple common sense process. As this process revolves loosely around the initial Deming cycle it has instant familiarity with architects, developers, designers, manufacturers and business process professionals across the board. The idea here is to get everyone to agree on the problem being solved, the service offered, or the function supported. This in turn enables a more seamless flow into the base architecture.
Although the above might indeed sound like “common sense”, and increasingly there is a reliance on this quality in architects; by formalising, and standardising this sense in one place, with commonly agreed data in a concise format (that all stakeholders understand and have contributed to – every relevant department gets to contribute to the doc and this is crucial for engagement) we can then provide a solid base for the detailed architecture to really achieve what it sets out to do. It also makes it easier for anyone new to quickly understand the architecture and contribute meaningfully without wading through reams of framework documentation for weeks on end.
As they say ” put talented people into average processes and you often get poor results, but put average people into great processes and you get excellent results”.
Like anything, the A3 process/tool takes practice, (it is not something you write individually and present), but the idea of having a one-page reference that everyone has contributed to and agreed upon can be a very powerful way of getting different functions to work together and most importantly understand why things are happening the way they are. Does it have to be the A3 process/tool? Of course not, but it does seem to be a useful reference or starting point.
Another advantage is that the components of the A3 process can quite easily be mapped to individual architecture phases in other frameworks such as TOGAF.
IT organisations are being increasingly measured by their alignment with the business; by speed and flexibility, productivity and growth, with security and risk mitigation embedded at every level (as it should be). Combined with this, the idea of service managers running an IT service as a function of the business and measured as such is be a powerful one. For me, this only puts greater emphasis on making sure everyone is referring to the same thing to avoid costly misunderstanding.
Through process/tools such as A3s, allowing architectures to be pulled from the value stream, making things as simple and visible as possible, and having stakeholders embedded in the process as early as possible, we can cut through many of the communication issues commonly associated with architecture relevance of late.
Try it – you might just like it.
Some examples of the A3 process/tools can be found below:
Explanation of an A3 example – pdf
A3 example templates can be found here
Think before you leap
What Do You Know About Why You Are Doing This A3?
Is the A3 a tool, process or both?
Addendum:
There are several formal definitions of terminology within the various frameworks. I try, where possible, to ground myself in standard English definitions of the terminology firstly to remind myself of what I am trying to achieve, and secondly to gain common understanding. Some of these basic dictionary definitions are included below:
TOGAF defines architecture as
- 1. A formal description of a system, or a detailed plan of the system at a component level to guide its implementation
- The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time”
Dictionary definitions
Architecture – the complex or carefully designed structure of something
Architect – ” a person responsible for inventing or realizing a particular idea or project.” from the Latin or Greek arkhitekton meaning “chief – builder”
Framework – a skeletal structure designed to support or enclose something – a frame or structure composed of parts fitted together, or a set of assumptions, concepts, values, and practices that constitutes a way of viewing reality
asbtechblog 