enterprise architecture vs solution...

www.fragiletoagile.com.au 1 22/06/2015 AGILITY BY DESIGN

Enterprise Architecture vs

Solution Architecture

Glenn Smyth Founder & CE

Fragile to Agile Pty Ltd

“The best way to predict your future is to invent it.”

Frank Herbert

www.fragiletoagile.com.au AGILITY BY DESIGN 2 22/06/2015

• What is Enterprise Architecture; • Why Enterprise Architecture; • Introduction to Fragile to Agile® Integrated Architecture Framework; • Enterprise Architecture and Solution Architecture (disciplines and roles); • How Enterprise and Solution Architects can work together more effectively:

• Sample Enterprise Architecture and Solution Architecture artefacts; • Flow of artefacts; • Solution Architecture Artefacts.

• Architecture Governance; • Zachmann and TOGAF Implications; • Benefits of using the same Framework.

Overview


• Enterprise Architecture is often equated

to town planning as it applies at the

highest/entire organisation level

What is Enterprise Architecture

• Architecture

– Overall design

– How individual pieces fit together

– A noun and a verb

• Role of architecture depends on scope

– Individual building

– Whole complex of buildings

– An entire city

• The larger the scope, the more we need to

focus on architecture

• Our definition of Enterprise Architecture

“The alignment of technology, people and business design to ensure that

together they deliver business intent.”


In 1884, Sarah Winchester, heiress to the rifle company fortune, started renovating a

house she bought in San Jose CA, convinced that continuous building would repel the

ghosts of all those killed by the company’s products. To save money she did not hire an

architect. Sarah lived alone, playing her piano at 2am when construction workers

changed shifts, until her death in 1922.

Why Enterprise Architecture


We would never do this with our homes

Why do we continue doing it in

business and IT expecting it to work?

Result after 38 years of construction – cost $US5.5M, 147 builders, no plans, 160

rooms, 40 bedrooms, 2 unconnected basements, 950 doors, 2 upstairs external

doors leading nowhere, 65 doors to blank walls, 13 staircases to blank walls or

windows, 24 skylights in floors, 47 fireplaces and only 17 chimneys, 30 rooms built

in by other rooms, 6 kitchens 2 with gravity defying plumbing.



Enterprise Architecture Value Proposition Our view:

“Enterprise Architecture helps to deliver business strategy with confidence whilst minimising cost and risk and maximising agility”.



$80 -145B p.a. is spent on failed and cancelled projects (The Standish Group International Inc.) 25% - 40% of all spending on projects is wasted as a result of re-work (Carnegie Mellon) 50% of projects are rolled back out of production (Gartner) 40% of problems are found by end users (Gartner) Poorly defined applications contributes to a 66% project failure rate for these applications, costing U.S. organisations $30B p.a. (Forrester Research) 60% - 80% of project failures are attributed directly to poor requirements gathering, analysis and management (Meta Group) Nearly two thirds of all IT projects fail or to not deliver original scope.



Fragile to Agile® Integrated Architecture Framework


EA and SA Disciplines versus Roles

The difference between Enterprise and Solution Architecture disciplines and roles is illustrated by the Fragile to Agile®

Integrated Architecture Framework in the following slides .


Enterprise Architect - Noun/Discipline


Enterprise Architect - Verb/Role


Solution Architecture – Noun/Discipline


Solution Architect – Verb/Role


• Enterprise Architecture the discipline is strategic only

• Solution Architecture the discipline is conceptual only

• Enterprise Architects must be involved in the solution architecture function to: • Ensure that it adheres to Enterprise Architecture design principles and

patterns • Identify opportunities for sharing across solutions

• Solution Architects should be involved in developing Enterprise Architecture

• Solution Architects are involved in logical design, software engineering to ensure engineering adheres to Solution Architecture (Enterprise Architects should not play here)

Disciplines versus Roles


Other Architecture Roles

• Business Architect

• Technology Architect (Domain Specialist) • Integration Architect • Security Architect • Communications/Network Architect • Infrastructure Architect • … for each domain within Technology Design

• Application Architects? …

• Application Architects are just highly specialised (or not very rounded) Solution Architects

• Dangerous role from a career longevity perspective


IAF - Other Architecture Roles

Business Architects

Technology Architects/

Domain Specialists

Business Analysts

Technology Engineers


Business Architect Role

• Bridges the gap between IT and business

• Understands the business environment

• Elicits business intent (facilitator of AcdD workshop)

• Translates business vision and strategy into effective change proposals and concept briefs

• Responsible for the business design layers i.e. aligned with organisational and business unit strategy and it’s guiding principles

• Estimates business related costs and benefits

• Produces business design artefacts, business architecture documents and business case


