By Jonathan Whelan
A while back I attended a course where in which the participants were split into groups and each group had to make a paper plane using only a sheet of A4 paper; there were no other instructions. The resulting planes were very different … and in some cases very amusing! Some were designed for speed – arrow-like, intended to travel in one direction fast, but their airtime was short. Others were designed for endurance – with a broad wingspan, intended to stay in the air for as long as possible, meandering their way left and right but ultimately towards the floor. And some were designed to achieve a bit of both. The only constraint was time, 10 minutes was allocated to complete the exercise, and perhaps the creativity of the participants.
Then the groups were given a brief specification, no more than a few lines and sometimes a very simple diagram or two, and asked to complete the exercise again. The result was much greater consistency of the planes produced as the specification constrained the diversity of the groups’ designs. And whether the planes favored speed or endurance was influenced by the specification. There was, however, still some room for a little creativity.
There is a strong analogy between the above scenario and federated architectures. A key purpose of operating a federated architecture is to provide the federated functions (or divisions) of the business with the freedom to design their systems given their specific situation and needs, but at the same time to contribute to the greater good of the organization. In other words, do what you need to do but do it in a way that helps the community (of federated functions) as a whole. There is no ‘command and control’; no one function that oversees the designs of each of the functions as to do so would require the detailed understanding of each of those functions. And this is where architecture directives have a part to play.
Let’s look at a typical scenario. Organization X is a large organization with functions, each with its own business plans and budgets, heads of function and so on, and each is responsible for its own architecture. The technology estate comprises hundreds of systems and thousands of interconnections between those systems. This estate has evolved organically over many years in response to customer demand, market forces, regulation, mergers and acquisitions to name a few. The estate includes a wide range of technologies, a mix of home-grown and packaged/third-party systems, a variety of databases and servers, and a myriad of interconnections through which data flows. The result is a complex ecosystem in which data and functionality is duplicated, and to make changes typically requires significant effort and risk. Consequently, Organization X is hindered in its ability to meet the demands placed upon it in today’s business environment where time-to-market, cost-to-market and running costs are differentiators. Organization X requires a technology estate that better meets its current needs. Rather than having a technology estate that is an asset, it is a liability. Does all that sound familiar?
Architecture directives – by which I mean architecture principles, policies, standards, patterns, etc. – provide a powerful way of guiding the architectures of the federated functions so that they can satisfy their own need but at the same time make a positive contribution to what Organization X as a whole is trying to achieve. Architecture directives are intended to avoid (or at least minimize) tomorrow’s technical debt; that is, the technical debt that results from tactical solutions made to address an immediate need but which ultimately results in future consequences (usually cost and/or risk) to the organization.
From an investment management and change management perspective, architecture directives make it possible to govern programmes and projects more objectively. There is no need to examine complex architecture diagrams depicting numerous systems and their interconnections (and often other dimensions that add to the complexity of architecture diagrams), but instead focus on adherence to the directives, or rather non-adherence and hence addressing ‘technical debt’. A simple policy titled, for example, ‘One in, one or more out’ – meaning that a system cannot be added to the estate without one or more being decommissioned – may be a reasonable contributor to an IT goal of reducing the number of systems overall, especially where significant duplication of system functionality has been identified. The simple question ‘Does the proposed investment adhere to the policy?’ should elicit a simple Yes/No answer. If ‘No’, then discussions should focus on justifying why not.
A critical success factor of architecture directives is getting the right balance; too many can swamp and confuse architects and designers, and too few means that strategic objectives may not be met. Too fluffy and they are difficult to follow and to govern against; too prescriptive and they can be unnecessarily burdensome. And they need to cover everything; they should focus on what is important to the organization. Defining architecture directives is a blend of art and science. Directives are designed to reduce the degrees of freedom over designs, not to limit the functions achieving what they need to, but encouraging them to do it in a way that benefits the organization as a whole.
But who should produce the directives? Given their purpose, it needs to be a function that takes a broad, independent view, and so usually it is a central strategy or architecture function, after all, the directives should reflect (and reinforce) the strategy. However, the best set of directives I have seen are produced by the functions collectively, facilitated by a central function. It gives each function the chance to understand each other’s specific needs as well as areas of commonality (and solutions can be shared). The engagement and conversations that take place between the federated functions are invaluable and foster a culture of ‘we are in it together’ in which compromises are made for the greater good.
Good architecture directives can be worth significantly more than the paper they are written on. Bad ones are a waste of paper that could otherwise have been used to make planes.
Jonathan is an established business transformation specialist who has over 34 years’ experience in change-related roles. His commonsense approach to addressing complex business problems and shaping practical, sustainable solutions has been fundamental to the success of many transformation programs.
In his spare time, Jonathan writes about business transformation, especially in relation to the issues and opportunities associated with information technology. His latest book, co-authored with Stephen Whitla and published by Routledge, is titled: Visualising Business Transformation – Pictures, Diagrams and the Pursuit of Shared Meaning.