Agile Enterprise Architecture? Oxymoron or Savior?

3,387 views

Published on

Agile software delivery strategies have taken organizations by storm, and those very same organizations are now scaling agile strategies across the entire IT organization as well as on very complex projects. Agile strategies are even being applied on enterprise architecture teams and are proving to be successful in practice. This presentation overviews IBM s Agile Scaling Model (ASM) and how to take an agile approach to enterprise architecture. It also summarizes industry data exploring the effectiveness of agile strategies and of various enterprise architecture strategies.

Published in: Technology, Business
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,387
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
136
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Agile Enterprise Architecture? Oxymoron or Savior?

  1. 1. Agile Enterprise Architecture:Oxymoron or Savior?Scott W. AmblerChief Methodologist for Agile and Lean, IBM Rationalwww.ibm.com/developerworks/blogs/page/amblertwitter.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. 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 enterprises future state and enable its evolution Source: GartnerEA as an Artifact The organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the companys 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. 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 SurveyDo you have an EA program? No34% 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. 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. 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 SurveySuccess 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. 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 SurveyFailure 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. 7. Failure Factors: People Issues #2 Project teams didnt take advantage of the EA #4 Enterprise architects perceived as "ivory tower“ #8 Enterprise architects werent 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 SurveyFailure Factors: Process Issues #5 Development teams couldnt wait for enterprise architects Source: Dr Dobb’s January 2010 State of the IT Union Survey 7
  8. 8. We need to look at thebig picture What is Enterprise Architecture? Enterprise Architecture Success Factors Agile vs. Enterprise Architecture Agile and Enterprise Architecture Parting Thoughts 8
  9. 9. Dueling SurveysAgilists 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. 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. 11. 47% believe 33% believe their agile their EA teams teams view EA view agile positively positivelyWe need to build bridges 11
  12. 12. What is Enterprise Architecture? Enterprise Architecture Success Factors Agile vs. Enterprise Architecture Agile and Enterprise Architecture Parting ThoughtsFocusing on construction is a great start… 12
  13. 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. 14. Agile Architecture StrategiesLook beyond technologyInitial requirements envisioningInitial architecture envisioningProve the architecture with working codeArchitecture spikesThink about the future, but wait to actArchitects also codeArchitecture owners, not architectsTravel lightTake a multi-view approach What is Enterprise Architecture? Enterprise Architecture Success Factors Agile vs. Enterprise Architecture Agile and Enterprise Architecture Parting Thoughts 14
  15. 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. 16. A more disciplined approach to agile solution delivery will help scott_ambler [at] ca.ibm.com twitter.com/scottwamblerwww.ibm.com/developerworks/mydeveloperworks/blogs/ambler/ www.ibm.com/rational/agile/ www.jazz.net 16
  17. 17. Backup Slides © 2012 IBM CorporationSome 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. 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.comAgile 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. 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 respondentsFor existing Enterprise Architecture (EA) programs, what hasimproved? (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. 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

×