Do you need SOA management?

BANGALORE, INDIA: SOA Management is a topic I often talk about as I travel throughout Asia.  The response I get is often mixed.  I believe the reason being a lack of understanding of why and how.  Regardless of how far along your organization is with SOA, SOA Management is something you need to pay attention to.  I will first discuss the reasons and then talk about what you should look out for.

Before I start, let me address the confusion around SOA Management and SOA Governance.  To me, SOA Management is part of SOA Governance. SOA Governance consists of processes, standards, and policies to govern SOA adoption. A complete SOA Governance solution involves registry/repository, change management, service control, quality of service, security, etc. 

I will only discuss SOA Management, which to most vendors addresses service control, security, and visibility for business processes and exception handling.

First, let us take a look at the conventional wisdom.  Organizations often do not think they need SOA management because there is not enough of a business driver for it.  Or as the saying goes: “Why do I need SOA Management when my SOA infrastructure is not yet in place?” Is this kind of thinking correct?  You can decide for yourself at the end of this article.

If you read my SOA Project article earlier, you will remember I mentioned that SOA adoption is a journey.  It will take time for your organization to reach certain level of SOA maturity.  At some point in your SOA adoption, SOA management will come into the picture.  There are a couple of reasons for this:

1. Your SOA infrastructure turns monolithic applications and silo business functions into distributed services.  The increased flexibility and agility adds complexity to security and access control.  This demands new thinking in management tools.

2. Even with a basic SOA environment, your organization will need to have visibility into your SOA infrastructure.  The visibility requirements include business processes, service usage, performance bottlenecks, etc.  As your environment becomes more distributed, you lose visibility with existing management tools.  So as you SOA enable your business, you need to SOA enable your management environment beyond conventional system management.

Right time for SOA?

So, when is the right time to think about SOA management?  And should that point in time be earlier or later in your SOA deployment cycle?  The answer depends on several factors:

1. Access control and security are critical issues addressed by SOA management.  Because of this, SOA Management should be an integral part of your SOA infrastructure and not something that gets bolted on later.  Realistically, you need to think about security and control early in your SOA project.

2. With proper planning, SOA management reduces the cost and development time for your SOA project.  It is commonly understood that changes/fixes in the early part of a project lifecycle has less impact than changes/fixes that happen later. In other words, the later you decide to change things addressed by SOA management, the bigger the impact to design decisions you made earlier.  This can prove to be very costly.

3. It is often the case that organizations only think about management when something goes wrong.  It is hard to quantify the “cost” of disruption caused by rogue services or security breach in your infrastructure.  Instead of looking for fire fighting measures, you should leverage SOA management tools as a way to proactively control and monitor your business.

4. Business Process Management (BPM) is one of the big themes for organizations in Asia.  SOA adoption, although early, is another.  SOA management tools can make a good complementary solution to BPM.  Let me explain.

When dealing with BPM, most organizations think about how to leverage BPM tools to model and control their business processes.  However, I submit the following questions for you to consider:

1. Can all your business processes be defined with a BPM solution?

2. If not, what do you do with these business processes that are not defined by the BPM tool?

3. Are the business processes working the way they are designed?

In other words, how do you find out if your business process is causing some unintended consequences?

I would say most organizations will not be able to model all business processes with a BPM solution. If your business has been around for a while, you probably have more undefined business processes than you think.  Some SOA Management tools, with auto discovery capabilities, can fill the gap. These tools can ‘see’ what is happening within your infrastructure and show it to you.  So instead of modeling the business process the way you think should work, let your SOA Management tool tell you what is actually happening. This not only benefits IT to pinpoint usage and bottlenecks, it also benefit analysts to see the business process as they are happening in real time.

By now, I discussed the reasons for SOA management.  If you are convinced that SOA management is something you need, here are a few things to look out for when picking your solution:

Things to keep in mind

1. Performance.  All management and monitor tools introduce some overhead.  You want to make sure your system performance does not suffer too much as a result.

2. Standards support.  Your business runs on heterogeneous applications, services, and standards.  Your management solution should too.  If you need to change your infrastructure investment to conform to SOA Management, you are probably looking at the wrong solution.

3. Cross functional support.  Your SOA infrastructure spans multiple functions and applications.  So will your SOA Management solution.  Make sure your solution can satisfy the needs of the IT organization, as well as the business analysts and security officers.

Like any other assets in your corporate infrastructure, if you know why and how to leverage your SOA Management solution, you will gain a clear competitive advantage.  Do you need SOA Management?  The decision is yours.

The author is Technical Services Director, Progress Software.