Roles in SOA Governance

Posted by Stefan Tilkov on Jul 18, 2007

Sections

Enterprise Architecture

Topics

SOA ,

Governance

Tags

SOA Adoption

The IT in most large organizations has grown over a period of years or even decades – and it shows. There are applications built on a Mainframe using IMS and CICS; there are command-line applications running on Unix platforms; there are the remains of partially successful client/server and 4GL experiments, UIs that expose first generation object-oriented thinking to their unfortunate users … and all of this is kept together by duct tape, or in other words: a multitude of different integration technologies, from file-based interfaces to database replication, from API access to screen-scraping, with some RPC, CORBA, and at least two EAI platforms thrown in for good measure. Or in other words: Looking at it as a whole, the IT in most large companies is a total mess.

There is a discipline, known as Enterprise Architecture, that addresses this from a logical, modeling and maintenance perspective – i.e., manage the application portfolio, document the connections, and plan for a continuous improvement and gradual modernization of what makes up the application landscape. But in my experience, this approach is largely descriptive most of the time, and not primarily intended to enforce a consistent conceptual architecture through change. This is where SOA comes into play.

SOA promises to introduce explicit boundaries between functional areas that are designed according to business demand, not IT needs. (For an excellent approach to this, see Steve Jones’s book here on InfoQ.) Services become the primary conceptual elements that are managed, introduced, developed, that are assigned a budget, an owner. Services are candidates for being out-sourced, replaced, modernized; gradually, the company’s IT moves from an application-oriented architecture that relies on integration towards a service architecture that makes interoperability between autonomous services the default instead of the exception.

To make sure SOA succeeds, many vendors, analysts, consultants and practitioners agree that Governance is a critical ingredient for a successful SOA initiative. This makes it sound as if governance is something that is needed only during a company’s transition to SOA. While this transition itself is probably going to take a decade – at least in most organizations I’m familiar with – it still makes sense to view SOA Governance as something that is practiced continuously, even once the majority of an enterprise’s assets are service-oriented already.

This article explores a potential set of roles for successful SOA Governance, the roles of “SOA Domain Architect”, “SOA Platform Architect”, “Service Designer”, “Business Service Owner”, and “Technical Service Owner”. Whether you adopt these names or choose a terminology more in line with your current approach is secondary, but I believe that the tasks described for these roles throughout the following sections need to be formally assigned in any case to ensure SOA can deliver what it promises.

Let’s take a look at each of these roles in more detail.

Service Designer

Designing a service is a task that requires both technical as well as business skills. The skill profile of a Service Designer can be compared to that of a more technical business analyst, or a high-level developer with more domain knowledge than technical expertise. The service designer’s task is to come up with a “good” service design, i.e. he or she needs to find the right balance between suitability for the particular problem and re-use potential in a different or more general scenario.

To be able to design a “good” service, the service designer needs to decide how to group operations (if you choose to adopt the “classical” style of SOA) into interfaces - i.e., decide whether a single service is actually better expressed as a number of collaborating or independent services. He or she also needs to decide how to name operations and services, what granularity a service operations should be, whether or not to rely on existing services, how to handle error cases, and many more aspects that influence the quality of the particular service at hand, as well as the overall service landscape.

I will risk making a controversial statement: Because XML forms the basis for documents exchanged between service consumers and service providers in most organizations, a service designer absolutely needs to have good, if not very good command of XML and related standards and technologies, specifically XML Schema (XSD), namespaces, and common XML design principles. Most of the time, a service designer will rely on some tool support for this; but no matter how good the tools may be, it’s still critical that he or she understands what it is they are hiding.

Services are not designed independently of each other, even if the goal for them is to be autonomous. This is particularly true concerning the input and output documents, which will commonly rely on a repository of already designed XML Schema fragments. Services can (and should) also re-use existing services. For this reason, the service designer needs to have access to an information store that contains this information. For the role discussion – and in fact, even more generally – it’s entirely irrelevant whether this information store is a directory on some shared server, a simple Access database, or a commercial or home-grown full-featured registry/repository solution.

So what has all of this got to do with governance? The service designers follow rules and guidelines during their work. For example, there may be specific rules that govern what gates need to be passed before service design even starts, or when service artifacts transition from one phase in the service life cycle to the next. There may be rules applicable to service granularity, or clustering of services (into groups, domains, or whatever). There are many other aspects in a service designer’s daily work that are being “governed” by company SOA policy, so it’s probably fair to say that the service designers are the primary users or consumers of a company’s governance framework.

