8 Business Drivers for Technology & Architecture decision making

2. 8 Business Drivers for Technology & Architecture decision making Mark Carroll Architect Advisor Microsoft ANZ Session: ISO5

3. Once upon a time ….

4. Once upon a time …. Chooser Architecture / Technology Choice

5. Once upon a time …. Project Manager Chooser Architecture / Technology Choice Architecture / Technology Impact

6. Once upon a time …. Project Manager Chooser Project Owner Architecture / Technology Choice Architecture / Technology Impact

7. Once upon a time …. Project Manager Chooser Architecture / Technology Choice Architecture / Technology Impact

8. Once upon a time …. Project Manager Chooser ? Architecture / Technology Choice Architecture / Technology Impact

9. Once upon a time …. Project Manager Chooser + ? = Architecture / Technology Choice Architecture / Technology Impact

10. Cost Drivers Industry drivers Customer & user benefit drivers Key Drivers for technology and related architecturedecision making Tangible Costs Life Expectancy Skills Availability Third Party Product & Services availability Timeliness Standards & Methodology fit User Functionality requirements Customer requirements

11. “Funds for procurement and funds flow within TCO .” “How long is the choice going to be viable and supported .” “The right skills at the right price and at the right time.” “The right services and complimentary products at the right time” “Elapsed time from Pain to Gain .” Cost Drivers Industry drivers Customer & user benefit drivers “The ability to operate with other standards compliant assets” “Giving the user something they can interact with effectively .” “Delivering what is ‘in scope’ for the sponsor who is paying.” Tangible Costs Life Expectancy Skills Availability Third Party Product & Services availability Timeliness Standards & Methodology fit User Functionality requirements Customer requirements

12. Skills availability • What is this ? • “The ability for you to acquire the necessary technology or architecture related skills at the right price and at the right time.”

13. Skills availability • Good fit to this driver; • Easier to perform advance planning – skills closer to commodity status; • Easier to smooth out unexpected ‘skill resource humps’ in your work schedule reducing risk of project and operational failure; • Bad fit to this driver; • Lack of emergency ‘resource’ increasing risk; • Market tighter – you pay more increasing cost ! • Low in-house incentive to acquire skills or retain once developed – staff not motivated;

14. Third party product and services availability • What is this ? • The availability of third party products that will help you get the job done along with the skills required to establish and master them; • The availability of third party services providers – anything from outsourcers to advisors;

15. Third party product and services availability • Good fit to this driver; • Costs reduce and availability increases providing more options for Project and operational managers; • Bad fit to this driver; • Fewer third parties in a market can lead to you being trapped or having costs ‘run away’; • More pressure on in-house providers; • Reduced options for efficiency and cost recovery;

16. Standards & Methodology fit • What is this ? • Levels of compliance and ease of achieving compliance to relevant IT & sector industry standards (eg: WS-I, BPEL, e-GIF)

17. Standards & Methodology fit • Good fit to this driver ; • Compliance ‘tick’ – good for market / sponsor buy-in, Enhances credibility; • Your ‘stuff’ is more likely to effectively work with and leverage other ‘stuff’ developed by others.

18. Standards & Methodology fit • Bad fit to this driver; • You get ‘caned’ for not paying attention to industry standards; • You end up with ‘stuff’ that finds it increasingly difficult to work with other ‘stuff’ that does support the Standards and methodology fit

19. Customer requirements • What is this ? • Ability of the technology / architecture to implement what the person sponsoring or financing the project or operational area wants in terms of functionality; • Includes security, integration, business process, look & feel and a host of others; • Difficult to keep track of ! • Requirements definitions can provide a ‘scoped’ view of what is required but often miss out on the bigger picture.

20. Customer requirements • Why is this important ? • Obviously sponsors want their objectives met by means of their requirements being satisfied; • When sponsors requirements cannot be met expensive workarounds (often with accompanying scope creep) are often used to achieve a compromise between what the technology / architecture is capable of and what is ‘required’; • Very subtle but true – if you can meet the customers requirements and the undertaking fails it is more difficult for them to shift the blame on to you and your technology / architecture choice;

