View
6.417
Download
5
Category
Preview:
DESCRIPTION
Presentation to the first New Zealand Enterprise Architecture Conference on 4 November 2003
Citation preview
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
Recommended