Does SOA Need Another Governance Silo?

Turns out that the new year wouldn’t be complete without yet another SOA is dead flame war, touched off by Anne Thomas Mane’s provocative comments that stated, to the effect, that SOA is dead, long live services. As inveterate SOA blogger Joe McKendrick has noted, it’s a debate that’s come and gone over the years, and in its latest incarnation has drawn plenty of reaction, both defensive, and on target – that the problem is that practitioners get hung up on technology, not solutions. Or as Manes later clarified, it’s about tangibles like services, and solid practices like applying application portfolio management that deliver business value, not just technology for its own sake.

We could be glib and respond that Francisco Franco is still dead, but Mane’s clarification struck a chord. All too often in software development, we leap then look. We were reminded of that with an interesting announcement this week from SOA Software. Their contention is that there is a major gap at the front end of the SOA lifecycle, at least when it comes to vendor-supplied solutions. Specifically, it is over managing service portfolios – making investment decisions as to whether a service is worth developing, or worth continuing.

SOA Software contends that service repositories are suited for managing the design and development lifecycles of the service, while run-time management is suited for tracking consumption, policy compliance, service contract compliance, and quality of service monitoring. However, existing SOA governance tools omit the portfolio management function.

Well, there’s a gap when it comes to portfolio management of services, except that there isn’t: there is an established market and practice for project portfolio management (PPM), which applies financial portfolio analysis techniques to analyzing software development projects to help decision makers identify which projects should get greenlighted, and which existing efforts should have the plugs pulled.

The downside to PPM is that it’s damn complex, and mandates comprehensive data collection encompassing timesheet data, all data relating what’s paid to software vendors and consultants, and infrastructure consumption. We also have another beef, that in most IT organizations, new software development or implementation projects account for 10% of budgets or less. The bottom line is, PPM is complex, hard, and anyway, shouldn’t it also cover the 80 – 90% of the software budget that is devoted to maintenance?

But anyway, SOA Software contends that PPM is overkill for managing service portfolios. Their new offering, Service Portfolio Manager, is essentially a “lite” PPM tool that is applied specifically to services. Their tool factors in four basic artifacts: existing (as-is) business processes or application functionality; identifiers for candidate services such as “customer load qualifier;” ranking of business priorities; and metadata for services that are greenlighted for development and production.

We understand that SOA Software is attempting to be pragmatic about all this. They claim most of their clients have either not bothered with PPM, or have not been successful in implementing it because of its scope and overhead, and it’s better to manage even if it’s for a special case. And they see plenty of demand from their client base for a more manageable service-oriented PPM alternative.

But we have to wonder if it makes sense to erect yet another governance silo, or if SOA really merits a special case. The problem is that if we view SOA as a special case, now we wind up with yet another level of managerial silo and more process complexity. It also divorces SOA – or services if you prefer—supports the business. If SOA is a special case, then it must be an island of technology that has to be managed uniquely. In the long run, that will only increase management costs, and in the end reinforce the notion that SOA is a workaround to the bottlenecks of enterprise, application, or process integration, and a band-aid to poor or nonexistent enterprise architecture.

It also further isolates SOA or services from the software development lifecycle (SDLC), of which they should be an integral part. While services are not monolithic applications, are extensions or composites of applications and other artifacts such as feeds, they are still software. From a governance standpoint, the criteria for developing and publishing services should not be distinct from developing and implementing software.

And while we’re at it, we also believe that the run-time governance of SOA or services cannot be divorced from the physical aspects of running IT infrastructure. Service level management of SOA services is directly impacted by how effectively IT delivers business services, which is the discipline of IT Service Management (ITSM). When there is a problem with publishing a service, it should become an incident that is managed, not within its own SOA cocoon, but as an IT service event that might involve problems with software or infrastructure. In the long run, service repositories should be federated with CMDBs that track how different elements of IT infrastructure are configured.

In the short run, SOA Software’s Service Portfolio Manager is a pragmatic solution for early adopters who have drank the SOA Kool Aid and mainstreamed service implementation, but lack adequate governance when it comes to the SDLC (and enterprise architecture, by implication). In the long run, it should serve as a wakeup call to simplify PPM applying the 80/20 rule, making it more usable rather than spawning special case implementations.