21. Customer requirements • Good fit to this driver; • Less risk of scope creep, expensive compromises or abandonment; • Bad fit to this driver; • Significant credibility problems for the technology / architecture choice and related parties; • Good place to shift blame for failure;

22. User functionality requirements • What is this ? • Giving the user something that they can understand and use effectively; • Understanding is achieved typically via simplicity and the use of common standards & conventions (eg: common look and feel by both ‘house’ and wider standards) ; • Key concept : Users are not always customers – users ‘use’ the technology or architecture customers pay for it;

23. User functionality requirements • Why is this important ? • Premise 1: Easy to use systems don’t just look good they feel good to the user; • Premise 2 : When things go wrong easy to use systems either recover gracefully or tell you what needs to be done to get things going again. • Both premises reduce costs associated with lack of user acceptance and other related costs including downtime..

24. User functionality requirements • Good fit to this driver; • Goodwill , Credibility & accompanied greater lee way for other areas [read problems]; • Bad fit to this driver; • Pushback from users can be detrimental to the implementation regardless of any other merits it displays; • As the most ‘visible’ part of the implementation it has the greatest impact on quality perceptions;

25. Timeliness • What is this ? • New - Ability to build & deploy quickly to point of productive utilisation; • Existing - Ability to change & deploy quickly to point of productive utilisation or problem remediation or both; • Productive utilisation by the business is the key point here – covers from ‘pain’ to ‘gain’. • Key Concept: Pain to Gain;

26. Timeliness • Why is this important ? • Has direct impact on productivity and ROI measures when in place; • Has a more subtle but still major impact on Customer & User satisfaction; • Enterprise agility;

27. Timeliness • Good fit to this driver; • Technology or architecture perceived as agile and productive (TIME / Cost / Quality); • Bad fit to this driver; • Perceptions of expense, poor quality, over complication and the use of technology / architecture that lacks focus on business; • ‘Blame fly-paper’ syndrome;

28. Life Expectancy • What is this ? • How long is your technology going to be ‘supported’ by the supplying vendor or community; • How accepted are the key tenets beneath your architecture;

29. Life Expectancy • Why is this important ? • If you cannot rely on others for affordable support you are going to be either stuck with an ‘orphan’ or an expensive self help exercise; • More subtle but still major – what is the true cost (both up front and in terms of opportunity costs) of having something that is not receiving incremental functionality and critical support ;

30. Life expectancy • Good fit for this driver; • When the business case question is asked (and it will) you will have a credible answer; • Reduced risk of expensive workarounds / substitution sooner or later; • Bad fit for this driver; • Significant risk of failure or expense introduced; • Significant risk of other drivers being ‘turned’ from good to bad – for example skills availability as skills exit a dying market for an obsolete technology or approach;

31. Tangible Costs • What is this ? • Costs of procurement + ( ( Annualised Cost of ownership * Expected life in years ) * 1.x ) + Estimated cost of retirement; • Many use an annualised cost that takes into account NPV or other accepted cash flow approach; (either discounted or non-discounted) • Some include identified opportunity costs;

32. Tangible costs • Why is this important ? • Decision investment - obvious; • More subtle but still major – what impact is this going to have on aggregated IS/ IT spend (how big a profile in the overall scheme) – this can drive the risk management approach in some organisations; • Quantifiable hard accountability metrics can be ‘career limiting or enhancing’;

33. An Example of applying the 8 Drivers in the context of a process: Evaluation Proposal Evaluation Implementation Review ( Upgrade, Replace, Retire, Reset ) Retire

34. Business Case. Technology Life cycle Management Process EA Refers to 8 Drivers Evaluation Proposal Drivers applied to process specified in EA Evaluation Implementation Review ( Upgrade, Replace, Retire, Reset ) Retire

35. Example: IT Delivery Architecture of the Enterprise Architecture of Ministry of Education TISSL (New Zealand)

36. A chain is as strong as ….

37. Call to Action • Evaluate your current approaches to technology and architecture selection – can you identify significant risks based around skills, timeliness, life expectancy or other factors; • Consider if some of the business drivers I’ve just outlined can help reduce those risks; • Do you have a robust process to apply your business drivers appropriately and consistently both to new and existing choices;

38. © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.