Java Reference
In-Depth Information
This is considered an advanced stage for a SOA, and some organizations that are heavily in-
vested in such strategies and supporting tools have even termed their architectures POAs, or
process-oriented architectures.
The basic idea here is that there are a variety of reasons that organizations might want to adopt
SOA. And SOA doesn't happen overnight. So understanding why you want to invest in this
long-term architectural strategy in general terms can help you refine your general goals into
smaller, more workable, and more concrete goals.
Building on the principles of agile development methodologies such as Scrum, we can create
a roadmap that allows us to do a little work and deliver value to the business incrementally.
We generally don't use a waterfall method to develop our software, and likewise we shouldn't
create a roadmap that front-loads lots of research and development with no proposed pay-off
for a long time to come. Such a “big bang” approach is very dangerous in SOA.
NOTE
As support for the idea that SOA represents a real change not just in technology but in organizational
approach, it is useful to recall Conway's Law: “organizations which design systems…are constrained
to produce designs which are copies of the communication structures of these organizations.” You
can't do SOA without examining how your project teams and organizational attitudes need to change.
There are a few general steps that every SOA roadmap is likely to define. These steps can (and
should) be performed in an iterative fashion, as you reach each new milestone:
1. Starting a SOA, especially if you have not done much web services development before,
can be very difficult. The market is overwhelmed with hype and noise. Figuring out what
you need for your particular enterprise can be tricky, especially when you don't know
what you don't know about SOA. You therefore need to start with a research and planning
stage that will probably involve a lot of reading. Attend industry conferences and talks.
Read whitepapers. Engage vendors in conversations with a clear statement that you're in a
discovery stage and don't plan on buying anything just yet. If you have relationships with
analysts such as Gartner or Burton Group or Forrester, engage them. Figure out first what
you don't know. Remember that SOA is not just about getting an implementation of the
WS-* specifications. The business must be involved. And while you can start top-down,
and indeed you will need support up the organizational chain, your SOA will ultimately
be realized bottom-up.
2. Now that you know what you don't know, use this knowledge to create a set of flexible
checkpoints. To borrow from Six Sigma, this is a kind of measuring stage. Determine what
needs to be worked on. Establish a set of tools that you will need for the current iteration.
