Setting Some Realistic Enterprise Architecture Goals

Paul RamsayDirectorEquinox Limited

The Enterprise Architecture ConferenceTuesday 4 November 2003 (v1.0b)

2 © Equinox Limited 2003

Overview

• Some initial observations• The unintegrated enterprise• Selecting a framework• Alignment to strategic goals• Demonstrating results• Role of supporting tools• Long term viability

3 © Equinox Limited 2003

Enterprise architecture

• The next big thing?• Top of the food-chain?• A career path for over-grown technicans?• Imposed rather than embraced?

… or• Bringing back the baby we threw out with the bath

water?

4 © Equinox Limited 2003

Enterprise architecture (continued)

“Map” of the enterprise and a “route planner” for business and technology change:• Goals and objectives• Processes and organisation• Systems and data• Underlying technology

5 © Equinox Limited 2003

Enterprise architecture (continued)

• Structure, functions and interactions of an enterprise• “The technical implementation of business strategy”• Bridge between business and technical community• The foundation on which to build an effective

IT infrastructure

Where are we today?Where do we want to be?

How do we plan to get there?

6 © Equinox Limited 2003

Benefits

• Lower cost• Enhanced productivity• Improved management• Greater interoperability• More efficient use of operational and support

resources• Improved technology investment• Enhanced procurement• Better alignment with business direction

7 © Equinox Limited 2003

Reducing complexity

DiversityNumber of different:• Vendors• Hardware• Software• Interfaces

Complexity = Diversity x Scope

ScopeNumber of:• Users• Requirements

“Generally speaking, IT standardisation reducescost and variety increases cost”

8 © Equinox Limited 2003

Some initial observations

• Every organisation already has an architecture• The choices you make today become tomorrow’s

legacies• Must be “owned” by the organisation• Not a “silver bullet” or an “instant solution”• Journey not the destination - process not a product• There is no “right answer” or no “only way” - one size

does not necessarily fit all• Most New Zealand companies do not have the typical

IT infrastructure and organisation implied by many EAframeworks

9 © Equinox Limited 2003

Business perception of IT?

10 © Equinox Limited 2003

The evolution of technology

Oversold

Under-delivered

Reappraisal

“The nextbig idea”

Cynicism

MysticismRealism

Enthusiasm

11 © Equinox Limited 2003

The unintegrated organisation

Many organisation’s use of technology is often:• Unplanned• Uncoordinated• Inconsistently applied throughout the organisation• Reactive rather than proactive• Driven by individual requirementsThis encourages poor utilisation of resources and results in undue complexity.

12 © Equinox Limited 2003

Most projects don’t assist the situation

Projects by their very nature often tend to be insular and only focus on:• Immediate needs and interests of the sponsoring

business group(s) (“quick wins”)• Immediate deliverables (often resulting in the delivery

of narrowly-defined, highly-optimised “point solutions”)They often don’t consider the bigger picture and many of the “architectural issues” involved …… but projects are how an organisation builds its future.

13 © Equinox Limited 2003

An undefined architecture

In the absence of a defined architecture:• Individual system decisions are made which result in

a considerable amount of time being spent oninteroperability and integration

• Vendor products and technology become the driversof business capabilities and limitations

• There is no formal basis to validate and documenttechnology decisions that affect multiple systemsacross the organisation

14 © Equinox Limited 2003

Getting the “big rocks” rightNeed to get the “big rocks” in right from the beginning:• Reliability• Performance• Security• Maintainability• Recoverability • etcMuch more difficult –sometimes impossible – to put them in afterwards

15 © Equinox Limited 2003

• More interested in the ends rather than the means(eg. water vs. plumbing)

• Like may other “utilities” this often results inmanagement by exception - only an issue when itdoesn’t work

• Successful delivery - ultimately the only outcome ofany value

“If you continue to do what you’ve always done,you’ll always get what you’ve always got”

Organisational expectations

16 © Equinox Limited 2003

Organisational expectations

Time

QualityCost

Functionality

Now

