Agile and SOA Comparing the Two

Sally Elatta & Kyle Gabhart

1

Comparing and Contrasting Agile and SOA

Kyle Gabhart [email protected] • Subject matter expert in the area of SOA and Enterprise

Architecture.

• Popular speaker recognized for his enthusiasm and dynamic analysis of emerging technologies.

• Authored several articles and a popular book SOA: A Field Guide for Executives

• Director of Emerging Technologies for Web Age Solutions

Sally Elatta [email protected]

• Agile /Process Improvement Coach, Architect, Trainer

• Passionate about process improvement and building high performing teams.

• Coached and trained many small and large organizations on Agile Adoption.

• Certified ScrumMaster, Scrum Practitioner, IBM, Sun, and Microsoft Certifications.

Copyright(c) Sally Elatta 2009 2

• Comparing SOA to Agile – Apples and Oranges?

• The Agile Story

• The SOA Story

• How Do They Relate?

• The Challenges/Misconceptions with Both

• Bringing more Agility to SOA Projects

• Bringing better Architecture to Agile Projects

• Conclusion


• Agile is a Software Development & Execution methodology that aims to improve how software projects are executed. It provides simple yet effective project management and engineering best practices.

Iterative Development Collaboration Visibility

Inspect & Adapt Test Driven Development Measurement

• SOA is an Architectural Style that aims to build software services that are technology agnostic, business focused, reusable and that offer business process flexibility.

Services Processes Business and IT Alignment

Business Process Orchestration GovernanceIntegration


The manifesto’s shared value statement:“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals & interactions Over Processes & Tools

Working Software Over Comprehensive Documentation

Customer Collaboration Over Contract Negotiation

Responding to Change Over Following a Plan

“That is, while there is value in the items on the right, we value the items on the left more.”


6Copyright(c) Sally Elatta 2009

Product Backlog

Co-Development

Business / IT as One Team

Measurement!

Cross Functional Team

7Copyright(c) Sally Elatta 2009

• Traditional Architecture ..

8

DataWarehouse

LegacyMainframes

Web Servers

ApplicationServers

ApplicationServers

Workstation

ReportServer

DataMarts

DataMarts

Data

Data

Data

Copyright © Sun Microsystems

Order Services Customer Services

Product Services• PlaceOrder

• GetOrderStatus

• CalcOrderTotal

• GetOrderDetails

• GetCustomerInfo

• AddNewCustomer

• UpdateCustomerInfo

• GetAllCustomers

• GetProductCatalog

• GetProductDetail

• AddNewProduct

• CheckInventoryLevel

Architecture Goal

11

LegacyMainframes

Web Servers

ReportServer

EnterpriseInteroperability

Hub(Service Bus)

EnterpriseInteroperability

Hub(Service Bus)Workstation Application

ServersApplication

ServersData

Data

Data

DataMarts

DataMarts

DataWarehouse

Exposed Service

Exposed Service

Exposed Service

Exposed Service

Exposed Service

Copyright © Sun Microsystems



SOA Agile

Align with the Business Needs

Facilitated through layered services and service orchestration

Empowered Product Owner, Team works on highest priority user stories, not ‘Done’ until user acceptance

Provide Flexibility and Adaptation

Through loosely coupled service interfaces and policy-driven business rules

New stories are welcome (following set rules), retrospective allows process inspection and adaption

Produce quick ROI

By reducing dependence upon expensive middleware licensing and also through re-configuring solutions

Customer views working software quickly, customer may deploy small features that are valuable

Respond to Change

Re-deploying services, re-configuring business processes, or changing policies

Reviewing the plan each iteration, story reprioritization based on business needs

• SOA projects tend to suffer from BDUF (Big Design Upfront).

• Usually implemented top down with a divide and conquer approach.

• Long time before any immediate ROI is realized.• SOA assumes services will be designed correctly

the first time and does not deal well with iterative changes.

• Communication done extensively via heavy documentation.


• Challenge: SOA projects tend to suffer from BDUF (Big Design Upfront).– Perform high level enterprise framework design

upfront then dive into detail design iteratively. • Challenge: Usually implemented top down with a

divide and conquer approach.– Create collaborative cross functional teams with

heavy business engagement.• Challenge: Long time before any immediate ROI

is realized.– Direct customer involvement combined with early

delivery of service functionality within each iteration produces value more rapidly.

15Copyright(c) Web Age Solutions

• Challenge: SOA assumes services will be designed correctly the first time and does not deal well with iterative changes. – Proper service interface design, service contract

management, thorough service version strategies, and effective use of intermediaries can produce very robust and adaptable service interfaces.

• Challenge: Communication done exclusively via heavy documentation.– Well-designed service-oriented enterprises heavily

leverage metadata, which is automatically generated and maintained by tools and through proper governance and represents a “self-documenting” approach

16Copyright(c) Web Age Solutions

• Thought to be a fit for small projects.

• Lacks proper upfront architecture.

• Very little formal documentation.

• Lacks proper upfront planning.

• Is not prescriptive, does not lay out all steps and deliverables needed upfront.


• Big Design and Architecture upfront is not good from an Agile perspective, but so is NO upfront architecture and design!

• Agile projects need to do High Level Architecture envisioning upfront during Iteration 0.

• Detailed architecture and service implementation can be done iteratively.

• An Agile Architect/team lead must coach the team through design meetings each iteration.

• Code review sessions should be integrated in each iteration. Pair/Collaborative Programming.

• Iteration 0 training on standards for coding, design packaging, deployment, naming ..etc.


• During iteration 0, the Agile Architect should attempt to identify high risks and create Proof of Concept stories that mitigate them.

• Do collaborative design instead of ivory tower architectures. You still have an architecture owner for final decisions.

• Use lots of understandable models and diagrams. Communicate them visibility.

• Requirements and business value should drive your architecture not the drive to use specific technologies and tools.

• Do not ‘over architect’ and over use ‘patterns’.


Business Process

Modeling

Service Identification &

Specification

Service Implementation

Testing, Refactoring

Final Testing

Service Deployment


Agile Training & Coaching• Executive and Business Overview of Agile/Lean• Real World Agile and Scrum team training + Project Jump Start• Agile Engineering Practices• Advanced Agile Topics • Effective/Agile Requirements Gathering• Servant Leadership• … More!

• www.WebAgeSolutions.com – 1 877-517-6540

• www.AgileTransformation.com – 1 402-212-3211


• Sally’s Agile Adoption Article: http://tinyurl.com/6h5mam

• Towards an Agile Architecture:http://tinyurl.com/c3f3uz

• Kyle’s SOA Guide for Executive Book: http://tinyurl.com/ykj3zjc

• Kyle’s Articles: http://kylegabhart.sys-con.com/

23

Technology

Agile and SOA Comparing the Two