Architecture reflections
Andrew Brown
Security & Digital Transformation, CISO, CIO - CISSP, Enterprise Architect-TOGAF, ITIL
If you follow IT news and commentary around Architectures 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 are articles talking about Enterprise Architecture being broken, or the business irrelevance of architectural frameworks as we know them today – a prevailing 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 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 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.
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.? Which specialist shall I employ?? Which qualification is the best to pursue?? What is most relevant?
As an aside, while it is not quite accurate and too simplistic to view COBIT as the “why”, ITIL as the “how”, or combined 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.? It is also interesting to note that ITIL with ITILv4 has now shifted emphasis to incorporate much more of Lean and Agile thinking with value based outcomes (DevOps surely having an influence on the Service Value Chain as the most important part of the SVS – Service Value System).
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.
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!
Hopefully you will have spotted the error in the complexity just outlined. 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 is there 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 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” 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 by explaining the entire detailed process to justify your approach.? Simplicity can often be a challenge.
Below is one practical suggestion to get everyone on the same page.
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 a common ground to be established to 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 thus avoid the redundancy and wasted time 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 much easier to then 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 an 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) 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 suchis 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
Explanation of an A3 example
A3 example templates can be found here
Think before you leap
?
Is the A3 a tool, process or both?
https://www.lean.org/common/display/?o=1922
-----
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
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
?