Extend SOA governance to all of IT? Why not?

Why is SOA governance separate from overall IT governance? HP's Kelly Emo takes up this question in a new post, observing that perhaps the governance principles and practices being preached for SOA can benefit the entire range of an organization's application portfolio.

As Kelly puts it:

IMO extending SOA governance more broadly to the concept of governance of the modern application lifecycle will be a powerful way for IT to combat the complexity that comes from the move from monolithic apps to modern compositions of shared services.  And composing rather than re-building is a key to lower costs of build and maintenance--which could be important right now in the dark days of reduced budgets.

The things we are learning from SOA governance implementations are teaching us a lot about application lifecycle management -- not only the ability to track and communicate the availability of IT assets, but also the automation being introduced, as well as the best practices entailed in involving the business end-user in the process of designing and deploying new and existing systems.

As Kelly also says, it's high time that the idea that monolithic applications have a "linear lifecycle" is put to rest. "Modern applications are compositions of modular and potentially shared services which, in and of themselves, have lifecycles with inherent interdependencies.  The application lifecycle is actually an overlapping set of interdependent lifecycles – the lifecycle of the service and the lifecycle of the composite application which depends on the service."

It's inevitable that most of our application portfolios will be service-oriented in some way anyway -- even if we're not calling oit "SOA." It never made sense to me why SOA should have one governance mechanism, while the rest of IT and the organization had something else.