SOA Governance

Depending on who you talk to, SOA is either the coming thing or a marketing ploy based on an acronym, some technology and little else. In one view, we have organisations running on shared business services, delivering business outcomes and supported by technology that can be insourced, outsourced or upgraded at will, as long as the service contract doesn’t change. In the other view, we have standards-based chaos, in which services are built “right” using all the latest acronym-ware—ESB, WS-this, WS-that, Web 2.0—but whether you get the right services, built right, is largely a matter of chance.

As usual, the truth is somewhere in the middle and where you are on the continuum depends on both your corporate and SOA maturity. The focus should be on building a service-oriented business and then using service-oriented technology, where appropriate, to support it. We are reminded of that other great experiment, the shared corporate database. Yes, in the days before Master Data Management, there really were companies that stored all their data in one place, logically, updated it in one place and made “quality assured” data, and its metadata, available everywhere it was needed. We now need MDM because programmers decided that shared databases were a bad idea because they slowed down coding: for a start, before you changed a field format or semantics you had to talk with its other users and apply change management and similar “overhead” processes! So, you meet people writing Web 2.0 who even suggest that giving everyone their own database is “good practice”—David Heinemeier Hansson, creator of Ruby on Rails, for example, talking to Tim Anderson: “people instead should have one database per application, and if you need to share a database or share data, expose that as services”. Many of the issues which killed the shared database for a time could kill shared services:

• Politics – a powerful manager can’t really “own” a shared service but may want to.
• People issues – changing for shared services needs communication and negotiation skills, an area IT is not noted for.
• Short termism – developing shared services for reuse needs an initial investment (in the case of databases, a DBA and a data analysis team; for services, perhaps a centre of competence and SOA architect). If you only measure project by project cost, you will never see the life cycle ROI gained as a whole project portfolio takes advantage of that initial investment.
• The silo mentality – “our project is the only one that really matters and sharing resources will slow us down”
• Rewarding short term technical exploits instead of the longterm delivery of effective business outcomes.

Now is the time to learn from the past and make sure that SOA doesn’t suffer from the same dysfunctional issues.

One company that seems to be helping companies with this is BEA (we’re sure there are others; or, at least, we hope there are). We’ve just come from a meeting with BEA in which technology was hardly mentioned, let alone BEA products, and the talk was all about governance, architecture, people issues and organisational structures.

We were talking with Danny Healy (EMEA Technical Director at BEA) and Phil Head (UK Practice Director at BEA). They told us that BEA’s consulting arm was now 40% architectural (as opposed to 60% technical), including many new hires. The new people are dealing with customers who say “I want to do SOA” (we’d be happier if such people put this somewhat differently; perhaps, “I want to achieve this business outcome and I think SOA is the way to do it”—but we suppose that that’s what the BEA consultants address first); and “I need to solve this business problem”. And, of course, there are still many who say “I’ve bought BEA” and still just need technical consultants.

Healy and Head made the point that all of the issues are, in fact, interrelated; and that you have to take a holistic approach to them—but that they don’t all have to be solved at the same time. Prioritisation is your friend.

Many of the issues, they say, can be lumped together under one heading: SOA Governance. But different companies will need different governance models, they add, because what you need will depend on:

• the internal characteristics of your particular organisation—the organisational and governance status quo; your corporate and SOA maturity levels (in essence are you a metrics-focussed organisation without a dysfunctional “blame culture”, and are you happy thinking in terms of services and contracts in connection with IT);
• geography and external organisational relationships (managing service levels from people not on site—or perhaps not even employed by you can be tricky);
• politics;
• the business environment; and so on.

If we ourselves had to pick on one killer issue, we’d pick corporate maturity; and Head and Healy say that evaluating this is often the first thing to do—even prior to engagement.

BEA suggests that a mature organisation will implement end-to-end SOA lifecycle governance—and that many companies that didn’t do this first time around are now revisiting the issue. SOA governance is a vital part of producing services with a service contract that people can trust and the underlying model will include metrics and scorecards that keep SOA alive; the services architecture itself; and the underlying organisational governance of roles and rewards necessary to institutionalising SOA as an active part of the organisation. When introducing SOA many organisations concentrate on overcoming inertia with respect to change; but continuing efforts to institutionalise a services culture will be necessary, to overcome “homeostasis” (the tendency over time for a stable working system to return to its initial state when disturbed).

BEA now has experience of many large companies implementing SOA governance effectively. The specific implementation details aren’t usually made public, but the general characteristics of these efforts (from an NDA briefing) are interesting. For a start, there is a definite timeline, delivering the SOA-based organisation incrementally. In the early stages, buy-in at all levels is important, training may be necessary, and the strategic architecture can be formulated. At later stages, the first services can be delivered and evaluated; at the very end, only when many services are available, can you usefully address service portfolio management. It is important to balance local innovation against enterprise co-ordination—and you must make sure that your organisational structures and roles support what you are trying to do. And, overall, you mustn’t lose sight of the reusable business services that are the ultimate objective of SOA.