If you follow IT news and commentary around Architectures at the moment it might seem that Enterprise Architecture is in a bit of a quandary. On the one hand there seems broad agreement that to drive IT advantages in line with business needs, at speed, a sound architectural base is needed. What is also needed is efficient processes to drive this architecture.
On the other hand there are articles talking about Enterprise Architecture being broken, or 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, there is 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 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 business relevant services, and solving business problems through architecture. There is a need to create and communicate the base architecture to achieve this.
Although the aim of this post is not to compare and contrast the different frameworks and methodologies, a brief mention of the options does highlight some of the problems we face.
We have a LOT of choice around governance, framework, 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 (they overlap, and also address slightly different concerns), it does illustrate that the landscape is far from simple.
As an aside, while it is not quite accurate and too simplistic to view COBIT as the “why”, ITIL as the “how”, or with other frameworks the “how” and “what”, it can serve as a useful starting point in questioning what you can get out of each, and mapping the overlapping functions in getting them to work together.
To further illustrate the complexity 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.
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 component of the Infrastructure domain with which I am familiar (Network) 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
You will, of course, have spotted an error in the complexity I have just outlined. A good base architecture will not have to architect around each new technology, but identify solutions to fit seamlessly into the architecture as they solve a business problem, enable a service, or support business functions. This is why architecture is there in the first place.
So we ask ourselves what business problem are we solving, what service are we enabling, or function we are supporting? For example with SDN 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? Or with some of the other technologies, are you able to move workloads faster regardless of location 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 indeed have 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” and hope everyone nods in agreement, but a more practical method might yield better results.
What I am not saying is that some of this is not covered in Architecture Vision or Business Architecture phases of TOGAF for example, but it is all too easy to slip into the technicalities of the process, or explain the entire process in order to try get everyone on board with this piece, let alone contribute meaningfully. This can often be a challenge.
One practical suggestion is briefly outlined below.
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 common ground to be established and serve as a foundation of 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 to avoid the 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. As obvious as this sounds, it is rarely done effectively.
This brings us to the option of a process/tool that can literally get 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 common sense in one place, with common agreed data in a concise format, with stakeholder contribution and understanding, 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 initially 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 often 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 will be increasingly measured by their alignment with the business; by speed and flexibility, productivity and growth, with security and risk mitigation embedded at every level. Combined with this, the idea of service managers running an IT service as a function of the business and measured as such, will 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 A3, 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, maybe we can cut through some of the communication issues commonly associated with architecture relevance of late.
Some examples of the A3 process/tools can be found below:
Think before you leap
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”
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