PerfectFree

Everything and more!

“People will always ask for morethan an organisation has the capacity to deliver”

17 © Equinox Limited 2003

Organisation expectations - managing trade-offs• Much of what we do is about trade-offs - moving in

one direction incurs a cost in the other• Architectural decisions sometimes involve making

trade-offs at the individual project or application levelfor the overall benefit of the organisation as a whole

18 © Equinox Limited 2003

So what’s the key?

• Clearly defined vision, strategy and objectives“Ad-hoc decisions

taken independently of each otherdo not reflect a coordinated strategy”

• Strong organisational leadership and direction“If an organisation is dysfunctional,

why should you expect its information systemsto be any different?”

19 © Equinox Limited 2003

So what’s the key? (continued)

Programme management and enterprise architecture are the combined key to the successful prioritisation and selection of organisational initatives:• So many opportunities – such limited resources!• The absence of a structured and objective framework,

an unstructured and subjective decision makingprocess may result in:• Haphazard and poorly coordinated initiatives• Dominant or influential groups or individuals directing or

influencing funding decisions (“pet projects”)

20 © Equinox Limited 2003

People come first!

Processes are the gluethat holds all together

People

Processes

ToolsTools help to enhanceproductivity and quality

People make business and

technology happen

A common mistake is to focus on processes and tools at the expense of people (who determine the nature and culture of an organisation)

21 © Equinox Limited 2003

Selecting a framework

A framework alone won’t produce an architecture - it is simply an aid to experienced and knowledgable architects• “Just enough” - recognises that one size does not fit

all and that different organisations require differentlevels of detail and formality in order to be successful

• “Incremental” - allows for introduction and up-take ata pace an organisation can absorb and cope withwhile continuing to be productive

22 © Equinox Limited 2003

Selecting a framework (continued)

• “Extendable” - can be implemented in a manner thatrecognises the need to support subsequent businessand technical changes

• “Integrated” - encourages the attitude thatarchitecture is a “team sport” and can be linked toother pre-existing or agreed corporate processes

23 © Equinox Limited 2003

Selecting a framework - other issues

• Too generic - trying to be everything to everybody• Too prescriptive - sledge hammer to crack a nut• Framework is subordinate to the needs of the

business - not the other way around• Value comes in application - analogy of a smorgasbord

Generic SpecificFramework Continuum

Less value to the organisation More value to the organisation

24 © Equinox Limited 2003

Alignment - delivering the vision

Day-dream

Sleep-walkingNightmare

Dawnof a new day!

Vision

No Vision

PlanNo Plan

“Start with the end in mind”- Stephen Covey

25 © Equinox Limited 2003

Alignment

• Business-IT alignment is continually the top concernof CIOs

• Put in place an appropriate governance mechanism:• Representative and resourced• Clear mandate with decision-making responsibility

• Actively engage with the business and monitor formisalignment

• Establish appropriate checkpoints and milestones forsign-off

“Avoid the big stick”

26 © Equinox Limited 2003

Alignment (continued)

• “Bottom-up” decisions optimise the parts at theexpense of the whole

• By clearly linking technical implementation to anarchitecture which reflects business strategy,organisations will achieve more consistent andeffective outcomes

27 © Equinox Limited 2003

Measuring the impact

• Must have objective measures of success• Research suggests that architecture planning and

standards compliance can reduce IT expenditurebetween 10% - 30%

• Fewer than 5% of Global 2000 IT organisations withan EA programme have a correspondingmeasurement programme in place

“Without measurements, EA is of little use”- META Group

28 © Equinox Limited 2003

Measuring the impact (continued)

• Needs to cover at least three areas:• Impact on alignment (is there a demonstrable link to

organisational goals and objectives?)• Impact on investment (is it delivering the tangible benefits

claimed?)• Impact on organisation (what is the level of adoption and

utilisation?)

• Measures need to evolve based on:• Feedback and analysis• Evolution of the architecture itself

29 © Equinox Limited 2003

Demonstrating results

