How Do You Know If You’ve Reached Practical SOA Maturity?

I’d like to think that my company is fairly far along the SOA path, but we’ll be spending time this year looking to refine our SOA reference architecture and map our progress on a SOA maturity model.  Most of the maturity models out there have some sort of scale which ranges from “starting with basic services in pilot projects” and graduates to “enterprise services and process orchestration” all the way to “agile, event-driven environments.”  If you’re unfamiliar with concept, check out what Sonic has to say.

All that said, I was thinking about some of the lower-level, tangible ways that I could observe whether we were indeed becoming more advanced in our SOA journey.  So, I put together a short list of 10 criteria that would indicate to me that we were doing more than paying lip service to the architectural principles of SOA.  Let it be noted that I don’t think my company does many of these, but you can’t know what you’re shooting for if you don’t throw up a target.

1. Organizational agreement on software validation processes and procedures.  Working in an FDA-regulated environment means that many of our systems require vigorous software validation processes.  Now considering that the nirvana of an SOA environment is that business and system processes can be constructed using the farm of existing reusable services, how do you properly validate this new system?   That is, must you revalidate each of the reused services that make up the new system in order to validate the entire new system, or do the software validation processes take into account composite applications?  The thinking of some is that a key criteria for this is risk.  Assess the risk points of the services working together, and then focus the validation effort on only those areas called out in the risk analysis.  I tend to like this approach since it’s progressive enough that we aren’t clumsily and coarsely retesting existing services unnecessarily, and instead focusing on what the FDA cares about the most, risk.
2. SOA implementation is not platform-specific.   I don’t want our SOA infrastructure to built solely upon Microsoft technology.  I don’t want it solely built with Java technologies either.  The services that we expose should all be supportive of cross-platform standards (and data types) and be consumable by any of the (many) technology platforms we have in place.   I should be able to call, with no issue, any exposed service from either a Windows, Unix, Linux environment and/or Microsoft or Java client.  This touches on the next point.
3. Service testing criteria should be defined and rigorous.   We shouldn’t simply be unit testing our service with blinders on that limit our scope to our target system.  If the goal is to maintain enterprise services, then each service should be challenged with cross platform invocation, and be proven to work as part of a composite service or process.  It’d be great for us to have a short, but comprehensive checklist that any service, regardless of situation, is tested against.
4. Common set of enterprise objects is available.  We’ve done this with our SAP implementation, where many of the core SAP objects are represented via XSD schemas and it is assumed that if you receive data from SAP for these functional areas (e.g. employee data, vendor information), it will conform to the enterprise schema.  Now, it’s impractical that every existing system and data source will be evaluated and a complete set of enterprise objects will be defined.   That doesn’t make sense.  But, we would probably benefit by having a “customer” object that all our various system services would accommodate.   Once you’ve defined these objects, the next critical piece is publishing them for others to discover.
5. Service repository contains services AND metadata.  We use SOA Software for our service directory, but simply discovering and listing services isn’t enough.  We also need clear guidance around how to best *describe* the service.  What is the metadata description needed for someone to not only discover this service, but know if it fits their needs, and how to consume it?  The first step is to find and register the services, but maturity will only be reached once we’ve properly cataloged and described them.
6. Service lifecycle is well defined.  Specifically, what is the change management, release management, and service ownership story?  Does a single group *own* all the services, or is there distributed ownership and management?  When changes are needed, how do you ensure that the service is appropriately versioned, and that breaks to the contract do not cause issues for existing consumers?
7. Metrics are captured and actionable.  While SOA Software provides us the means to observe all sorts of details on service usage, it’s arguably even more important to define how to act upon this data.  Do you defined a BAM dashboard?  What happens if specified SLAs are failing?  What’s the policy here?
8. Service developers incorporate common service patterns.  I’ll specifically call out communication patterns.  Can our developers articulate why they would choose a request/response pattern, asynchronous one-way pattern, or publish/subscribe pattern, and know how or when to use callbacks?  Many services are well served by an asynchronous processing model, but I wonder how many developers are comfortable with that.  Also, how many of our services support MULTIPLE communication patterns?  In many cases, it makes lots of sense to support not only a request/response channel, but also a one-way channel.
9. Developers build services that can ACTUALLY be reused.  Some folks may say that reuse is critical to an SOA architecture, but plenty of others will say that reuse isn’t a requirement and can actually hamper, not help, your design.  However, developers should be considering reuse while modeling their services, even if that only means that they carefully evaluate the service contract and exposed operations.  Likewise, can the service you’re building be detached into smaller, more modular components?   Maybe the broader application-specific service you’re writing has no possibility of reuse, but potentially a smaller part of the operation does include a repeatable process.  Sufficiently considering enterprise reuse is often one of the hardest things to do on a project.  How can you guess what someone MIGHT do with your service months from now?   But, taking a small slice of time to debate both “who” and “how” your service might be reused may yield design decisions otherwise not considered.
10. New architects/developers can quickly understand our SOA.   Can we grab a new college-hire or a seasoned developer and have them build services that comply with our SOA vision?  If our SOA principles and design criteria aren’t clearly articulated, we will quickly find an excessive amount of deviations to our master plan.  We don’t need a 400 page manifesto, but it is important to call out our standards for envisioning, designing, testing, security, deploying, consuming and managing enterprise services if we’re truly committed to building a vibrant service-oriented infrastructure.

Thoughts?  Do you find that you or your company already do many of these?  Or do you think any of these criteria are unnecessary or incomplete?

Technorati Tags: SOA