What Makes a Good SOA Project?

I was recently approached by Project Managers who asked several questions about SOA.
This got me thinking and I decided to respond to their questions by sharing an article written in July 2008 by a colleague of mine (Technical Services Director from Progress Software) which may help.
The original article is available here.
Have you ever heard of this question, or something similar: “What is a typical or good SOA project”?

Let us examine the whole idea of and confusion around SOA projects in more detail.

First, let us consider what SOA is.
SOA is a conceptual architecture. It is not a product. For that reason, SOA is often misunderstood because it is not something that you can touch and click.

Also, every vendor’s SOA products and implementations are different. So no two vendors can agree on what is the best SOA implementation.

As if this is not complex enough, different vendors will stress certain features and functionalities to their advantage. Some stress the usability advantage. Other talks about a complete product stack while others discuss standards support, performance, or continuous availability as key advantages.

No wonder to the end user, SOA can seem like the latest 3 letter acronym that vendors are using to make money.

However, the reality is not that grim.

There have been plenty of SOA success stories, especially in North America and Europe, from every vendor. The difference between these regions and Asia is that SOA adoption occurred earlier and therefore organizations have gone through the learning phase of utilizing SOA and are now starting to see the SOA initiative paying off.

The other difference is the IT infrastructure build out in these regions have occurred much earlier so organizations can focus much more on SOA than on both infrastructure and SOA.

Also, SOA has clearly replaced EAI as the technology of choice. You can tell by looking at all of the traditional EAI vendors. They all have a SOA story and no one is talking about EAI anymore.

Asian organizations, which are behind in SOA adoption, should look past the confusion and leverage SOA to their advantage.

Organizations that are new to SOA can learn from the mistakes of the early adopters by focusing on the following:

1. Adopt SOA soon if you have not already. 

Despite the confusion, SOA offers many advantages like service reusability and service abstraction. In fact, SOA closely resemble what happens in real life. For example, when you use a service like stock trading, whether you call a broker or do it online, you are not aware of the complexity that goes on behind the scenes, nor should you have to. That is what SOA is about! At every step of the way, what the service does to achieve its objective is hidden from the service user. It translate to a much more flexible and agile infrastructure, which means you can add services or change your business process much faster to suit your business needs (i.e. business agility). Agility is a powerful business advantage.

2. Find the vendor that matches your needs. 

Every platform has its strong selling points. The question is not which vendor has the best products. Rather, it is which vendor has the right products for you. For example, if your enterprise is highly distributed or your business needs to be available 24×7, then a highly scalable, distributed, and available product is what you need. Having a sexy GUI may not be the most critical thing.

3. Most importantly, focus on the business objectives, not the technology.

The mistake I see organizations make is deciding on an ambitious SOA project or to SOA enable everything when the infrastructure is being revamped.

Many times the SOA project is part of a bigger infrastructure project so people are dealing with a lot of moving parts at the same time. When you have that many moving parts, it is even more important to focus on the business objectives instead of the technology: objectives such as business integration, factory automation, CRM, straight through processing, etc. There are many reasons for this.

Doing SOA for the sake of having the latest technology will get you no where fast. If you cannot show results, the best technology will get shelved eventually.

With every technology or platform, there is a learning curve for the organization. While it is the right thing to have a clear picture of the ultimate goal, you need to start taking small steps to get over the initial learning curve.

It takes a journey to reach certain level of SOA maturity. It is difficult to go from no SOA to highly optimized SOA infrastructure in one step. Organizations need to take manageable steps to reach such maturity.

Organizations that have tried SOA but have failed should ask a few questions:

  1. Is the project too ambitious?
  2. Is there a clear business driver? Is there management buy-in?
  3. Can the benefits be shown easily?
  4. Did I pick the right platform for my business?
  5. Answering these questions can help you find out where the problem is and regroup for the next SOA initiative.

So, this goes back to my original question and the answer is:

  • A good SOA project is a project that has a proper focus and clearly defined, achievable goals.
  • Your objective is integration, factory automation, BPM, etc. SOA is just the means to achieve these objectives.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s