20
1 © 2012 IBM Corporation 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 What is Enterprise Architecture? Enterprise Architecture Success Factors Agile vs. Enterprise Architecture Agile and Enterprise Architecture Parting Thoughts

Agile Enterprise Architecture? Oxymoron or Savior?

Embed Size (px)

DESCRIPTION

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.

Citation preview

Page 1: Agile Enterprise Architecture? Oxymoron or Savior?

1

© 2012 IBM Corporation

Agile Enterprise Architecture:Oxymoron or Savior?

Scott W. AmblerChief Methodologist for Agile and Lean, IBM Rationalwww.ibm.com/developerworks/blogs/page/amblertwitter.com/scottwambler

What is Enterprise Architecture?Enterprise Architecture Success Factors

Agile vs. Enterprise Architecture

Agile and Enterprise Architecture

Parting Thoughts

Page 2: Agile Enterprise Architecture? Oxymoron or Savior?

2

EA as a Process

The process oftranslating business vision and strategy into

effective enterprise changeby

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)

Page 3: Agile Enterprise Architecture? Oxymoron or Savior?

3

What do Enterprise Architects Produce?

Source: Dr Dobb’s January 2010 State of the IT Union Survey

29%

33%

38%

44%

55%

64%

65%

67%

White papers

"To be" models

"As is" models

Reference architectures

Development guidelines

Architecture principles

System inventory

Business goals

9%10%

34%

30%

17%

Do you have an EA program?

Source: Dr Dobb’s January 2010 State of the IT Union Survey

Yes

Yes, and expanding

No

No, but I’ve experienced EA in other organizations

No, but we’re thinking about starting one

Page 4: Agile Enterprise Architecture? Oxymoron or Savior?

4

Resources = Complexity Agility Collaboration * Automation*Resources = Complexity Agility Collaboration * Automation* Add Automation

Individual

Productivity:5-25%

Timeframe is Weeks

Cost to Implement:<5%

Very predictable

Reduce Complexity

Organization

Productivity:2x – 10x

Timeframe is Years

Cost to Implement:25%-50%

Much culture change

ImproveCollaboration

IncreaseAgility

TeamProject

Productivity:15-35%

Timeframe is Months

Cost to Implement:5%-10%Predictable

Productivity:25-100%

Timeframe is Quarters

Cost to Implement:10%-35%

Some culture change

Economic Impacts

Why Should You Care?

What is Enterprise Architecture?

Enterprise Architecture Success FactorsAgile vs. Enterprise Architecture

Agile and Enterprise Architecture

Parting Thoughts

Page 5: Agile Enterprise Architecture? Oxymoron or Savior?

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 th e business

#5 Flexible enterprise architects

Source: Dr Dobb’s January 2010 State of the IT Union Survey

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

Page 6: Agile Enterprise Architecture? Oxymoron or Savior?

6

Source: Dr Dobb’s January 2010 State of the IT Union Survey

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

Page 7: Agile Enterprise Architecture? Oxymoron or Savior?

7

Source: Dr Dobb’s January 2010 State of the IT Union Survey

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 flexi ble

#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

Page 8: Agile Enterprise Architecture? Oxymoron or Savior?

8

We need to look at the big picture

What is Enterprise Architecture?

Enterprise Architecture Success Factors

Agile vs. Enterprise ArchitectureAgile and Enterprise Architecture

Parting Thoughts

Page 9: Agile Enterprise Architecture? Oxymoron or Savior?

9

Agilists Enterprise Architects

“versus”

Dueling Surveys

Ambysoft February 2012Agile Mini SurveyEA Mini Survey

70% of their firms have agile projects underway

49% of their firms have an EA

program

Page 10: Agile Enterprise Architecture? Oxymoron or Savior?

10

34% said their agile teams work with them well

15% say their EA teams work with

them well

44% thought that their agile teams addressed architecture well

18% think that their EA teams

work in an agile manner

Page 11: Agile Enterprise Architecture? Oxymoron or Savior?

11

47% believe their agile teams view EA positively

33% believe their EA teams

view agile positively

We need to build bridges

Page 12: Agile Enterprise Architecture? Oxymoron or Savior?

12

What is Enterprise Architecture?

Enterprise Architecture Success Factors

Agile vs. Enterprise Architecture

Agile and Enterprise ArchitectureParting Thoughts

Focusing on construction is a great start…

Page 13: Agile Enterprise Architecture? Oxymoron or Savior?

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

Page 14: Agile Enterprise Architecture? Oxymoron or Savior?

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

Page 15: Agile Enterprise Architecture? Oxymoron or Savior?

15

Sometimesthe situation isn’t always

so simple…

Domain Complexity

Straight-forward

Intricate,emerging

Compliance requirement

Low risk Critical,audited

Team size

Under 10developers

1000’s ofdevelopers

Co-located

Geographical distribution

Global

Enterprise discipline

Projectfocus

Enterprisefocus

Technical complexity

HomogenousHeterogeneous,

legacy

Organization distribution(outsourcing, partnerships)

Collaborative Contractual

Disciplined Agile Delivery (DAD):The Foundation for Agility@Scale

Disciplined Agile

Delivery

Flexible Rigid

Organizational complexity

Page 16: Agile Enterprise Architecture? Oxymoron or Savior?

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

Page 17: Agile Enterprise Architecture? Oxymoron or Savior?

17

© 2012 IBM Corporation

Backup Slides

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

Page 18: Agile Enterprise Architecture? Oxymoron or Savior?

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

Page 19: Agile Enterprise Architecture? Oxymoron or Savior?

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

Page 20: Agile Enterprise Architecture? Oxymoron or Savior?

20

Legal Stuff

© Copyright IBM Corporation 2012. All rights reserv ed.

� 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 IBMproducts 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.