Presentation to the first New Zealand Enterprise Architecture Conference on 4 November 2003

1. Paul Ramsay
Director
Equinox Limited
The Enterprise Architecture Conference
Tuesday 4 November 2003 (v1.0b)

2. Overview
• Some initial observations
• The unintegrated enterprise
• Selecting a framework
• Alignment to strategic goals
• Demonstrating results
• Role of supporting tools
• Long term viability
2 © Equinox Limited 2003

3. 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?
3 © Equinox Limited 2003

4. 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
4 © Equinox Limited 2003

5. 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?
5 © Equinox Limited 2003

6. 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
6 © Equinox Limited 2003

7. Reducing complexity
Complexity = Diversity x Scope
Diversity Scope
Number of different: Number of:
• Vendors • Users
• Hardware • Requirements
• Software
• Interfaces
“Generally speaking, IT standardisation reduces
cost and variety increases cost”
7 © Equinox Limited 2003

8. 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 EA
frameworks
8 © Equinox Limited 2003

9. Business perception of IT?
9 © Equinox Limited 2003

10. The evolution of technology
“The next
Realism big idea” Mysticism
Reappraisal Oversold
Cynicism Enthusiasm
Under-
delivered
10 © Equinox Limited 2003

11. 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 requirements
This encourages poor utilisation of resources and
results in undue complexity.
11 © Equinox Limited 2003

12. 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.
12 © Equinox Limited 2003

13. 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 on
interoperability and integration
• Vendor products and technology become the drivers
of business capabilities and limitations
• There is no formal basis to validate and document
technology decisions that affect multiple systems
across the organisation
13 © Equinox Limited 2003

14. Getting the “big rocks” right
Need to get the “big rocks”
in right from the beginning:
• Reliability
• Performance
• Security
• Maintainability
• Recoverability
• etc
Much more difficult –
sometimes impossible – to
put them in afterwards
14 © Equinox Limited 2003

15. Organisational expectations
• More interested in the ends rather than the means
(eg. water vs. plumbing)
• Like may other “utilities” this often results in
management by exception - only an issue when it
doesn’t work
• Successful delivery - ultimately the only outcome of
any value
“If you continue to do what you’ve always done,
you’ll always get what you’ve always got”
15 © Equinox Limited 2003

16. Organisational expectations
Time Now
Cost Quality Free Perfect
Functionality Everything and more!
“People will always ask for more
than an organisation has the capacity to deliver”
16 © Equinox Limited 2003

17. 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 level
for the overall benefit of the organisation as a whole
17 © Equinox Limited 2003

18. So what’s the key?
• Clearly defined vision, strategy and objectives
“Ad-hoc decisions
taken independently of each other
do not reflect a coordinated strategy”
• Strong organisational leadership and direction
“If an organisation is dysfunctional,
why should you expect its information systems
to be any different?”
18 © Equinox Limited 2003

19. 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 making
process may result in:
• Haphazard and poorly coordinated initiatives
• Dominant or influential groups or individuals directing or
influencing funding decisions (“pet projects”)
19 © Equinox Limited 2003

20. People come first!
A common mistake is to focus on processes and tools
at the expense of people (who determine the nature and
culture of an organisation)
People make
business and People
technology happen
Processes are the glue Processes
that holds all together
Tools help to enhance Tools
productivity and quality
20 © Equinox Limited 2003

21. 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 different
levels of detail and formality in order to be successful
• “Incremental” - allows for introduction and up-take at
a pace an organisation can absorb and cope with
while continuing to be productive
21 © Equinox Limited 2003

22. Selecting a framework (continued)
• “Extendable” - can be implemented in a manner that
recognises the need to support subsequent business
and technical changes
• “Integrated” - encourages the attitude that
architecture is a “team sport” and can be linked to
other pre-existing or agreed corporate processes
22 © Equinox Limited 2003

23. Selecting a framework - other issues
Generic Framework Continuum Specific
Less value to the organisation More value to the organisation
• 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
23 © Equinox Limited 2003

24. Alignment - delivering the vision
“Start with the end in mind”
- Stephen Covey
Vision Dawn
Day-dream of a new day!
No Vision Nightmare Sleep-walking
No Plan Plan
24 © Equinox Limited 2003

25. Alignment
• Business-IT alignment is continually the top concern
of CIOs
• Put in place an appropriate governance mechanism:
• Representative and resourced
• Clear mandate with decision-making responsibility
• Actively engage with the business and monitor for
misalignment
• Establish appropriate checkpoints and milestones for
sign-off
“Avoid the big stick”
25 © Equinox Limited 2003

26. Alignment (continued)
• “Bottom-up” decisions optimise the parts at the
expense of the whole
• By clearly linking technical implementation to an
architecture which reflects business strategy,
organisations will achieve more consistent and
effective outcomes
26 © Equinox Limited 2003

27. Measuring the impact
• Must have objective measures of success
• Research suggests that architecture planning and
standards compliance can reduce IT expenditure
between 10% - 30%
• Fewer than 5% of Global 2000 IT organisations with
an EA programme have a corresponding
measurement programme in place
“Without measurements, EA is of little use”
- META Group
27 © Equinox Limited 2003

28. 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
28 © Equinox Limited 2003

29. 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 reporting
including compliance and benefit realisation
“Architecture initiatives which outrun business requirements
and 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
29 © Equinox Limited 2003

30. 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
30 © Equinox Limited 2003

31. Obtaining buy-in
Awareness
Involvement Education
31 © Equinox Limited 2003

32. 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 continual
work 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 the
nature and culture of the organisation
32 © Equinox Limited 2003

33. Maintaining buy-in (continued)
• Work your way down as far as it makes sense within
your organisation:
Principles
Best practices
Standards
Technologies
Products
Specific configuration / implementation guidelines
• People will not enforce architectural standards
beyond the point where they do not believe they will
result in business benefits
33 © Equinox Limited 2003

34. Maintaining buy-in (continued)
• Avoid becoming lost in the details - “missing the forest
for the trees”
• Finding the right level of detail is an exercise in
discovery - not a science
• Avoid “answering questions that no one is ready to
ask”
• Set realistic and achievable objectives - “don’t try and
drink the ocean”
“Just enough, just in time”
(also known as minimalist architecture)
34 © Equinox Limited 2003

35. 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 project
teams from inception to transition
35 © Equinox Limited 2003

36. Role of supporting tools
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
36 © Equinox Limited 2003

37. Role of supporting tools (continued)
• Framework support
• Modelling capability (eg. process, UML, data etc)
• Repository for models and other artefacts
• Integration with other SDLC tools
37 © Equinox Limited 2003

38. 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 applications
otherwise it risks becoming outdated and irrelevant
• Must continue to be “marketed” to both business and
technical communities
• Must also continue to seek feedback on whether the
architecture is meeting the needs of these
communities
38 © Equinox Limited 2003

39. Long-term viability (continued)
Business
(Organisational)
Supporting business
requirements
Leveraging new
technologies EA
Technology
(Implementation)
Must continually endeavour to maintain this balance
39 © Equinox Limited 2003

40. Resources
• Global Enterprise Architecture Organisation
http://www.geao.org
• New Zealand Chapter of the Worldwide Institute of
Software Architects
http://www.wwisa.org.nz
• Resources for Software Architects
http://www.bredemeyer.com
• Enterprise-wide IT Architecture (EWITA)
http://www.ewita.com
40 © Equinox Limited 2003

41. 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
41 © Equinox Limited 2003