• Target those areas that:• Give initial “quick wins” and deliver tangible results• Reflect high priority / high impact business requirements

• Make sure you follow this up with relevant reportingincluding compliance and benefit realisation

“Architecture initiatives which outrun business requirementsand fail to show early, meaningful results

cannot be sustained. EA efforts that do not take into consideration long-standing biases concerning discipline and standardisation will

be ignored.”- META Group

30 © Equinox Limited 2003

Demonstrating results (continued)

According to Dana Bredemeyer, there are three key qualities:• “Good” – is technically sound and complete• “Right” - addresses business issues and solves

business problems• “Successful” – is used and delivers business value

31 © Equinox Limited 2003

Obtaining buy-in

Awareness

Involvement Education

32 © Equinox Limited 2003

Maintaining buy-in

• Start small - “don’t try and drink the ocean”• Acknowledge that initial results will not be all inclusive

or complete - but avoid things becoming a continualwork in progress

• Regular releases - maintain relevance and “top-of-mind” positioning

• Continually emphasise the benefits of compliance• Align level of detail (particularly in terms of

standardisation and compliance required) to thenature and culture of the organisation

33 © Equinox Limited 2003

Maintaining buy-in (continued)

• Work your way down as far as it makes sense withinyour organisation:

PrinciplesBest practicesStandardsTechnologiesProductsSpecific configuration / implementation guidelines

• People will not enforce architectural standardsbeyond the point where they do not believe they willresult in business benefits

34 © Equinox Limited 2003

Maintaining buy-in (continued)

• Avoid becoming lost in the details - “missing the forestfor the trees”

• Finding the right level of detail is an exercise indiscovery - not a science

• Avoid “answering questions that no one is ready toask”

• Set realistic and achievable objectives - “don’t try anddrink the ocean”

“Just enough, just in time”(also known as minimalist architecture)

35 © Equinox Limited 2003

Communication and collaboration

• Ongoing process of dialogue and communication –common issues this area include:• Low IT credibility within the business• Poorly written communication• Too much technical jargon• Failure to relate IT activities to business objectives

• Use all available communication mechanisms(eg. briefings, newsletters, Intranet etc)

• Seek to collaborate and stay connected with projectteams from inception to transition

36 © Equinox Limited 2003

A tool is not the task - just in the same way that having a shovel is not digging the garden!Tools are simply an “enabler” for:• Information gathering• Repository• Modelling• Analysis and assessment• Information sharing• etc

Role of supporting tools

37 © Equinox Limited 2003

• Framework support• Modelling capability (eg. process, UML, data etc)• Repository for models and other artefacts• Integration with other SDLC tools

Role of supporting tools (continued)

38 © Equinox Limited 2003

Long-term viability

• Architecture needs to evolve as:• Business requirements change• New technologies are identified• Experience is gained as the architecture is applied to specific

projects or applicationsotherwise it risks becoming outdated and irrelevant

• Must continue to be “marketed” to both business andtechnical communities

• Must also continue to seek feedback on whether thearchitecture is meeting the needs of thesecommunities

39 © Equinox Limited 2003

Long-term viability (continued)Business

(Organisational)

Technology(Implementation)

EA

Supporting businessrequirements

Leveraging new technologies

Must continually endeavour to maintain this balance

40 © Equinox Limited 2003

Resources

• Global Enterprise Architecture Organisationhttp://www.geao.org

• New Zealand Chapter of the Worldwide Institute ofSoftware Architectshttp://www.wwisa.org.nz

• Resources for Software Architectshttp://www.bredemeyer.com

• Enterprise-wide IT Architecture (EWITA)http://www.ewita.com

41 © Equinox Limited 2003

Acknowledgements

• Dana Bredemeyer, Bredemeyer Consulting• Ben Ponne, EDS (New Zealand) Limited• Bill Ross, Equinox Limited• Vijay Seetharaman, EDS (New Zealand) Limited• Damian Woodhouse, Borland New Zealand Limited

paul.ramsay@equinox.co.nz+64 4 499 9450