Does SOA make eXtreme Programming (XP) obsolete?

One of the promises of SOA and SOBA is that applications will be less complex, and therefore can be developed more quickly.  This complexity is reduced by having strict rules about how SOBA apps will leverage and reuse services.  In essesence, SOA takes an architectural approach to the problem of apps that take a long time to create, deploy, and modify. 

Interestingly enough, Agile Project Management methods (like Scrum, XP, and others) solve a very similar business problem in an entirely different way.  Instead of breaking up the complexity of the application in order to speed up delivery, they address the process by which that large and complex application is created using methods that focus on embracing scope change (while controlling it), improving dev team communications (while reducing the time spent on it), and prioritizing the feature set. 

Clearly, these two approaches are not tied to each other for success.  An XP project can (quickly) deliver a stovepipe app that is difficult to maintain.  A SOBA can be (quickly) developed using a heavy process like RUP.  However, both SOA and Agile SDLC methods use the same problem definition to justify their existence, and both purport that each, in its own right, is sufficient to solve the problem.

Clearly, if one problem spawns two different solutions, you have to ultimately ask the question: are both solutions necessary? 

In my opinion, SOA does nothing to address the fundamental problems caused by using a bad SDLC process.  Agile software development processes go a long way towards making life livable for the people who write code for a living.  On the other hand, Agile development processes do nothing to address the fundamental problems caused by system definitions that are too complex, refuse to consider reuse, and will ultimately cost a fortune to maintain.

So, in a way, both are needed.  On the other hand, I think we need to frame the problem a bit differently so that there are clearly two different problems being solved.  That way, when SOA solves one, and agile methods solve the other, both can be measured independently of one another.

My suggestion on how to reframe the problem statements to account for both---

Agile methods solve the problem of software development processes that produce frustration, rework, long hours, and missed expectations.  These are very tactical needs tied directly to the act of developing software.

SOA solves the problem of systems that embody multiple business capabilities in a non-reusable manner, thus forcing developers to re-invent the wheel every time a new application is created.  These are architectural needs tied to the business' need to deliver consistent solutions in a rapid manner.

Comments

• Anonymous
  January 04, 2006
  SOA makes all programming obsolete.
  
  ;)
• Anonymous
  January 05, 2006
  The comment has been removed
• Anonymous
  January 06, 2006
  Hi Thomas,
  
  If you go back and read the post, you can see that I am not pretending that XP and SOA are not different kinds of things. I am saying that they are largely justified, to executives, using the same words. My suggestion is to fine-tune the justification for both so that implementing one is NOT seen as a reason to avoid the other.
  
  --- Nick
  Enterprise Architect
  Certified ScrumMaster
  
  
• Anonymous
  January 06, 2006
  I did read your post. My reply explains how I read it. And I didn't see it the way you explain it now. What I saw was two unrelated things compared.
  
  Perhaps I am the one who needs some sleep. I know I need it:)