1 / 34

Agile Enterprise Architecture: A step change is required

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”

bonnie
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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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

More Related