Fragile to Agile® End to End Approach to Change


EA and SA Fit


Enterprise Architecture


Flow of EA Artefacts to SA Artefacts

• Major advantage of using the same Framework which is illustrated below: • Business Intent Artefacts (AcdB technique*) • Sample Enterprise Architecture Artefacts

• Business Capability Model • Reference Architectures and Design Principles • Patterns

• Fragile to Agile Conceptual Design Process

* AcdB technique is courtesy of 2nd Road Thinking www.secondroad.com.au

http://www.secondroad.com.au/


AcdB (Business Intent Technique)


• The AcdB (ABCD) tool is based on a toolset of conversation, invention and intent

• Developed by 2nd Road Thinking based in Sydney (project level variations are a Fragile to Agile adaptation)

• Tools combine to form the intellectual heart of design thinking

• Solutions are derived through creativity and community rather than cause and effect

• The AcdB technique is used in a number of organisations including:

– Australian Taxation Office

– SunCorp Group

– New Zealand Inland Revenue

– Bendigo & Adelaide Bank

– Internode

AcdB – Background


The AcdB (ABCD) approach has been adopted and adapted by Fragile to Agile for the following reasons:

• It supports strategic direction (SOA etc.)

• It is aligned with Lean principles

• Provides a clear scope and traceable and realistic outcomes

• Uses multi disciplinary teams

AcdB – Rationale


Voice of Intent

Voice of Design

Voice of Experience

Facilitator

Voices and Roles

Business Architect Solutions Architect Enterprise Architect

Business Unit Leads (Organisation) Business SME (Project) (can be multiple)

Executive (Organisation) Project Sponsor (Project)

Scribe / note taker (should be different from other roles)


A

Organisation

A

Project Level D

C B This is an issue

This is an issue

This is an issue

This is an issue

This is an Outcome

This is an Outcome

This is an Outcome

This is an Outcome

This is an hypotheses

This is a Project

D

C B This is an issue

This is an issue

This is an issue

This is an issue

This is an Outcome

This is an Outcome

This is an Outcome

This is an Outcome

This is an hypotheses

This is an action

This is an action

Strategic project initiatives flow on from the Ds of an organisation level AcdB (but this is not their only source)

Levels of AcdB (continued)

This is a Project


EA Artefact – Business Capability Model


INTPR07 – Unit of Work Boundary

There is a 1 to 1 relationship between a step in a Business Process Orchestration and an Enterprise Service (if the step is automated). Each step in a Business Process Orchestration represents a single unit of work. As each step invokes an Enterprise Service, an Enterprise Service also represents a single unit of work. A unit of work shall not span across multiple Enterprise Services or multiple business steps.

Fa

cil

ita

ted

Ou

tco

me

s

We provide a market leading, cohesive and feature rich digital experience for clients and third parties;

We provide real time account opening, servicing and client analytics;

We will actively work to reduce costs caused by re-work & waste in all areas;

Through innovation we will change & streamline our processes to improve our client & intermediary experience while reducing costs.

EA Artefact – Design Principle


Example Reference Architecture - Integration


Flow of EA Artefacts to SA Artefacts (CDP)


The same concepts that applies to governance as a whole, also applies to architecture governance. Architecture governance : • Maintains the integrity, relevancy and currency of all enterprise architecture

design elements • Oversees the decisions that effect the target state architecture • Provides a mechanism for making and monitoring those decisions

There are broadly three parts to a full governance framework and the Westminster System of Government is an appropriate analogy to describe them, being: • Legislation – sets the rules for technology referred to as design principles

categorised by the domain of design they cover; • Police Force – monitors for compliance to the legislation (design principles); • Courts – architecture governance deliverables establish the courts and their

processes, makes rulings on the legislation and maintains its relevancy and currency.

Architecture Governance


Architecture Governance Bodies


Zachmann and TOGAF - Issues

The two predominant Enterprise Architecture Frameworks, however: • Only 30 - 40% of organisations have an Enterprise Architecture function

• 60% of those “roll their own” • Do not resonate with business at all:

• “That’s an IT thing” • Poor starting point for a discipline about aligning business and IT

• Tendency to lead to: • “Ivory Tower” Enterprise Architectures • Enterprise Architectures that Solution Architects do not understand

• Governance problematic • Exponential growth in complexity since they were developed • Lack clear distinction between Enterprise and Solution Architecture resulting

in EA teams trying to “boil the ocean” e.g. do SA for the whole organisation • Not enough granularity in domains of design


Using the Same Framework

Solution Engineering


Enterprise Architecture

Architecture Governance

CRITICAL SUCCESS FACTOR All use the same framework


Thank You

enterprise architecture vs solution...

Documents