Agile Enterprise Architecture? Oxymoron or Savior?
5 likes2,699 views
The document discusses enterprise architecture (EA) and how it can be approached in an agile manner. It provides definitions of EA, describes what EA teams typically produce. It also shares results from surveys that show many organizations have both EA programs and agile projects, but there is often a disconnect between the two. The document argues that a more disciplined and flexible approach to EA, such as the Disciplined Agile Delivery framework, can help bridge the gap between EA and agility.
![A more disciplined
approach to agile solution
delivery will help
scott_ambler [at] ca.ibm.com
twitter.com/scottwambler
www.ibm.com/developerworks/mydeveloperworks/blogs/ambler/
www.ibm.com/rational/agile/
www.jazz.net
16](https://image.slidesharecdn.com/agileenterprisearchitecture-120309224229-phpapp02/85/Agile-Enterprise-Architecture-Oxymoron-or-Savior-16-320.jpg)
Agile Enterprise Architecture? Oxymoron or Savior?
- 1. Agile Enterprise Architecture: Oxymoron or Savior? Scott W. Ambler Chief Methodologist for Agile and Lean, IBM Rational www.ibm.com/developerworks/blogs/page/ambler twitter.com/scottwambler © 2012 IBM Corporation What is Enterprise Architecture? Enterprise Architecture Success Factors Agile vs. Enterprise Architecture Agile and Enterprise Architecture Parting Thoughts 1
- 2. EA as a Process The process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise's future state and enable its evolution Source: Gartner EA as an Artifact The organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the company's operating model. The operating model is the desired state of business process integration and business process standardization for delivering goods and services to customers. Source: MIT Center for Information Systems Research (CISR) 2
- 3. What do Enterprise Architects Produce? Business goals 67% System inventory 65% Architecture principles 64% Development guidelines 55% Reference architectures 44% "As is" models 38% "To be" models 33% White papers 29% Source: Dr Dobb’s January 2010 State of the IT Union Survey Do you have an EA program? No 34% 30% Yes 17% Yes, and expanding 10% 9% No, but we’re thinking about starting one No, but I’ve experienced EA in other organizations Source: Dr Dobb’s January 2010 State of the IT Union Survey 3
- 4. Why Should You Care? Complexity Agility * Collaboration * Automation Reduce Resources = Complexity Increase Agility Improve Collaboration Add Automation Economic Productivity: Impacts 2x – 10x Timeframe is Years Productivity: 25-100% Productivity: Timeframe is Quarters 15-35% Productivity: Timeframe is Months Cost to Implement: 5-25% 25%-50% Timeframe is Weeks Much culture change Cost to Implement: 10%-35% Cost to Implement: Some culture change 5%-10% Cost to Implement: Predictable <5% Very predictable Organization Project Team Individual What is Enterprise Architecture? Enterprise Architecture Success Factors Agile vs. Enterprise Architecture Agile and Enterprise Architecture Parting Thoughts 4
- 5. Success Factors: People Issues #1 Active involvement of business leaders #2 Active involvement of IT leaders #3 Enterprise architects are active participants on project teams #4 Enterprise architects are trusted advisors of the business #5 Flexible enterprise architects Source: Dr Dobb’s January 2010 State of the IT Union Survey Success Factors: Business Issues #6 Having a business case for EA efforts #10 Cost reduction Source: Dr Dobb’s January 2010 State of the IT Union Survey 5
- 6. Success Factors: Process Issues #7 Continuous improvement/evolution of EA artifacts #8 Architecture reviews #9 Appropriate governance #11 Master data management (MDM) Source: Dr Dobb’s January 2010 State of the IT Union Survey Failure Factors: Business Issues #1 Insufficient time provided #3 Too difficult to measure benefits #6 No perceived benefit of EA program #7 No executive endorsement #10 Insufficient funding #12 Cancelled due to political issues #13 EA program successful but terminated Source: Dr Dobb’s January 2010 State of the IT Union Survey 6
- 7. Failure Factors: People Issues #2 Project teams didn't take advantage of the EA #4 Enterprise architects perceived as "ivory tower“ #8 Enterprise architects weren't sufficiently flexible #9 Enterprise architects perceived as impediment to success #11 EA perceived as not viable Source: Dr Dobb’s January 2010 State of the IT Union Survey Failure Factors: Process Issues #5 Development teams couldn't wait for enterprise architects Source: Dr Dobb’s January 2010 State of the IT Union Survey 7
- 8. We need to look at the big picture What is Enterprise Architecture? Enterprise Architecture Success Factors Agile vs. Enterprise Architecture Agile and Enterprise Architecture Parting Thoughts 8
- 9. Dueling Surveys Agilists Enterprise Architects “versus” Ambysoft February 2012 Agile Mini Survey EA Mini Survey 70% of their firms 49% of their firms have agile have an EA projects program underway 9
- 10. 15% say their EA teams work with 34% said their them well agile teams work with them well 18% think that 44% thought their EA teams that their agile work in an agile teams manner addressed architecture well 10
- 11. 47% believe 33% believe their agile their EA teams teams view EA view agile positively positively We need to build bridges 11
- 12. What is Enterprise Architecture? Enterprise Architecture Success Factors Agile vs. Enterprise Architecture Agile and Enterprise Architecture Parting Thoughts Focusing on construction is a great start… 12
- 13. Focusing on construction is a great start… … but isn’t the real goal to deliver a consumable solution? Eventually gradual improvement leads to a leaner approach 13
- 14. Agile Architecture Strategies Look beyond technology Initial requirements envisioning Initial architecture envisioning Prove the architecture with working code Architecture spikes Think about the future, but wait to act Architects also code Architecture owners, not architects Travel light Take a multi-view approach What is Enterprise Architecture? Enterprise Architecture Success Factors Agile vs. Enterprise Architecture Agile and Enterprise Architecture Parting Thoughts 14
- 15. Sometimes the situation isn’t always so simple… Disciplined Agile Delivery (DAD): The Foundation for Agility@Scale Team size Compliance requirement Under 10 1000’s of Critical, developers developers Low risk audited Geographical distribution Domain Complexity Straight Intricate, Co-located Global -forward emerging Disciplined Enterprise discipline Agile Organization distribution Project Enterprise Delivery (outsourcing, partnerships) focus focus Collaborative Contractual Organizational complexity Technical complexity Flexible Rigid Heterogeneous, Homogenous legacy 15
- 16. A more disciplined approach to agile solution delivery will help scott_ambler [at] ca.ibm.com twitter.com/scottwambler www.ibm.com/developerworks/mydeveloperworks/blogs/ambler/ www.ibm.com/rational/agile/ www.jazz.net 16
- 17. Backup Slides © 2012 IBM Corporation Some agile whitepapers on IBM.com The Agile Scaling Model (ASM): Adapting Agile Methods for Complex Environments – ftp://ftp.software.ibm.com/common/ssi/sa/wh/n/raw14204usen/RAW14204USEN.PDF Scaling Agile: An Executive Guide – ftp://public.dhe.ibm.com/common/ssi/sa/wh/n/raw14211usen/RAW14211USEN.PDF Improving Software Economics: Top 10 Principles of Achieving Agility at Scale – ftp://public.dhe.ibm.com/common/ssi/ecm/en/raw14148usen/RAW14148USEN.PDF Enable the Agile Enterprise Through Incremental Adoption of Practices – http://public.dhe.ibm.com/common/ssi/ecm/en/raw14077usen/RAW14077USEN.PDF Disciplined Agile Delivery: An Introduction – http://public.dhe.ibm.com/common/ssi/ecm/en/raw14261usen/RAW14261USEN.PDF 17
- 18. Disciplined Agile Delivery The Disciplined Agile Delivery (DAD) process framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value lifecycle, is goal-driven, scalable, and is enterprise aware. www.disciplinedagiledelivery.com Agile Scaling Model (ASM) Agile Development Focus is on construction Goal is to develop a high-quality system in an evolutionary, collaborative, and self-organizing manner Value-driven lifecycle with regular production of working software Small, co-located team developing straightforward software Agile Delivery Extends agile development to address full system lifecycle Risk and value-driven lifecycle Self organization within an appropriate governance framework Small, co-located team delivering a straightforward solution Agility at Scale Disciplined agile delivery and one or more scaling factors applies 18
- 19. The Surveys Data, summary, and slides downloadable from www.ambysoft.com/surveys/ Dr Dobb’s January 2010 State of the IT Union Survey – 374 respondents Ambysoft February 2012 Agile Mini Survey – 61 respondents Ambysoft February 2012 EA Mini Survey – 59 respondents For existing Enterprise Architecture (EA) programs, what has improved? (Rating between -10 and +10) 1. System integration (3.6) 2. IT governance (3.3) 3. Team follows common technology infrastructure (3.3) 4. Business efficiency (3.2) 5. Data integrity (3.2) 6. Continuity of organizational knowledge (3.0) 7. Business governance (3.0) 8. Audit compliance (2.9) 9. Risk management (2.9) 10. Technical integrity (2.8) 11. Operating costs (2.5) 12. Enterprise decision making (2.5) 13. Reduction of waste (2.3) 14. Support for multi-vendor projects (1.8) 15. Outsourcing initiatives (1.3) 16. Reduction of technical complexity (0.8) Source: Dr Dobb’s January 2010 State of the IT Union Survey 19
- 20. Legal Stuff © Copyright IBM Corporation 2012. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, the on-demand business logo, Rational, the Rational logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others. 20