BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ
News Articles Presentations Podcasts Guides

Topics

Choose your language

QCon New York

Find real-world practical inspiration from the world’s most innovative software leaders. Attend in-person.
QCon San Francisco

Learn what's next in software from world-class leaders pushing the boundaries. Attend in-person or get video-only pass to recordings.
The Software Architects' Newsletter

Your monthly guide to all the topics, technologies and techniques that every professional needs to know about. Subscribe for free.

InfoQ Homepage News InfoQ Article: Agile - The SOA Hangover Cure

QCon San Francisco (Oct 2-6): Learn what's next from software leaders pushing the boundaries.

InfoQ Article: Agile - The SOA Hangover Cure

Bookmarks

Jul 31, 2006 2 min read

Write for InfoQ

Join a community of experts. Increase your visibility.
Grow your career.Learn more

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

Rate this Article

Adoption
Style

This content is in the Enterprise Architecture topic

Related Topics:

Hello stranger!

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

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Time to consider infrastructure and standards

    by Ozawa Hitoshi,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

    Back to top
  • RUP versus Agile for SOA Methodology

    by Eric Roch,

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

    Back to top
  • Re: RUP versus Agile for SOA Methodology

    by Deborah (Hartmann) Preuss,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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 :-)

    Back to top
  • Re: RUP versus Agile for SOA Methodology

    by Eric Roch,

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

    Back to top
  • Re: Time to consider infrastructure and standards

    by Ozawa Hitoshi,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

    Back to top
  • Re: Time to consider infrastructure and standards

    by Eric Roch,

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

    Back to top
  • Re: Time to consider infrastructure and standards

    by Ozawa Hitoshi,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

    Back to top

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT