Failure to Communicate

There is a discussion of this article in the EA group on LinkedIn.

At a recent Gartner Group presentation the presenter estimated that between now and 2012 40% of Enterprise Architecture (EA) programmes will be shelved due to poor execution and that a major contributory factor to this will be a failure to effectively communicate the value of EA.
 
This is not a new problem for enterprise architects and IT architects in general (there are currently 10 widely used IT job titles that include the term architect). As someone who has always tried to use a "light-touch" approach to architecture and who’s job appears to many almost indistinguishable from staring into space, the importance of measuring and communicating value has always been forefront in my mind.
 
However, it is unusually hard to do this effectively across a wide audience. If EA initiatives are to succeed they must have buy-in at many levels in an organisation. At the recent TechEd EMEA in Barcelona I was out one evening with a mixed group for drinks when a seasoned programmer rather colourfully confided to me that she really didn’t understand what architects did. [I paraphrase] "They just seem like self-important developers and managers who swan around being really up themselves." Now one could argue that this maybe down to the experience of the individual in question, the number of drinks in the individual at the time or that this represents an equal failure or unwillingness to understand, but if ever there was a failure to communicate value there it is in action.
 
Architecture is actually all about value. Not value in the ROI sense, which is both a difficult and dangerous way to measure EA, but in the sense of really driving out the best value from IT investments across the board. Good architecture is highly valuable because it’s role is to find and ensure the delivery of best-fit solutions to business problems. To ensure the accurate translation of business strategy and requirements into IT strategy and delivery and to achieve maximum leverage and reuse of existing assets. However, because these kinds of activities are largely orthogonal to business units, projects and service delivery their value in terms of ROI is difficult to measure and tends not to reflect their real value to the business.
 
The business spend in IT is broadly divided into three areas.
  • The Run Spend – operational costs of maintaining services
  • The Growth Spend – introducing new services
  • The Transformation Spend – restructuring existing services to better suit changing business needs
The bulk of EA and other architectural initiatives are concentrated in the second two areas (Growth and Transformation) and it is these areas that tend to be first in the firing line when cuts need to be made. However, without proper architectural focus it is very difficult to produce services with lower longer term running costs or ones that can more easily be transformed. So, the effect over time of reducing the spend on transformation and growth is that running costs increase, often cancelling out the short term gains of the cost cutting.
ARC207
I have borrowed (and modified) this slide from David Chappell’s excellent presentation at TechEd about the Microsoft Application Platform.
His premise in this presentation is that the primary goal of business strategy is to create competitive advantage through differentiation. Key to creating this differentiation are custom applications on the basis that if you can buy something off the shelf it’s equally available to your competitors, almost certainly old news and therefore does not create competitive advantage.
However, over time, innovation becomes obligation and the value of that service decreases. The first provider to offer a given service gets the most advantage/value, the second less so and so on, up to the point where that service becomes so widespread that not providing it becomes a distinct disadvantage.
 
The strategic importance then of the application platform is that it should facilitate rapid and cost effective development and deployment of these differentiating applications in the key window of opportunity (C) and provide low operational costs over the longer term (B).
 
We can look at the strategic importance and value of EA in the same way. (B) is where the operational spend occurs while (A) is where the growth and transformation spend occurs and where much of the EA effort is focused. So we can see that the focus of EA is on delivering maximum value in (A) and creating architectures that will reduce costs in (B).
 
With a mature EA the lower operational costs have been achieved and much of the major transformation work is complete. Architecture has been created that allows for quicker, easier, cheaper transformation when required leading to greater agility, and maximum reuse and leverage of existing assets. This means that more of the overall spend can be used to achieve greater advantage in the growth area or the same growth can be achieved for less spend. As a result EA rarely has an ROI of its own, rather its value is found in improved ROI across a whole range of other initiatives.

Service Orienteering

