Setting Some Realistic Enterprise Architecture Goals


Published on

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

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Setting Some Realistic Enterprise Architecture Goals

  1. 1. Paul Ramsay Director Equinox Limited The Enterprise Architecture Conference Tuesday 4 November 2003 (v1.0b)
  2. 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. 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. 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. 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. 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. 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. 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. 9. Business perception of IT? 9 © Equinox Limited 2003
  10. 10. The evolution of technology “The next Realism big idea” Mysticism Reappraisal Oversold Cynicism Enthusiasm Under- delivered 10 © Equinox Limited 2003
  11. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 31. Obtaining buy-in Awareness Involvement Education 31 © Equinox Limited 2003
  32. 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. 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. 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. 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. 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. 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. 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. 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. 40. Resources • Global Enterprise Architecture Organisation • New Zealand Chapter of the Worldwide Institute of Software Architects • Resources for Software Architects • Enterprise-wide IT Architecture (EWITA) 40 © Equinox Limited 2003
  41. 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 +64 4 499 9450 41 © Equinox Limited 2003