Joe McKendrick expands on the recent Gartner report, including Gartner's "9 ways to measure SOA success":
- Improved efficiency, particularly with respect to business processes execution
- Lower process administrative costs
- Higher visibility on existing/running business processes
- Reduced number of manual, paper-based steps
- Better service-level effectiveness
- Quicker implementation of processes
- Quicker time to market
- Shorter (overall) project cycles
- Overall reduction in the total cost of application development and maintenance
[ Keep up on developments in SOA with InfoWorld's Technology: Architecture newsletter. ]
Pretty basic, if you ask me -- not to take anything away from Gartner. 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.
- The ability to alter schemas without affecting services and/or processes. In essence, 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.
- 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 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.
- 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.
- The ability to expose processes and services from inside of the enterprise. In short, going the other direction.
If these measurements apply, you can call it SOA. Just a few more to consider.