Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Agile architecture

505 views

Published on

Published in: Design, Business
  • Be the first to comment

Agile architecture

  1. 1. The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2010
  2. 2. IASA is  a non-profit professional association  run by architects  for all IT architects  centrally governed and locally run  technology and vendor agnostic The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly
  3. 3. What is “creates value”? What is Good? suitable or efficient for a purpose beneficial or advantageous
  4. 4. Architecture Value • Profitability • Constituent Value • Reuse • Grow Market Size • Grow Market Quality
  5. 5. What is an Architecture? The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2010 DocumentVisual Design Decision  Is it the architectu re or the container  Can you have an architectu re with no document ation?  What distinguish es a design from an architectur e?  Is the decision to use http an architectur e?  How many decisions make up an architectur e? Value  What does it contribute?  How do we define good and best?
  6. 6. Design Document – Engineer  The system will use a thin client  This will remove the need to install a client as all systems already have these installed.  Some users need to access the system from a remote sight.  The system will support Internet Explorer version 9 and Firefox version 4.4 and above.  These browsers are a part of our corporate standard image for client machines.  Other browsers are not allowed on the desktop. The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2010 Mozilla/IE Client ClientApplication Servers DB
  7. 7. Technical Model Innovation - Architect  Thin Client  4.4 million new clients  Total Profit of $440,000,000  IE + Firefox and Nothing Else  IE = $240,000,000  Firefox = $200,000,000  Other browsers = - $40,000,000 The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2010 Mozilla/IE Client ClientApplication Servers DB
  8. 8. Architecture Purpose The Architect’s Preferences People Realized Value External Customer Balanced Enterprise Process/Tools Working Technology Internal Customer Localized Optimization
  9. 9. v
  10. 10. Issues in Agile  Seeing beyond the iteration/task  Challenging Agile Assumptions  Working software is important?  Unit testing is always a good idea?  Do we really need good developers?  Should developers and users make business decisions?  Are stakeholders actually important?  If business isn’t agile why worry about software?  Do investment cycles and budgeting limit agility to a side show?  Can agile handle governance?  Can agile include enterprise architecture?  Are documents really valueless?
  11. 11. Agile Architecture  If architecture is value then agile teams must change  Most importantly agile teams must have architects  Must be enterprise aware support existing roadmaps, bottom up governance and strategy  Is document focused (there is no architecture without documents) – but just good enough  Requires significant growth in architect team size
  12. 12. Agile Architecture  Participates in each sprint/iteration cooperatively  Is there for a different reason than developers  May include multiple types of architecture  May work to reduce scope or limit appearance of agility
  13. 13. Architects Are Not Technical Leads  Senior Software Engineers Are Not Architects ExperienceandLevel Engineer Architect ExperienceandLevel
  14. 14. Architecture Engineering Business Unit roject Management Quality
  15. 15. Agile Architecture Innovation
  16. 16. Enterprise Architecture and Agile
  17. 17. Select Projects • Create/Review business case • Calculate and communicate value • Prioritize and select • Assign architects Create Architecture(s) • Capture and analyze requirements • Architecture master •Generic architecture •Product specific architecture •Architecture Prototype • Views/viewpoints Deliver Architecture(s) • Stakeholder communication • Modify and update artifacts • Delivery Manage Architecture • Review and analyze value • Set architecture goals • Update Engagement Model • Communicate value Higher Level Project Level Core – Scoping Levels in the Organization
  18. 18. Why You Should Care – To Be Set Goals FundExecute Measure C-Suite Portfolio Mgmt. GovernanceMilestone Review Asset Mgmt. EAs Plan Design Deliver Measure Design Project Architects Project Architects Project Architects Project Architects Project Teams Project Teams Project Teams Project Teams Project Teams
  19. 19. Lifecycles Set Goals FundExecute Measure C-Suite Portfolio Mgmt. GovernanceMilestone Review Asset Mgmt. EAs Plan Design Deliver Measure Design Project Architects Project Architects Project Architects Project Architects Plan DesignDeliver Measure Solution Teams Plan DesignDeliver Measure Solution Teams Plan DesignDeliver Measure Solution Teams Plan DesignDeliver Measure Solution Teams Plan DesignDeliver Measure Solution Teams Plan Desi gn Deliv er Mea sure Solution Teams Plan Desi gn Deliv er Mea sure Solution Teams Plan Desi gn Deliv er Mea sure Solution Teams Plan Desi gn Deliv er Mea sure Solution Teams Plan Desi gn Deliv er Mea sure Solution Teams Plan Desi gn Deliv er Mea sure Solution Teams Plan Desi gn Deliv er Mea sure Solution Teams Plan DesiDeliv Mea sure Solution Teams Plan Desi gn Deliv er Mea sure Solution Teams Plan Desi gn Deliv er Mea sure Solution Teams Plan Desi gn Deliv er Mea sure Solution Teams Plan DesiDeliv Mea sure Solution Teams Plan Desi gn Deliv er Mea sure Solution Teams Plan Desi gn Deliv er Mea sure Solution Teams Plan Desi gn Deliv er Mea sure Solution Teams Plan DesiDeliv Mea sure Solution Teams Plan Desi gn Deliv er Mea sure Solution Teams Plan Desi gn Deliv er Mea sure Solution Teams Plan Desi gn Deliv er Mea sure Solution Teams Plan Desi gn Deliv er Mea sure Solution Teams Plan Desi gn Deliv er Mea sure Solution Teams Plan Desi gn Deliv er Mea sure Solution Teams Plan Desi gn Deliv er Mea sure Solution Teams Plan Desi gn Deliv er Mea sure Solution Teams Plan Desi gn Deliv er Mea sure Solution Teams Plan Desi gn Deliv er Mea sure Solution Teams Plan Desi gn Deliv er Mea sure Solution Teams Plan Desi gn Deliv er Mea sure Solution Teams Plan Desi gn Deliv er Mea sure Solution Teams Plan Desi gn Deliv er Mea sure Solution Teams Plan Desi gn Deliv er Mea sure Solution Teams Plan Desi gn Deliv er Mea sure Solution Teams Plan Desi gn Deliv er Mea sure Solution Teams Plan Desi gn Deliv er Mea sure Solution Teams Plan Desi gn Deliv er Mea sure Solution Teams Plan Build Run
  20. 20. Enterprise Lifecycle Goals Innovation Enterprise Lifecycle Select Create Deliver Manage Select Create Deliver Manage Select Create Deliver Manage
  21. 21. Lifecycle Extended Prioritization Delivery Return Cost Sales Finance IT Pipeline Ideation Changes to Current State
  22. 22. Disciplined Agile Delivery (DAD) is a process decision framework The key characteristics of DAD:  People-first  Goal-driven  Hybrid agile  Learning-oriented  Full delivery lifecycle  Solution focused  Risk-value lifecycle  Enterprise aware © Disciplined Agile Consortium 32
  23. 23. Scrum Extreme Programming LeanKanban DAD is a Hybrid Framework © Disciplined Agile Consortium 33 Unified Process Agile Modeling Agile Data“Traditional”Outside In Dev. DevOps …and more DAD leverages proven strategies from several sources, providing a decision framework to guide your adoption and tailoring of them in a context-driven manner. SAFe
  24. 24. A High Level Lifecycle © Disciplined Agile Consortium 34
  25. 25. Disciplined Agile Delivery: Basic Lifecycle © Disciplined Agile Consortium 35 DAD promotes a full delivery lifecycle
  26. 26. Disciplined Agile Delivery: Lean Lifecycle © Disciplined Agile Consortium 36 DAD doesn’t prescribe a single lifecycle
  27. 27. Disciplined Agile Delivery: Lean Continuous Delivery Lifecycle © Disciplined Agile Consortium 37 Advanced product teams follow a continuous delivery approach
  28. 28. DAD supports a robust set of roles  Team Lead  Agile process expert, keeps team focused on achievement of goals, removes impediments  Product Owner  Owns the product vision, scope and priorities of the solution  Architecture Owner  Owns the architecture decisions and technical priorities, mitigates key technical risks  Team Member  Cross-functional team members that deliver the solution  Stakeholder  Includes the customer but also other stakeholders such as Project Sponsor, DevOps, architecture, database groups, governance bodies © Disciplined Agile Consortium 38
  29. 29. DAD Teams Are Enterprise Aware  DAD teams strive to leverage and enhance the existing organizational eco system wherever possible  Implications:  Work closely with enterprise groups  Follow existing roadmap(s) where appropriate  Leverage existing assets  Enhance existing assets © Disciplined Agile Consortium 39
  30. 30. Governance is Built Into DAD  Governance strategies built into DAD:  Risk-value lifecycle  Light-weight milestone reviews  “Standard” opportunities for increased visibility and to steer the team provided by agile  Enterprise awareness  Robust stakeholder definition © Disciplined Agile Consortium 40
  31. 31. Context Counts – Tailoring and Scaling Agile © Disciplined Agile Consortium 41 Agile Disciplined Agile Delivery Agility at Scale • Construction focus • Value driven lifecycle • Self-organizing teams • Prescriptive • Project team aware • Delivery focus • Risk-value driven lifecycle • Self-organization with appropriate governance • Goal driven • Enterprise aware DAD provides the foundation from which to scale:  Large teams  Geographically distributed teams  Compliance  Domain complexity  Technical complexity  Organizational distribution
  32. 32. Questions

×