SOA Domain Architect

In most organizations, there will be a whole group of service designers who are tasked with supporting either individual business units or the company as whole, since it’s unrealistic to assume a single service designer could be able to design all of a company’s services. The SOA Domain Architect is responsible for ensuring that the work produced by the individual service designers leads to a coherent, high-quality, company-wide SOA. In many ways, this means that the SOA Domain Architect is the lead service designer – in fact, assigning one of the service designers this additional role might be a good starting point, and even if this is not the case, it’s critical that the domain architect is at least capable of doing a service designer’s work (much as a good application architect should be able to act as a programmer).

The SOA Domain Architect’s responsibilities include acting as a final decision maker in case of conflicts regarding service design, determining whether or not a given service should be changed, replaced, or augmented by an additional service. He or she acts as the lead design authority regarding dependencies between services, and must ensure that all consumer/provider relationships are not only documented correctly, but also conform to the companies overall service model.

To the business side – and also, if applicable, to an Enterprise Architecture group – it’s ultimately the SOA Domain Architect’s task to deliver the business value of SOA (as opposed to the technical value, see below).

SOA Platform Architect

There has been a lot of discussion about the “right” technology for SOA, here on InfoQ and elsewhere. But whatever technological choice is being made, SOA’s potential can only be realized if there’s some consistency to the technical decisions. In other words: It’s perfectly fine to base a SOA on Web services, or REST, or CORBA, or Java and JMS, or C# and MQ – or in fact, any combination thereof. But whatever the technical decisions are, they need to limit choice to either a single selection from this (or an expanded) list, or a small combination.

It’s the SOA Platform Architect’s first task to make these choices. Once such as set of standards has been selected – assume, for the sake of the argument, that it’s Web services compliant to the WS-I Basic Profile 1.2, combined with WS-Addressing, WS-ReliableMessaging and UDDI v3 – the SOA Platform Architect is responsible for ongoing maintenance of this list. For example, there might be new standards worth adopting, or technological alternatives, such as RESTful HTTP, might be introduced. Products – which should never form the basis for the overall technical SOA architecture, but should instead only be used to implement it – need to be evaluated, and possibly introduced. Lastly, a company-wide SOA consists not only of business services, but also technical services, e.g. for authorization, transformation, user provisioning etc. For the technical services, the SOA Platform Architect acts as the SOA Domain Architect (i.e., the domain is the platform).

Business Service Owner

If the overall SOA is supposed to further the often claimed alignment between business and IT, it’s critical that a service is not only a technical (IT) concept, but also something the business side of the company is aware of. To ensure this is the case, every service should have an owner responsible for the service from a business perspective. It’s the Business Service Owner’s task to justify the service existence and continuous operation of a service to the stakeholders – and if it’s not possible to find someone willing to fulfill this role, the service itself should be questioned (but see below for exceptions).

The business service owner will decide what functionality the service provides, no matter how it is implemented – he or she is the service designer’s “proxy” to the business side. The business service owner should also play an important role regarding outsourcing decisions, i.e. his interests (and incentives) should be aligned so that getting the most efficient “implementation” is in his own best interest.

Technical Service Owner

There will obviously be services that fulfill a more technical roles – for example, a service that provides user authentication is important, but not directly related to a company’s business function. For services like this, there should be a Technical Service Owner whose role is similar to that of the Business Service Owner described above, only with a more technical interest and focus.

On the other hand, business services need technical owners, too – someone needs to be responsible for the technical aspects of a service, such as its implementation, more technical policy aspects, versioning strategy etc. This is another aspect associated with the technical service owner role.

Conclusion

The simple role concept introduced in this article can obviously only be a starting point. But in our experience, it has proven to be a good checklist of tasks and potential roles that can be mapped to an organization’s existing roles, and show where there’s a need to introduce new ones. Hopefully, it will be useful to you, too – I’m very interested in learning more about the roles you have defined for your SOA initiatives.

Stefan Tilkov is one of InfoQ's SOA editors, as well as co-founder and a principal consultant at (similarly named, but independent) innoQ, a consultancy with offices in Germany and Switzerland.

• Older >