The concern about SOA governance has ratcheted up as enterprises are aggressively looking for ways to get more value out of their existing services and resources (which is a perennial promise of IT solutions). In perusing the increasing commentary on the topic, it seems to me that SOA governance – what it is, its goals, its success requirements, its solution requirements, etc – is highly dependent on the perspective of the people involved. Whenever a bunch of different perspectives together under one banner name, you either get a cacophony or the ability to pull off movie-worthy plans (ala The Italian Job or Ocean’s Eleven). Which is it going to be for SOA governance?
Let’s take a look at some of these perspectives. Enterprise strategists, for example, think about SOA governance in corporate execution terms. They have spent time translating strategic business goals such as lowering time-to-market costs, reducing compliance risks or improving service quality to cost ratios into enterprise SOA requirements. However, for that enterprise architecture to succeed, strategists must also nurture its adoption by the entire enterprise. For them, governance involves tracking the progress of the enterprise as it builds SOA capabilities over time and as it matures its use of those capabilities to provide competitive advantage.
Additionally, they are concerned with structuring policies and processes that clarify SOA-related decision making processes and responsibilities, such as: what decisions must be made and when should they be made; what information is needed to make those decisions and where does it come from, who should make those decisions and how do they coordinate with other stakeholders, how decisions implemented, automated, reviewed and revised as business conditions change. From this perspective, SOA governance solutions often involve corporate policy and procedure automation, performance indicator tracking, and managing enterprise roadmaps.
Most IT managers have a difference perspective. They tend to think about SOA governance in application lifecycle terms – design/architecture, develop/assemble, testing/deployment, runtime operations/policy enforcement. The main governance issues tend to be around coordinating these lifecycle activities between the different IT groups, each with their own processes and highly specific solutions. In spite of internal efforts to consolidate IT suppliers, it will be extremely difficult to uproot and replace existing IT solutions that are effective and delivering value for a particular group. From this perspective SOA governance solutions should involve managing and/or federating service meta-data, technical policies and requirements across the preferred tools/solutions each of these groups needs.
Business unit managers often talk about SOA governance in financial and resource management terms. Those that are producing services are wondering: “How do I benefit if my service becomes extremely popular? I’ll have to dedicate more infrastructure and people to supporting the performance and coordinating upgrades with all the consumers. I’m not budgeted to support other BUs.” On the flipside, those that are consuming these services are thinking: “I’m creating new value for my BU from services that we already have, so why should I have to share the top-line benefits?” Basically, SOA can up-end decades-old thinking about departmental boundaries and budget allocation, since services developed and maintained by one department can be reused by others. From their perspective, SOA governance solutions should focus on coordinating ownership, performance responsibilities, funding and internal charge-backs for shared resources.
As you can see, each perspective on governance is different, but related to each other, and potentially require significant effort to achieve (and I haven’t even touched issues such as compliance, security, data confidentiality, technology standards, etc.). Getting every SOA governance perspective on the same page is no small feat for large enterprises. Yet the payoff in terms of enterprise cost effectiveness and agility can be enormous when governance mechanisms are implemented in a coordinated way. So the question is, how can enterprises keep all of these efforts on track? Particularly at a time when employees are often expending as much effort trying to keep their jobs as they are doing their jobs.
Part of it depends on those tasked with designing and implementing their aspects of SOA governance. They must recognize their solutions, policies and procedures must be designed to slip into the daily tasks of people involved. Think email integration with CRM solutions as an example – in my experience, no one took the extra time to log all of their contact emails SAP, ACT! or even Salesforce.com – until there was Outlook integration which automated the logging process. The same thinking should apply to SOA governance. The most successful groups will add governance mechanisms without a lot of additional employee effort.
Part of it depends on each group recognizing the common bonds between these different perspectives. For example, there needs to be a common way of describing and discovering available shared services so that they can be tracked by those responsible for their lifecycle management, those concerned with business unit resource management, and those responsible for tracking corporate SOA capabilities and usage. This means keeping the meta-data about shared service function, composition, ownership, dependencies, etc. as simple and specific as possible to avoid confusion as different groups exploit that data in different ways.
Part of it is executive-level recognition that all these aspects of SOA governance are not luxury items. Enterprise executives must buy-into and clearly communicate why and how they expect effective governance to be a key aspect of navigating treacherous economic waters. With demonstrable executive support, SOA governance – in all its forms – becomes a competitive advantage.
