InfoQ Article: Agile - The SOA Hangover Cure

by Miko Matsumura on Jul 31, 2006 |

Carl Ververs digs in to the age old Information Technology problem on behalf of the SOA community: How do you start? With SOA, there's a dynamic tension between "intentional" architecture and "just get started" services. The idea of hurtling ahead without much architecture is dangerous and can lead to "spaghetti" SOA. Then again, overarchitecting is counter to the YAGNI (You Aint Gonna Need It) philosophy of Agile Programmers everywhere.

The full article is available by clicking here.

Carl digs in to this dynamic tension with an entertainingly written exclusive InfoQ article. Excerpts from the article below:

So I ask you: how can you design, plan and implement what you do not know? You can't. So you might as well design around just what is in front of you and plan for half of what you know to be invalid tomorrow.

You can't learn what it's like to make, own and interconnect services from a book, you have to DO it. Only when those messages start flowing and trigger events will you understand. Only when you invoke the same service from two entirely different pieces of code will you understand the power of what you have created.

Do you need to have your message headers standardized to do this? Do you have to have your governance set up? Do you need to have an SOA infrastructure up and running?

No, and you know it.

But just sending wild XML without schemas over JMS sounds so.., so... impulsive! Yes, and isn't it beautiful?

So, now that I have you convinced that there is an alternative way to approach SOA, let's look at how you can actually get true SOA off the ground, using Agile/XP practices.

First, select a team of 4, 6 or 8 developers. The more varied their skill set, the better. Reserve a room for half an hour at the beginning of every day. This will be your AgileSOA project room where you will discuss lessons learned, designs and practices and where you will plan your next steps. Get an easel with a flipchart, so you can carry your artifacts in and out at will.

Select a mildly complex process flow from your company's core business. To name some examples, try implementing a simple loan application. A basic stock trading system is a good candidate as well. Remember, you don't have to solve the entire business problem, just make your solution do something that appears useful to your business types.

Chart out the simplest path through the flow, initially leaving out all exceptions, errors and decision points (the so-called Happy Path). Now go and implement the first pieces, pairing developers with the largest difference in skills and experience. This may seem unexciting, but I challenge you to build that first consumer of MSMQ or JMS messages, get a few running and have a producer successfully send some XML data to them. (That means ALL of them, not just one)

So what if this first step is trivial and mundane? Did you write unit tests for the producer and consumer, so that you can verify that the data comes across intact? Did your pairs develop together, without walking back to their own desks? No? Thought so.

Read Agile: The SOA Hangover Cure

Related Editorial

Agile workshops and training

A Unified Mobile Architecture for the Modern Data Center

Agile Practices to Improve Project Management Organization (PMO) Effectiveness

Enterprise-class API Patterns for Cloud & Mobile

Agile Maturity Model Applied to Building and Releasing Software

Related Sponsor

Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

Time to consider infrastructure and standards by Ozawa Hitoshi Posted

Re: Time to consider infrastructure and standards by John Harby Posted

Re: Time to consider infrastructure and standards by Ozawa Hitoshi Posted

Re: Time to consider infrastructure and standards by Eric Roch Posted

Re: Time to consider infrastructure and standards by Ozawa Hitoshi Posted

RUP versus Agile for SOA Methodology by Eric Roch Posted

Re: RUP versus Agile for SOA Methodology by Deborah Hartmann Posted

Re: RUP versus Agile for SOA Methodology by John Harby Posted

Re: RUP versus Agile for SOA Methodology by Eric Roch Posted

Time to consider infrastructure and standards by Ozawa Hitoshi

I basically agree with the steps to get SOA project started in an organization. I think the important point is in the following clause:

As your service population grows, the need for some infrastructure and standards will emerge. Now is the time to identify services and formats that are used by many SOA participants.

When is the "right" time to start identifying common services and formats and how should one go about it? Who should decide when it is the right time? Should one just consider the currently needed infrastructure and standards and keep adjusting them as the project gets bigger?

I think that properly handling this transition phase is the key to making a sucessful SOA project or making a large bowl of spaghetti.

Re: Time to consider infrastructure and standards by John Harby

IMHO, one should start identifying common services and formats upon inception. Of course this will be iterative since requirements will dictate services and the requirements may need to be flushed out. In any case, a process should be specified to continue identifying and refactoring common services in the future.

RUP versus Agile for SOA Methodology by Eric Roch

There's continued debate on the merits of the Rational Unified Process (RUP) vs. agile methods such as eXtreme Programming (XP) for SOA design. While it's possible to run SOA projects in an XP fashion, my concern that the lack of rigor can lead to an incomplete or inconsistent process...

blogs.ittoolbox.com/eai/business/archives/rup-v...

Re: RUP versus Agile for SOA Methodology by Deborah Hartmann

That's an interesting article, thanks Eric.

Just a reminder, though: not all teams use RUP in the same heavy-weight way. RUP is a methodology toolkit which includes recommendations for implementing various "flavours" of process, including "Agile RUP".

Just how Agile that flavour is, is another discussion :-)

Re: RUP versus Agile for SOA Methodology by John Harby

I'm not convinced that RUP is correctly designed for say an initial SOA implementation in a large corporation. RUP seems very project oriented whereas such an SOA effort is really like many projects rolled into one effort. However, I certainly can see how RUP can be modified to support such efforts and recognize how certain concepts such as CIM can be used in general.

Re: RUP versus Agile for SOA Methodology by Eric Roch

Good point. I agree that RUP is more project specific, but I was speaking in terms of project specific deliverables. I have used variations of IBM's SOMA and the OASIS SOA Blueprint for enterprise service discovery. RUP and UML is the next level down.

www.oasis-open.org/committees/download.php/1507...

www-128.ibm.com/developerworks/webservices/libr...

Re: Time to consider infrastructure and standards by Ozawa Hitoshi

From reading the article, I thought that it meant using
Agile to get a SOA project going and to switch over to
something like RUP when the SOA project gets some backing from the company - read as getting a budget.

In the beginning, I think it's difficult to get time and support from different groups to identify common services unless SOA is implemented in a top-bottom approach. If the organization is already committed to SOA and have large budget to implement it, I think I would favour to use something like RUP from the beginning and get as many people involved.

Re: Time to consider infrastructure and standards by Eric Roch

Where and how to get started with SOA is another interesting topic. I am working with quite a few clients and I have found that most start bottom up and then move to top down after some initial sucess. When moveing to top down, enterprise service discovery, I have not found that RUP is a good appoach. RUP and UML are very good a capturing project based deliverables that can be reused as services are reused - the deliverables support services reuse.

But enterprise service discovery is more functional and process decomposition with a good mix of IT strategy. What you want is a services blueprint (what the services catalog end state will be), a prioritized roadmap to get there and what the services architecture and infrastructure will look like over time to support the roadmap.

As I said in the previous comment I use variations of IBM's SOMA and the OASIS SOA Blueprint to accomplish this along with some IT strategy allignment techniques. I will write a longer post on this topic.

Here is another post on where to get started - this is an interesting topic.

blogs.ittoolbox.com/eai/business/archives/where...

Re: Time to consider infrastructure and standards by Ozawa Hitoshi

I agree with you that most actual projects involving new technologies such as SOA are done bottom up because there is too much risk involved.

Activities mentioned in SOMA is interesting as well as practices mentioned in the OASIS SOA blueprint. I think these may be used with a general project process framework such as Agile.