Download/display Word Perfect

278
-1

Published on

Published in: Technology, News & Politics
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
278
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • There are arguably 3 recognised and established frameworks: Zachman TOGAF FEAF Contemporary attempts include: Agile Enterprise Architecture (AES) Simple Iterative partitions (SIP) Enterprise Unified Process (EUP) Gartner is not a framework, but produces valuable insight on the field and is a useful reference model. After researching the methodologies, observations are: None of the methodologies are complete. There are merits in all of the approaches and common themes appear. There is now information available that helps us understand why the older methodologies failed. There is no process to follow. The framework is not specifically tailored to information technology. Some concepts are outdated. Consensus is that not all models are required. Taxonomy of artifacts does not produce an Enterprise Architecture. Architecture is a verb , not a noun. (it constantly evolves, not a one-off task) The newer methodologies generally try and address the shortcomings of the older methodologies. Recommendation is to use the bits of each methodology that “works” and adopt a hybrid approach. Understand the reasons for historic failure and ensure the hybrid model avoids these. Continue to evolve and modify your EA, remember EA is a verb, not a noun.
  • Guidelines “ And thirdly, the code is more what you call "guidelines" than actual rules” Disney's – Pirates of the Caribbean – Curse of the Black Pearl Direction The compass was unusual in that it did not point due north, but rather pointed to the thing the holder wanted most at that moment Roadmap The fountain of youth, worlds end – try not to have these in your roadmap
  • 2004 – Bright and Shiny and new – we dabbled 2005 – We ‘decided’ we needed an architectural view across a major change initiative initiating in the organisation at the time – we didn’t know how to do it – so we did what most organisations did and brought in consultants to help us, what was delivered was actually very good and has guided a lot of our thinking in the IT infrastructure space over the last 3 years. 2006 – The ‘silver bullet’ – ‘build it and they will come’ 2007 – The realisation that architecture is not an organisational change programme, nor can it replace one - it cannot replace the communication and commitment that is required to support such an initiative 2008 – Consolidation in relation to the ‘ready’ areas of the business 2009 – Initial platform implementations beginning to take shape, supported by relevant business areas, positive reinforcement of approaches
  • Be prepared to make the first move – you will be surprised the increased level of engagement if you make the effort, and what that will help you understand what business drivers are ‘lurking beneath the surface’
  • Over-arching approach People then Processes then Methods then Software / Systems / IT Important to work with the business people in the organisation (eg statistical analysts, methodologists, data collection, publishing) in order to streamline and standardise processes and methods – Align this with the understanding of the business drivers – it may not be aligned (A big problem), prior to starting to design and build ‘standardised’ solutions.
  • The ‘War Room’ Not distracted Focussed Room for everyone Use walls and whiteboards Had too many at first – but they soon solidified to a core set of people
  • Download/display Word Perfect

    1. 1. Examining Different Architectural Models to get Best Fit with your Organisation CASE STUDY: “Evolving Architecture in Statistics NZ ” Presented by: Rosemary McGrath Enterprise Architecture Manager Statistics New Zealand
    2. 2. Agenda <ul><li>Drivers for Change </li></ul><ul><li>Architecture ‘A’ Definition </li></ul><ul><li>Architecture – the ‘tools’ of the trade </li></ul><ul><li>A History of Architecture at Statistics NZ </li></ul><ul><li>Conclusions - Everything Evolves </li></ul><ul><li>What is Shaping Where we Evolve to Next? </li></ul><ul><li>Questions </li></ul>
    3. 3. Drivers for Change <ul><li>Fiscal Sustainability </li></ul><ul><ul><li>Reduce the risk, time and cost of new statistical developments </li></ul></ul><ul><ul><li>Maintain or reduce Total Cost of Ownership (TCO) </li></ul></ul><ul><li>Increased Operational Efficiency </li></ul><ul><ul><li>Strengthen the application of common classifications and standards across subject matter areas </li></ul></ul><ul><ul><li>Enable continuous improvement through the increased adoption of standards, improved methodologies and best practice </li></ul></ul><ul><li>Enhancement of Statistical Effectiveness </li></ul><ul><ul><li>Increase utilisation of administrative data </li></ul></ul><ul><ul><li>Expand Statistics NZs role in leadership of the Official Statistics System (OSS) </li></ul></ul><ul><ul><li>Enable increased demand for access to timely and relevant statistical data to be met </li></ul></ul>
    4. 4. Architecture – “A” Defintion <ul><li>An often used/abused term </li></ul><ul><li>ANSI/IEEE Std 1471-2000 is: &quot;the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.&quot; </li></ul><ul><li>This is a definition I like – and reflects the way I like to look at ‘what architecture is’ </li></ul><ul><li>“ Architecture is the use of abstractions and models to simplify and communicate complex structures and processes to improve understanding and forecasting .” </li></ul><ul><li>http://blogs.technet.com/michael_platt/archive/2006/03/27/423300.aspx </li></ul>
    5. 5. Architecture – The tools of the trade <ul><li>Architectural Frameworks </li></ul><ul><ul><li>There are quite a few of them – Zachman, TOGAF, FEAF are probably the most well known </li></ul></ul><ul><ul><li>For one perspective on an assessment across the frameworks </li></ul></ul><ul><ul><li>http://msdn.microsoft.com/en-us/library/bb466232.aspx </li></ul></ul><ul><li>Architectural Principles </li></ul><ul><ul><li>Each framework has a set of principles </li></ul></ul><ul><ul><li>The are very similar </li></ul></ul><ul><ul><li>They are not contentious </li></ul></ul><ul><li>Architectural Models </li></ul><ul><ul><li>Domain models – Static. </li></ul></ul><ul><ul><li>BPMN – Dynamic. </li></ul></ul><ul><ul><li>Enterprise models - Big picture </li></ul></ul><ul><ul><li>Deployment – Infrastructure/support </li></ul></ul><ul><ul><li>Models for technical audience may include Class, Component, ERD etc – all UML based </li></ul></ul>
    6. 6. Architecture – The tools of the trade – a learned view <ul><li>Guidelines </li></ul><ul><ul><li>Help people </li></ul></ul><ul><ul><li>Clarify understanding </li></ul></ul><ul><ul><li>Support implementation </li></ul></ul><ul><li>Direction </li></ul><ul><ul><li>Options are key </li></ul></ul><ul><ul><li>Feedback </li></ul></ul><ul><li>Roadmap </li></ul><ul><ul><li>Let everyone understand </li></ul></ul><ul><ul><li>Have clear milestones and deliverables </li></ul></ul><ul><ul><li>Be attainable (believed to be attainable) </li></ul></ul>
    7. 7. A History of Architecture at Statistics NZ <ul><li>Acknowledgement – Gartner Hype Cycle </li></ul><ul><li>http://www.gartner.com </li></ul>2004 2005 2006 2007 2008 2009
    8. 8. Some ‘hard’ lessons learned <ul><li>Having artefacts does not equate to having an architecture. (wide criticism) </li></ul><ul><li>Do not take an extremely structured systematic top-down approach to establishing an EA. “This type of approach works well when applied to complex but fixed domains, such as building or aircraft construction, but is completely inappropriate when applied to emergent (dynamic) domains such as economies or enterprises.” (Gartner) </li></ul><ul><li>It is OK to have gaps </li></ul><ul><li>Accept that there are various levels of acceptance of change (any change) across the organisation, find those that will partner with you </li></ul><ul><li>Find some champions, champion architecture, market (not a common skill) </li></ul><ul><li>Always present options – everyone wants a choice </li></ul><ul><li>Architecture is a verb not a noun. </li></ul>
    9. 9. Remember!!
    10. 11. Early Problem 1 Architecture, SOA, Web services, Reuse ##$@@!! %%^&&& **&^% ##$%#@ !
    11. 12. What has helped us? – The generic Business Process Model <ul><li>To define our business processes, we </li></ul><ul><ul><li>identified the enterprise wide business processes </li></ul></ul><ul><ul><li>abstracted at the business level, NOT the data level or ‘system’ level, and </li></ul></ul><ul><ul><li>Stayed at the common level – generally activity, not task </li></ul></ul><ul><ul><li>used commonly understood terms to be inclusive </li></ul></ul>
    12. 13. Early Problem 2 <ul><li>Challenges - Misalignment of strategies, plans, outputs and outcomes (impacts governance, funding, capability) – What is the ‘right’ architecture </li></ul>
    13. 14. How has our approach changed? People Process Methods Software Process Methods Software People Time
    14. 15. What has helped us? – The Domain Model
    15. 16. What is a Domain model ? <ul><li>Conceptual model of a system which describes the various real world entities involved in that system and their relationships </li></ul><ul><li>Communication tool to validate and verify the understanding of the business domain between various groups. (Technical and non-technical) </li></ul><ul><li>Structural view of the system, complemented by the dynamic (process) views in Use Case models/ User stories </li></ul><ul><li>Domain models (partial) are an important decomposition tool, view the system in many contexts using entities and relationships </li></ul><ul><li>Domain model should apply to the industry – Common Taxonomy </li></ul>
    16. 17. What has helped us? – The ‘War’ room
    17. 18. Conclusions <ul><li>Everything Evolves </li></ul><ul><li>There is a light at the end of the tunnel </li></ul>We’re doing what we can to ensure it’s not a train!!
    18. 19. What are we doing next?
    19. 20. The Relevant Views/Perspectives for ‘our’ Architecture Framework
    20. 21. Starting to complete the jigsaw
    21. 22. Re-Invigorating the Architecture Service Model 1. 2. 3. 4. 5.. Procurement Project Management Change/ Release Management Procurement Project Management Change/ Release Management Architecture Compliance Process Business Strategic Elements IT Strategic Elements Architecture Review Process Business Strategic Elements IT Strategic Elements Architecture Review Process Enterprise Architecture Framework Documentation Architecture Governance Architecture Blueprints Architecture Communications Plan Statistics NZ Enterprise Architecture Framework Documentation Architecture Governance Architecture Blueprints Architecture Communications Plan Architecture Documentation Process Architecture Blueprint Process Architecture Framework Process Architecture Communication Process
    22. 23. Agile with SCRUM <ul><li>What we have noticed so far </li></ul><ul><ul><li>Scrum is an implementation of agile methods and practices </li></ul></ul><ul><ul><li>‘ Agile Architecture’, ‘just enough architecture - allowing for the big, long-term picture as well as the fluid nature of implementation, within 2 week sprints </li></ul></ul><ul><ul><li>Makeup of the teams is important, cross functional and relevant to the current priorities </li></ul></ul><ul><ul><li>There is a shift to architecture becoming a stakeholder instead of a 'prescriber' allowing the focus to change from technology or techniques to working iteratively and incrementally within project teams. </li></ul></ul>
    23. 24. Questions?
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×