02.05.07

The “G” Word

Posted in Application Development, SOA & Web Services, IT Governance at 2:21 am by Tony Baer

Mention the term “governance” these days, and you’ll probably draw lots of nervous stares because the term means many things to so many people. Narrow that to SOA governance, and those expressions often turn blank.

The challenge is that governance itself is a loaded term, and when it comes to SOA, the definition of what to govern is at this point somewhat fluid.

Looking the term itself, in an age of SOX, governance not only implies fiscal responsibility, but legal as well. And while SOX isn’t specifically aimed at IT directly, as steward of corporate data, IT is on the firing line when it comes to ensuring that the CEO stays out of jail. One CIO of a major consumer goods company once related to us that SOX efforts tied up her staff for the equivalent of 90 days over the previous year.

And when you compare the objectives of SOX and SOA, you’ll inevitably confront a disconnect. While SOX is intended to prevent bad things from happening to data, if SOA is implemented properly, it provides new ways of exposing data.

Now let’s ratchet up the equation. With traditional software development, once you got past the requirements stage, the business typically threw most responsibility for the application over the wall to IT. By contrast, the SOA lifecycle can involve multiple masters through the life cycle, because new or reused services can be composed and shared on an ongoing basis. In most organizations, responsibilities for creating and maintaining a service over its life cycle have yet to be fully defined.

Consequently, if you’re going to formally govern SOA, that implies that there is some formal IT governance exercised as well to govern the rules of engagement, and set the context for how IT contracts with the business to expose and manage services from creation to deployment, modification, reuse, and retirement. And, given that reuse relies on a robust architecture (without one, you’d be hard-pressed to repurpose services if their semantics or technical designs are incompatible), that implies that the organization should have a somewhat codified software development lifecycle as well. And as we’ve maintained previously, the enforcement of service contracts specifying service level agreements means that there is an infrastructure management aspect as well.

Not surprisingly, when we convened a panel of experts on SOA governance at the Open Group’s Enterprise Architecture Practitioners conference last week, responses to the question of what SOA governance entails were all over the map. We’ll drill down more into that discussion in coming weeks.

But given that the goals of SOA are hardly modest, it’s no wonder that we’re still dancing around the “G” word.

Permalink