Reply is the place to meet an incredible variety of enthusiastic, passionate, ideas-driven people, who want to make a difference and an impact.Would you like to know more?
Glue Reply is the Reply Group Company specialising in IT architecture, integration and data solutions that drive business value. Pragmatic in its approach, Glue Reply provides independent advice on the technology solutions that achieve clients’ business objectives. Glue Reply’s core proposition is to help organisations maximise the value from their business change and technology investments by helping them define, design, implement and resource best practice.
Glue Reply works with many companies as a trusted advisor as well as being known for getting stuck into the nuts and bolts of any technical challenge to ensure the desired outcome. Glue Reply’s solutions drive operational excellence whilst preparing clients for digital transformation, cost reduction and data exploitation.
It is not difficult to find instances of business and IT projects failing to achieve their goals. The reason (or is it excuse?) frequently cited is misalignment or disconnection to organisational strategy. Enterprise Architecture (EA) has been offered as a part of the solution but has not been wholly successful. In many cases, the way EA is done and the starting point used means that despite significant investment, EA is not delivering the value that it could. Why is this? EA is often characterised by its significant 'disconnect' or shortfall between what IT projects are delivering and what is required to achieve business goals. This disconnect needs to be corrected. The contention of this paper is that a capability-led approach to architecture does that by providing a structure that enables organisations to derive and 'connect' direct business related benefits from their IT investment.
When implementing EA, how do disconnections between project delivery and business goals develop? There are a number of possible reasons:
To ensure that all projects and programmes deliver quantifiable business value, an important first step is to clarify the organisation's key business drivers and goals. These are often well defined, but not necessarily structured in a way that is useful in programme delivery. Business goals and strategies determine the 'capabilities' that are required to achieve the business mission. A common mistake is to start with the 'as is' process and technology state. This constrains thinking and places limits on project boundaries.
Often, architects are asked to describe the 'as-Is' state of an organisation's technology and business processes, but this is frequently done without the original plans and designs. The result is a set of pictures and models that represent an impression of the current state rather than an accurate depiction of what the technology and processes in place were meant to achieve, so the starting position does not truly reflect the current state. The 'to-be' state is surely more important. Often too much time is spent trying to document 'what it is' rather than 'what it should be'. Unless the as-is state is close to being good enough already, spending time capturing it in detail is a bit like winning the battle but losing the war. There is much better value in accepting that 'it is what it is' and putting the effort into what 'it should be'.
Many architectures become shelf ware. In other words, architectures are created but the real work, which is needed to underpin this process, is not done. As a result, the architectures do not deliver what business users are expecting. It is like buying a new 10-channel surround sound system but not connecting it to your television. You will only reap the benefits when the solution has been integrated into the environment.
Architectures are usually created by the IT team on behalf of the business. Despite the best efforts of the project teams, the outcome is often presented in technical terms dragging people into the details of the systems and applications, rather than focussing on organisational outcomes. This results in the team losing traction with the business - the very audience it was created to engage.
Some of the more forward leaning organisations are looking to Capability Architecture as a way of driving both the business programme and the ITEA project portfolios from the common starting point of stated business goals. Capability Architecture is gaining traction, but be warned: this capabilityled approach will only be successful when the IT function of an organisation works very closely and in a specific way with senior management from other areas within the business. To ensure success, the business needs to 'own' many of Capability Architecture elements not the IT function.
Capability Architecture provides a framework to describe the world using terms that the 'business' understands.
By using a common language, its aim is to unite an organisation across functional boundaries, through simple statements that connect activities, approaches and outcomes. A capability is a description of what the business is trying to achieve. It is often derived from the organisation's overall business goals, which usually describe a high-level strategic vision and direction. One Business Capability may be to improve the availability of equipment with greater visibility of items and assets. Each business goal relies on a number of capabilities. When these are in place, the business goal can be achieved. In other words, if a business goal describes the 'why' in terms of what the business is trying to do, the capability describes 'how and what with' this goal can be reached. For example, in order to improve equipment availability (business goal), the capability to view the forward and reverse supply chain equipment flows (capability). The organisation's mission statement and business goals are the key inputs to capability architecture.
Using defence capability-based planning concepts, Capability Architecture is based on a top-down distillation of the 'what, how, and why' the business should respond to customer needs and its operational environment. This differs from the bottoms-up 'art of the possible' perception of a technology-led approach. Business goals and capabilities should be specific and action-oriented, with the capability defined in a structured way.
The realisation of a given capability, however, is not quite so straightforward. This is where the 'disconnect' between IT and the business begins. While IT understands the 'WHAT' in the diagram above, the 'WHY' and the 'HOW' are open to interpretation. We are talking about more than simple requirements (which are so often systems orientated), but rather an articulation of the business capability needed to be carried out in a certain way to achieve a qualitative or quantitative outcome. To complicate the situation further, capabilities may sit across several parts of the organisation causing a conflict of interest and confusion between departments and areas of the business. For example, a well-known retailer of mobile phones and wireless services ran a sales promotion, offering a free laptop to customers signing up to its broadband package. The problem was that the company's retail outlets were physically not capable of receiving, storing and displaying the PCs. The capability required to 'realise' the goal of capturing broadband market share had not been defined, nor had plans been put in place to address deficiencies in the existing capabilities. We must therefore apply some structure and rules to the definition of capability and to the design attributes.
Capabilities must be described 'uniquely' and without constraint. This means that there should be no 'ands' or other conjunctions in capability statements. The ability to take orders and effect delivery, for example, relates to two totally different operations and should not be lumped together in one statement. No statement of solution, in either business or technical terms, should be included at this stage either.
Once the singular capability statement has been created and validated, further attributes need to be considered to inform the design process. These are related to the business goals.
It is rare that a change programme comes from only one area of the enterprise. Often, several areas need to change if a programme is to be a success. Enterprise architecture can be over complex, however; Capability Architecture enables us to apply more rigour and follow a much more pragmatic approach, as shown in the simple fourstep process below:
• Business Goals & Objectives > Quantified goals and objectives enabling the measurement of success and the assessment of change
• Capability Definition & Assessment > A measurement of today's capability and what is required to support the business goals• Organisational Response > A simple assessment of the people, process and technology development required to deliver the required capabilities
• Roadmap> The building of a business driven Capability Roadmap
A capability-led architecture can deliver a number of benefits: • It delivers a common language that is understood by both business and IT colleagues, as both discuss 'capabilities' rather than the 'business' talking about strategies and IT focussing on specific, lower level design details; • Provide a standardised and repeatable framework for prioritising investments with direct connection and 'line-of-sight' to the business needs and strategic vision.
• The adoption of a holistic or cross-function position means that everyone can work to the same agenda and the scope and outcomes can be identified more accurately. This means that better decisions are made and IT budgets can be used more effectively;
• It helps to ensure the practical and timely delivery of EA, by linking business goals to projects;
• In considering capabilities, organisations are better informed to understand, plan and manage related risks.
The application of Capability Architecture and capability planning really works. Reply has helped many clients covering a wide range of industries apply this approach to generate real benefits.
For a well-established aerospace product and service provider, we designed and deployed a robust mechanism that delivered strategically aligned capability planning for business improvement. Critically, it ensured that planning was explicitly in the context of business outcomes rather than technology deliverables. This provided the strategic line-of-sight necessary to properly prioritise investments and improve organisational concentration. Our Capability Architecture approach has helped a major global mobile telecommunications business combine and update its existing service provision with a new retail capability. This top down approach ensured the establishment of an appropriate and consistent level of service granularity and that identified the full set of business services, maximising re-use potential.
At the two of the top food retailers, our Capability Architecture approach was used to identify common capability requirements driven by the business strategy. This was applied across multiple business units and customer channels where we created the CA framework, Target Architectures, and long-term Business and IT roadmap to deliver the required Business Capabilities through combined business and IT change.
Many organisations are 'doing' EA, but few are doing it well. A disconnect between business and IT strategies seems to be the common reason for the programme portfolio and IT delivery failing to achieve the right value to the business.
By adopting a truly technology independent, capability-led approach connects what IT delivers and what the business expects. Our contention is that the capability-led approach will do just that, by providing the rigour and structure that will allow companies to 'do EA as originally intended' and deliver real business value.
By creating the common lexicon for and by reducing complexity of the programme portfolio Capability Architecture & Capability Planning gives focus to what really delivers the business goals and makes a difference to the bottom line.