The Gartner Group just listed "9 ways to measure SOA success.” Not to take anything away from Gartner, but theirs is a pretty basic list, if you ask me.  Indeed, these nine measurements are really about any successful architecture, using SOA approaches or not, which is fine. However, I have a few of my own that are more specific to SOA.

Here are Gartner's nine:

1. Improved efficiency, particularly with respect to business processes execution.

2. Lower process administrative costs.

3. Higher visibility on existing/running business processes.

4. Reduced number of manual, paper-based steps.

5. Better service-level effectiveness.

6. Quicker implementation of processes.

7. Quicker time to market.

8. Shorter (overall) project cycles.

9. Overall reduction in the total cost of application development and maintenance.

However, I have a few of my own that are more specific to SOA.

1. The ability to alter schemas without affecting services and/or processes. You've created an architecture that's able to accommodate changes to the underlying data structures without driving redevelopment of any services or processes that leverage that data structure.

2. The ability to alter services and/or processes, without altering schemas. The same concept as No. 1, but we're just going the other way. The issue here is that SOA architects often fail to consider agility in the context of data abstraction. In many instances, data is bound to services, processes, or both, and thus any changes to those services and/or processes drives changes to the schema, and the other way around. In order to get the full benefit of the architecture, you need to figure out how to abstract these changes in either direction.

3. The ability to create and alter core business processes using a configuration rather than a programming approach. The idea is to place volatility into a single domain, such as a process/orchestration layer or a composite (aka mashups), thus avoiding constant redevelopment and testing. This is key to your success, considering that we are going to change many business processes going forward, but typically should not change many services. Therefore, you want to make sure that any changes to business processes don’t drive waves of redevelopment. In essence, it’s a configuration solution, not a programming problem.

4. The ability to leverage processes and services from outside of the enterprise, such as from a cloud computing provider. We're clearly moving in this direction, and much of the motivation behind SOA is the ability to make this type of convergence easy. Architecture should consider that services are pervasive, and can come from within or outside of the enterprise. This frees up those who build business applications to be more creative and productive. Don’t be afraid of extending your architecture to the clouds.

5. The ability to expose processes and services from inside of the enterprise. In short, going the other direction as No. 4. Same benefit, just the other direction. If these measurements apply, you can call it SOA, at least in my world. At issue is that many are losing perspective when it comes to SOA. SOA is an architectural pattern that provides an additional benefit of agility, or the ability for the architecture to change as needed to support the business. Often, this is overlooked in favor of more easy to conceive and technology-oriented concepts. However, going down that road won’t even provide you with the core benefits you’ll need to justify doing a SOA. Trust me.