There are bushmen wandering in the Kalahari who have heard the term SOA. It has been an industry buzzword for the last 3 – 4 years. However, definitions of SOA are as varied as they are widely spread. To try to untangle these definitions we need to start from the ground up.
Services are simply the next evolution in how we write code. They are the next level of abstraction, the next unit of re-use and encapsulation and the next software paradigm. 10 years ago we talked about objects, 5 years ago it was components and now it is services.
Service Orientation is to services as object orientation was to objects. When we build applications in a service orientated manner we are thinking about our application in terms of the interaction between services. Where we had APIs we have service contracts and where we had shared types we have schemas or data contracts. Instead of clients and servers we have service consumers and service providers.
This explains some of the confusion that surrounds the acronym SOA. When some people are talking about SOA they mean Service Oriented Applications and Service Orientation in general as opposed to Service Oriented Architecture. Another factor that adds confusion is that SOA and Web Services have been used interchangeably to mean the same thing when actually it is quite possible to develop service oriented applications and design service oriented architecture without using web services at all.
Finally we come to SOA where SOA stands for Service Oriented Architecture. This has almost nothing to do with the software development concepts we have just discussed because the “Services” are not the same. In Service Oriented Architecture the services are Business Services and SOA in this context means “architecting” your IT infrastructure so that it is both strategically aligned with and decoupled from the business services it supports. While Service Orientation is a technology that can facilitate this architectural decoupling from a software perspective, they are not the same thing.
The reason we are all obsessed by decoupling these days has to do with complexity. Both the business and IT challenges we face are inherently and increasingly complex. Complexity is here to stay. The people who handle complexity most efficiently and robustly will win whether it’s because they are fastest to market or incur the lowest costs or offer the greatest value or achieve the greatest flexibility.
Efficiency
Decoupling and modularization are efficient. They create agility and facilitate reuse. A group of climbers ascending a mountain who are all roped together get some benefits in terms of security and communication however, they must all take the same route, normally the slowest easiest route that is accessible to the least skilled of their team. They must all travel at the same pace, normally the slowest pace, the one at which their weakest least fit member travels. They must all encounter the same risks at the same time. An avalanche that takes out one member is likely to get the rest, either because they are all bunched up or because they are all roped together and get dragged along. They are not resource efficient. Before they embark on the first step of the journey they must have sufficient resources in terms of food and equipment to get the whole team to the summit and back. They must always attempt each challenge en route in the same order, i.e. the order in which they are roped together or they must stop and go through a reordering process. If one member is injured or falls sick the whole team must stop or slow down or the ascent may have to be cancelled. These factors make them slow and places some if not many mountain tops completely out of their reach.
The same group of climbers that ascended using different routes at different paces and at different speeds and times incurs none of the above disadvantages and gets all of the benefits of being a team if they use radio, GPS and thermal imaging to provide the same security and communication the rope used to provide.
Robustness
Complex, non-linear, tightly-coupled systems tend to fail in non-predictable and catastrophic ways. The point at which they fail tends to coincide with or result from a change in the state or behaviour of one of the components. This has been described as the domino or ripple effect which in reality doesn’t even begin to describe the problems faced by modern complex systems because both falling dominos and ripples are simple and linear. Non-linear systems have feedback loops and echoes which can exacerbate, magnify or accelerate failures. In complex systems a single event or action can cause a multiplicity of other events or actions which are not the same or in the same order each time.
Complexity and non-linearity are here to stay. These are inherent in the problems we are trying to solve so they are non-negotiable. We cannot do something complex in a simple way except by abstracting the complexity and that simply moves the complexity somewhere else, it does not reduce it. In fact it can add new complexity. Even simply hiding the complexity of a system behind a simple interface can cause problems in terms of its use, for instance it can make resource intensive processes seem otherwise. The only feature we can mitigate to any great extent is the coupling and this is why so much of our effort is addressed here.
Benefits
How do we benefit from strategic alignment ? Really, when we say strategic we mean “from the strategic level on down” and the alignment means that IT infrastructure is modeled on the business services it supports. The most obvious benefit is that the IT infrastructure is designed to support not only the business as it is today but as it will be tomorrow, it has the businesses strategy engineered into it. It is proactive and not reactive. This makes the business agile because when it needs to change it doesn’t have to wait for the IT infrastructure to be re-engineered to support that change either because the systems have been engineered to allow for change or because their decoupling allows for change in one without necessarily requiring change in the other. When it comes to capacity management (one of the most arcane and yet most critical arts in both Business and IT Management)** the clear mapping of business processes and services onto IT services and processes is of enormous benefit. Key business volume indicators (BVIs) can be identified and profiled to find their resource footprints. What does a BVI cost the business in network bandwidth, system memory, processor cycles, disk space etc. Which systems are involved or affected? If the business plan involves increasing a BVI (e.g. doubling sales) the knowledge of that BVI’s system footprint enables IT to quickly establish if current capacity will support the increased business and if not, which systems will have to be scaled by how much to meet increased demand and how much will that up-scaling or out-scaling cost ? If IT cannot answer these questions in a timely and accurate manner when business decisions are being made this is a constraint on the agility of the business and a risk to the success of business strategy.
**If you really want to get a handle on this talk to Capacity Management specialists Capacitas or arrange to attend one of their excellent seminars.
%d bloggers like this: