1

Not understanding the Operating Model – (assuming Unified) and trying to build a service to meet the needs of everybody. Not laying foundations first – Security Services, Integration Services, Service Register, changes to SDLC, governance processes)

SOA anti-patterns – uber-service, CRUD interface, parameters that fundamentally change behaviour) Accidental architecture – having no architecture at all; following an architectural blueprint is the only way SOA will deliver expected benefits Ivory Tower architecture – having an unrealistic “nirvana” architecture that is not connected to what the business actually wants/needs to achieve Not defining architectural principles – across all architecture layers or linking them back to Business Intent will almost certainly result in religious wars within IT and provide no means of resolving these often debilitating disputes. Not clearly defining service container boundaries – communication between, but not necessarily within, service containers must be via Web Services – will result in incorrectly constructed services at the wrong level of granularity

2

3

In our view, the enterprise in Enterprise Architecture (EA) has two meanings, both of which are equally important. Although individual areas of the business can be the primary focus for EA, the first and generally well understood meaning of enterprise implies that the scope of the architecture must be the whole of the business. The second but less understood meaning is that it must incorporate the entire breadth of design, including business, people and technology design. Enterprise Architecture must be relevant to the business and deeply embedded in its process of implementing change. Otherwise it runs the real risk of becoming an ivory tower architecture. Our definition of Enterprise Architecture is: “Enterprise architecture is the alignment of business, people and technology design to ensure that together they deliver business intent.” Enterprise Architecture must be both a set of artefacts that achieves this alignment (architecture the noun) and a process for actually architecting a solution (architecture the verb). This process must also be integrated with an organisation’s standard change process and not conducted as a parallel activity. More importantly, it implies that Enterprise Architecture must be driven by business intent if it is to deliver its promised value.

4

Although there are as many definitions of Enterprise Architecture, there is a consensus beginning to emerge as to why it is needed. Design alignment is key and should be fundamental to any Enterprise Architecture practice, including alignment in both directions: • business to technology • strategic to conceptual

The Fragile to Agile Value Proposition is: “Enterprise Architecture helps to deliver business strategy with confidence whilst minimising cost and risk and maximising agility” It is designed to appeal to different members of the C-suite, for example: • CEO, CMO (delivering business strategy, maximising agility) • CFO (minimising total cost of ownership) • CRO (minimising risk) • CIO (maximising agility, minimising total cost of ownership)

5

There are many existing frameworks including Zachmann, TOGAF, MODAF, etc. Fragile to Agile has developed its own framework due to the following limitations with other frameworks: • Lack of resonance with business executives and perceived to be an IT practice only

which is a poor starting point for a discipline that needs to engage deeply with business

• Support architecture “the noun” reasonably well but not architecture “the verb” • Stress Business Process Design is the primary business design artefact but due to

constant change, is a fundamentally fragile foundation to base an organisation’s design

• Not easily embedded into change delivery processes • Only support Enterprise Architecture, not Solution Architecture therefore detached

Enterprise Architecture becomes problematic at many organisations using these frameworks

• Have a tendency to lead to Ivory Tower architectures • Lack detail in the layers of technology design • Have no implied or sequential order • Do not cover governance well and do not have it built in

Together, Zachmann and TOGAF have just under 50% of the market and others are “rolling their own” which indicates that existing frameworks are not sufficient.

6

The Fragile to Agile Integrated Architecture Framework: • Encompasses the entire breadth (from strategy formulation to implementation)

and depth (from the articulation of business intent to technology infrastructure design) of business change.

• Simplifies peripheral disciplines such as governance, investment prioritisation and the assessment of a change initiative’s adherence to strategic business intent.

• Incorporates all of the required elements to effect successful change in a single integrated approach.

• Allows Enterprise Architecture to be deeply embedded and integrated into an organisation’s process of implementing business change.

• Ensures that Enterprise Architecture must be driven by business intent and therefore deliver tangible business value.

7

A Business Capability Model (BCM) describes what the business does as opposed to how (business process models) or who (organisational models) does it. As what an organisation does changes much less frequently than how or who does it, a BCM is inherently stable and therefore a sound base on which to map an organisation’s business and technology architectures e.g. data architecture, business process layers etc. A Business Capability Model must depict all of the capabilities required for the organisation to operate regardless of whether they are executed internally or outsourced. A Business Capability Model should be applicable for both business consulting and deep technical design. It should provide a single tool that can seamlessly flow from business consultation to technology architecture design and maintain business engagement throughout the process. This not only provides a shared language and collaboration tool to facilitate these discussions but is fundamental to converting business strategy into execution.

8

The importance of a Business Capability Model is explained below: • It provides a capability oriented view of the business

• It is a stable business design artefact which does not require constant maintenance

and enables continuous technology alignment and business/IT synchronisation

• Acts as a common language and communication medium between IT and the business

• Fosters a much deeper understanding of the business and frequently leads to business change innovation e.g. Compaq

• Provides a strong basis for managing complexity within an organisation

• Enables conversations to determine whether the requirements of different business areas are sufficiently aligned to warrant the of sharing solutions and therefore reducing cost

• Is fundamental in delivering a successful SOA strategy.

9

The importance of a Business Capability Model is explained below (continued): • Used for mapping current, interim/transitional and target state architectures

• Exposes gaps, redundancy and overlaps in functionality

• Other significant non-IT benefits:

• Provides a greater understanding of the business and its issues and pain points • Identifying services (not necessarily IT) where investment will deliver the most

value • Identifying key cross capability hand off points (where processes most

commonly break down) • Positioning for greatly simplified in/outsourcing of capabilities, both in a business

and IT sense • Improving portfolio management • Enabling business investment focus, prioritisation and governance • Enabling capability based planning and transformation

For more information, Forrester Research’s paper “Business Capability Modelling – The Rosetta Stone moment for EA” is an excellent resource

10

Business Capability Model Executive View • Decomposes capabilities to two levels of abstraction only • Less rigour applied due to its high level nature • Consulting artefact • Used to manage up e.g. overlays, heat maps, investment and prioritisation

11

Business Capability Model Architecture View • Decomposes capabilities to four or five levels, where necessary • Design artefact – must be developed with rigour to achieve the detail required • Used for deep technical design

12

The Agility Pyramid is a core concept of the Fragile to Agile approach. The characteristics of an agile organisation is that its cost and time to market are far superior than more fragile organisations and the realisation of other tangible business benefits is guaranteed. An agile organisation is built on a foundation of dynamic business processes underpinned by flexible services. Achieving the former is the remit of the Business Process Management and Lean Manufacturing disciplines; achieving the latter being the domain of Services Based Business Design and Service Oriented Architecture. Adopting either a BPM or SOA strategy without the other will achieve incremental improvement only and certainly not deliver a truly agile organisation. Neither BPM nor SOA can be delivered without an architectural approach to design and implementation and, in our opinion, can only be achieved by using a Business Capability Model to underpin the actual design of an agile organisation. For example, this approach can be used to determine that correct boundary between top-down business process re-engineering and bottom-up lean manufacturing and continuous improvement for business process management initiatives. For a SOA strategy, it provides a scientific way to determine the correct granularity of services and a radically more agile version of the business. In essence, Enterprise Architecture is the missing link that is required to deliver Agile Inc. and translates strategy into execution and delivers a roadmap that can be implemented.

13

To achieve a truly agile organisation, Enterprise Architecture must incorporate all domains of design, specifically business, people and technology. The absence of this design alignment hinders a seamless and effective transition to a materially more agile state. Consequently, a single integrated approach needs to be used to initiate and drive all domains of architecture and design. Unless an integrated approach for both Enterprise and Solution Architecture disciplines is employed, unclear boundaries between both disciplines will prevail and solutions will not be strategically aligned to well-defined business intent. Further, enterprise architecture will be regarded as a blocker to change and, in the experience of Fragile to Agile, this much needed discipline will ultimately be abandoned. The Fragile to Agile® End to End Approach to Change, depicted in the diagram, supports the entire end to end approach to successfully execute business change and transformation. It can be used for all elements of business change from strategic planning, conceptual design and logical design to the physical delivery of the change. Using the approach consistently throughout the entire change process also greatly simplifies related issues such as governance, investment prioritisation and the assessment of a change initiative’s adherence to strategic business intent.

14

15