slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Agile Enterprise Architecture: A step change is required PowerPoint Presentation
Download Presentation
Agile Enterprise Architecture: A step change is required

Loading in 2 Seconds...

play fullscreen
1 / 34

Agile Enterprise Architecture: A step change is required - PowerPoint PPT Presentation


  • 169 Views
  • Uploaded on

Charles Edwards Version: 1.02 Date: 10 June 2009. Agile Enterprise Architecture: A step change is required. Background. So who’s this Charles guy?. Today’s Objectives. Something for all audience types: For Enterprise Architects Quick understanding of “Agile EA”

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

Agile Enterprise Architecture: A step change is required


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
    Presentation Transcript
    1. www.AgileEA.com and Process.AgileEA.com

    2. Charles Edwards Version: 1.02 Date: 10 June 2009 Agile Enterprise Architecture:A step change is required www.AgileEA.com and Process.AgileEA.com

    3. Background • So who’s this Charles guy? www.AgileEA.com and Process.AgileEA.com

    4. Today’s Objectives • Something for all audience types: • For Enterprise Architects • Quick understanding of “Agile EA” • Look at what these Step Changes are? • For C*Os • Discuss Enterprise Technical Debt • The implications of Architectural decisions • For Industry and Enterprise • Practical experiences - Strengths & Weakness of EA • Let’s get some Urgency and Openness into it all! www.AgileEA.com and Process.AgileEA.com

    5. What is “Agile EA” (Open source EA) www.AgileEA.com and Process.AgileEA.com

    6. AgileEA - Why? • Where did the idea come from? • Did a TOGAF 8.1 course in 2006 and loved the content • Left feeling TOGAF needed more (v9 is much better now) • In general however issues in EA are: • Structure – missing “easy” Operational Process • Modernisation – missing Agile, Adaptive, Services • Integrated tools – not only about visual modelling • Pragmatism & Urgency – embed EA, add value quick • Examples – What does “good” EA look like? • Openness – freely available to all at no cost • Extendibility – allow for an easier selection of techniques and plug-in components www.AgileEA.com and Process.AgileEA.com

    7. AgileEA - How? • Delivered as a • Human readable static Website. Not an executable business process tool. • Developed using a free open source tool called Eclipse Process Framework (EPF). • It follows a rigorous process meta-model (SPEM) www.AgileEA.com and Process.AgileEA.com

    8. AgileEA - What? • AgileEA is a blend of • Agile & Adaptive ideas - taken from software development • Enterprise Architecture ideas from multiple sources • Operational Process for EA's to follow - help introduce and build EA • Build Maturity– to run EA while also maturing EA in an organization • Crawl • Walk • Run www.AgileEA.com and Process.AgileEA.com

    9. AgileEA - Where? • In a SaaS form – usabledirectly off the internet • As-is / out the box – Download, deploy and use locally • Tailor it to suit your Co’s processes & terminology Download, tailor and deploy locally • Use in one of three scenarios: www.AgileEA.com and Process.AgileEA.com

    10. AgileEA – When? • Started in Dec 2006, now 2½ years old. • Part time work-in-progress • New iterative release every 3 or < months • Still in Beta – 2009.0.039 aiming for late 2009.1.000 www.AgileEA.com and Process.AgileEA.com

    11. AgileEA – Whom? • Loose collaboration with many peers • At work taking actual day-2-day experiences • Previous work peers and experience • Industry collaboration, in particular • Guy Tozer – Doriq.com • Kevin Lee Smith – PragmaticEA.com • Tom Graves – Tetradian.com • Roger Sessions – Simple Iterative Partitions (SIP) • Nigel Green – VPEC-T • ±200 registered international users on the site • Newly formed Linkedin.com forum has ±85 users www.AgileEA.com and Process.AgileEA.com

    12. What are theseStep Changes? www.AgileEA.com and Process.AgileEA.com

    13. Step Changes? To get to the next level Enterprise Architecture needs: • Agility and Adaptive-ness – speed and time • Pragmatism & Urgency – Ease of starting & quick results • Structure& Rigour – What does a “good” EA look like? • Integrated – concepts & support Tools • Openness – Bringing all the puzzle pieces together • Cultural – People & awareness make the change happen • Architectural implications – Enterprise Technical Debt www.AgileEA.com and Process.AgileEA.com

    14. Agility & Adaptive-ness • Traditional EA approach  Takes too long to deliver value • Long (months and years), • Structured (framework, serial) • Very rigid (project plans), • Cannot adapt to change (because of above points) • Business become impatient and terminate efforts. • New EA approach  To benefit from “duality” • Fix Causes - using a Rigid Structure – Yin • React to Symptoms - The ability to change direction quickly – Yang • Build a Structure to accommodate change while in full flow • Allow Engine to rev faster and go quicker • Yet stable enough to regularly change direction and win. Excellent Speed. Able to direction change quickly. Slow. Unstable under quick direction change. www.AgileEA.com and Process.AgileEA.com

    15. Pragmatism & Urgency http://www.pragmaticea.com/frameworks.htm www.AgileEA.com and Process.AgileEA.com

    16. Structure & Rigour • Model of the structure www.AgileEA.com and Process.AgileEA.com

    17. Structure – Multi Views & Viewpoints • AgileEA is split into 2 groups of Architecture Views • Enterprise Architecture View and • Software Project Architecture View Project Architecture Views Enterprise Architecture Views www.AgileEA.com and Process.AgileEA.com

    18. Integration – ideas & tools UML, Archimate Workflow & Change Control Risk Actionable Enterprise Architecture – not just Diagrams and Models of Architecture, but Workflow, Risk, Change control & Governance of Architecture, with Architecture Business Intelligence. Backed by databases of related text. Architecture Business Intelligence www.AgileEA.com and Process.AgileEA.com

    19. Openness • Collaboration & Sharing of ideas openly • Scaffold - to implement new concepts & ideas within • Neutrality - without • Intellectual Property and • Financial issues www.AgileEA.com and Process.AgileEA.com

    20. Cultural & Human • People love the status quo = comfort zone • People’s reluctance to change is legendary • Simply defining new processes won’t make people change • So why define an Operational Process then? • However – • Examples always help • Tangible - what “good looks like” helps people relate • Re-use – we must stop re-inventing the wheel • Good cross-ref to EA Frameworks • Good cross-ref to EA Tools • Gets the discussion going www.AgileEA.com and Process.AgileEA.com

    21. Architectural implications • Do Business people understand the implications of Architectural decisions? • The concept of Enterprise Technical Debt • Enterprise “Karma” Karma = “causalitythrough a system where beneficial effects are derived from past beneficial actions and harmful effects from past harmful actions, creating a system of actions and reactions” • Notion of gathering Interest on unpaid off Debt & ever mounting loan amounts. www.AgileEA.com and Process.AgileEA.com

    22. Practical ExperiencesStrengths & Weaknesses of EA www.AgileEA.com and Process.AgileEA.com

    23. Manage - Iterative planning • Poor – no acceptance except in software development circles of “iterative” (SCRUM) • Iterative - Very weak where I’ve worked… • Difficult to get interest and enthusiasm • Software “techies” get it – rest do not • Minimal architecture interest in Feedback loops • Too busy fighting fires daily than preventing them up front • Manage Risk by defining mitigating actions www.AgileEA.com and Process.AgileEA.com

    24. Manage - Governance • Good – lots of industry marketing • Using MS Sharepoint Lists / Wiki’s to keep lists of: • Architectural Decision lists • Architectural Waivers & Dispensation lists • Architecture Work Triage lists • Architecture Principles & Policy lists • Architecture Standards lists • Etc … • Not a lot of EA Tool support for the above items www.AgileEA.com and Process.AgileEA.com

    25. Manage - People • Reasonable – general industry understanding • Tools & processes? • Architect Work Demand lists • Architect Resource planning lists • Ensure roles well defined and hired to fit • Training lists • Too much pressure to fire fight – symptoms • Not enough invested in proactive causes www.AgileEA.com and Process.AgileEA.com

    26. Manage - Risk • Reasonable – medium industry marketing • Some get it, some do not. • Business users seem far more aware of this than IT • Using MS Sharepoint Lists / Wiki’s to keep lists of: • Architectural Risk lists (prioritised) • Risk taxonomies and categorisation lists • Architectural Action and Mitigation lists  feeds planning www.AgileEA.com and Process.AgileEA.com

    27. Manage - Communications • Reasonable – medium industry marketing • In Business some get EA, many do not. • Still way too much emphasis on EA in IT only - e.g. • Do an IT Strategy • Then fail to sell it to the Business • Problems when projects have to adhere to the IT strategy • Strategic Ownership and Decision making should be at CxO level not buried within IT. • Senior business execs should share the Risks and implications of their decisions www.AgileEA.com and Process.AgileEA.com

    28. Foundation - Process & Tools • Poor – EA industry marketing is primarily concerned with Modelling & frameworks • Process: is improving (Togaf 9 now in EPF) • Tools: an awareness of integrated enactment tools is now emerging • When will we have a suite of modules to run EA like we have a suite of ERP modules to run the business? • An integration of • Visual Modelling • Actionable enactment and control of Architecture • Shared information portals, etc • Hooks into BPM tools, CMDB tools, Project management, etc. www.AgileEA.com and Process.AgileEA.com

    29. Foundation - Configuration Mngt • Poor – industry marketing appears unaware • Leave it up to other tools • Not well understood in general • Most think CM applies to code only • Most think CM only covers version control • Confusion about Change Control & Configuration management • Automated Release management • CM in ITIL is different to CM for software development • We need CM for Architecture • To be able to baseline the Enterprise Architecture • in monthly or quarterly increments • Use this to generate Architecture KPI’s www.AgileEA.com and Process.AgileEA.com

    30. Foundation - Change Control • Reasonable – medium industry marketing • Disarray in Architecture from my experience • Multiple tools – lack consistency • From Help desks, excel, to ticketing systems, to Visual models, to BPM to MS Sharepoint lists and Wiki’s • Multiple processes • Various lifecycles require various State transitions • Software delivery change control • EA Visual Models change control • Project change control • Strategy change control (governance, plans, etc.) www.AgileEA.com and Process.AgileEA.com

    31. Architecture • Business Architecture Discipline • Poorbut Improving (VPECT-T, SIP, many more...) • Business are taking their own initiative • Info Systems Architecture Discipline • Reasonable in general • Applications & Data better but only Operationally focused not Support focussed • Weak around Services • Infrastructure Tech Architecture Discipline • Better • Often not well modelled however www.AgileEA.com and Process.AgileEA.com

    32. Wrap up www.AgileEA.com and Process.AgileEA.com

    33. Conclusion • For the Enterprise - step changes are: • Get Agile - Iterative & Adaptive continuously improving • Get Pragmatic & Urgent – To get results quick & easy • Cultural – People really make the change happen • Communicate – Share the Architectural challenges & risks • For the EA Industry: • Openness – Common framework for all puzzle pieces • Tool Integration – support Process concepts with Tools • Structure & Rigour – Show what a “good” EA looks like? • Educate Business in Architectural understanding – Enterprise Technical Debt  Implications of decisions. www.AgileEA.com and Process.AgileEA.com

    34. Thought for the day • Lean value of Kaizen (literally means "change good").  • For Toyota the immediacy of Kaizen is summed up as: "We must be noticeably better than last year...and it's a crisis" www.AgileEA.com and Process.AgileEA.com