SOA: Is There a 'Best Way' to Build?

Loraine Lawson

Gartner is predicting big things for business process management this year. The research firm says spending on BPM systems will reach $1 billion this year in software revenues and more than double by 2011.

 

Why?

 

The primary reason is service-oriented architecture projects. Process management is a huge driver for SOA, and Gartner believes companies will route some SOA spending to business process management initiatives. Since BPM relies heavily on SOA, it's a sort of buy-one, get-one free coupon for the industry. Gartner isn't the only one noticing this trend. Forrester has also noted that the two are increasingly intertwined, going so far as to predict SOA and BPM are merging into one issue.

 

It's not a bad idea to let BPM drive SOA in the enterprise. Since BPM is driven from the top down, this approach offers a measure of buy-in from top executives and it allows better long-term planning than, say, an initiative to integrate old mainframes with SOA.

 

But as Mike Rosen points out, top-down and bottom-down SOA initiatives aren't the only ways to approach SOA and, really, neither is the best method. Rosen is the CTO of AZORA Technologies and a columnist for Business Process Trends. In this month's column, "BPM and SOA: BPM Project Perspectives," Rosen argues that the best approach is to start in the middle and move out.


 

It sounds awkward, but if you think about it, it makes sense. SOA can be used to achieve short-term results that reap real benefits, which is why so many SOA projects begin with the organization's programmers. But it can also provide long-term efficiencies and structure, which is what you get with a top-down approach. Either extreme tends to overlook the merits of the opposite approach. By starting in the middle and pushing out, you can accomplish both short- and long-term gains.

 

But what does this look like in practice? Rosen says the secret is SOA Reference Architecture, which provides "an overall taxonomy that defines the different types of services, along with service groupings and responsibilities that help frame the overall service roadmap."

 

Unfortunately, Rosen wont' explain how SOA Reference Architecture helps you do that until next month.

 

But his column reminded me of the old days of building Web sites, which were either created through an upper-level directive or by rogue coders who created division pages on a whim and stored them on company servers. The sites that began from the top-down usually had a consistent, polished design, main page and contact page, but very little information you couldn't find in a phone book. The pages created in the divisions held more information, but you could hardly find it among the various font sizes and colors, animated GIFs and random links.

 

The best sites, (in the '90s, at least), used a compromise plan -- the design template, technical specifications and guidelines about what could be published were decided at the high-level, but the divisions were allowed to plug in the content and provide updates.

 

Of course, SOA is more complicated and won't involve dancing hamsters, but the point is the same. Both the top and bottom levels need to work together, and that's going to mean meeting in the middle.



Add Comment      Leave a comment on this blog post

Post a comment

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

null
null

 

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.