Wait. I thought S-O-A spelled "panacea."

T

  wo items hit my feed reader recently that served as a reminder that people still have serious misconceptions about what SOA offers.

The first was an article over at Linux.SYS-CON.com. Keven Smith and Lou Blick wrote a piece called "Avoid SOA Pitfalls!" They've got seven practical tips for designing and building an SOA within your enterprise. Their tips range from architecture suggestions to managing user expectations. What's important is that they make it clear that, if you don't follow good design and implementation methodologies, you will put your project at risk.

The bottom line? Calling a project "SOA" isn't a panacea for software success. Slapping a web service on top of an existing stove-pipe application won't make the project succeed, either. And, as they point out in tip number 7 (and as I've made clear many times), you need to think about scalability from the beginning.

At the end of the day, the users of your enterprise applications probably won't care that a SOA is in place. Users want functionality, and they don't want their applications to run at a snail's pace. As a result, your deployed systems will have to scale to meet the load required by the intended number of applications and end users. Enterprise architects will need to analyze the scalability requirements and start planning at design time, because the risks of not planning for scalability are huge - exposing a SOA to an organization that can't handle the load promises to ruin your entire project.

It's a point that I'll never stop hammering on, and I'm glad to see others making it as well. For more reading, see the article that Robert and I wrote for Dr. Dobb's last year.

The second item to hit my feed was from Glenn Cameron's dotnetSaaS blog--he summarizes a new report from Saugatuck Research (available for sale here). According to Glenn's summary, Saugatuck finds that SOA may not reach its full potential to transform businesses.

Why? They cite three key barriers: Upfront cost, resource sharing and allocation, and SOA Governance.

Resource sharing is the one that jumps out at me, because it's a key part of the benefits that grid computing can offer an SOA.

Grid addresses the scalability needs of an SOA by bringing the power of many machines to bear on your SOA computing needs (and providing a standard infrastructure for your developers to use). Furthermore, a good grid system addresses resource sharing as well. It will allow you to put policies in place that ensure that your most important processes get the compute power that they need. It will ensure fair sharing of resources as well.

Technorati tags: grid computing, soa