Ronan Bradley's FinanceTech Directions

There has been a lot of commentary on organizational changes required by SOA, but I have not seen much about how SOA will redefine existing roles and create new ones within the changed organization. Instead what seems to be assumed is that much of the responsibility for making SOA work is put at the door of the enterprise architect. As Daryl Plumber of Gartner puts it:

The first thing they have to do is make sure that they have proper architects.

Which sounds a little threatening – how many existing enterprise architects will pass this new ‘properness’ test?

Daryl’s comment comes from an excellent and wide-ranging interview around the organizational impact of SOA. He follows this line with some comments which probably reflect the consensus view on the subject but made me stop and think (http://mediaproducts.gartner.com/gc/webletter/progress_sonic121606/issue2/gartner1.html) There has been a lot of commentary on organizational changes required by SOA, but I have not seen as much about how SOA will redefine existing roles and create new ones within the changed organization. Instead what seems to be assumed is that much of the responsibility for making SOA work is put at the door of the enterprise architect. As Daryl Plumber of Gartner puts it:

The first thing they have to do is make sure that they have proper architects.

Which sounds a little threatening – how many existing enterprise architects will pass this new ‘properness’ test?

This comment comes from an excellent and wide-ranging interview with Daryl around the organizational impact of SOA. He follows this line with some comments which probably reflect the consensus view on the subject but made me stop and think . In essence, he sees architects having a role which is a tricky combination of coordinator and influencer:

If an enterprise makes the architect the center of that organization, then the roles of the other people around them, the developers, and the administrators and so forth, begin to change.

An architect is going to be looking at principles and guidelines, but a developer now has to recognize that not only are they building code for a system, they are building a set of components, modules, or services, as in service-oriented architecture.

What made we stop and think is two-fold:

Firstly, in Daryl’s world the architect becomes the interface point with business and even the center of the organization. While most enterprise architects are very capable of speaking with the business, SOA can and should change the goal-posts radically: In a successful SOA, there should be a high level of alignment between IT and business and therefore more and deeper communication. If enterprise architects are meant to be deeply involved in this interaction across the entire business, this is a potentially huge increase of the scope of the role.

The second part of the suggested role definition removes the architect from any sense of ownership of the services themselves (which is right as this would certainly be the wrong job and too big a job). However, this definition risks placing the architecture role in that classic no-win position of all the responsibility and none of the control and pushes a primarily technical role into what should be a strongly business focused environment of a business-aligned SOA.

The second issue that made me stop and think that struck me from Daryl’s interview relates to who owns the services: The key artefacts within a SOA are of course the service definitions (and their related data models). The benefits of reduced cost and increased flexibility rely on these being maintained, evolved and most importantly used as often as possible. So what is the role of the owner and what does he/she own? To my mind ‘owning’ in a business-aligned SOA environment should be in the sense of being responsible for making sure the services are used and used in the way to give most benefit to their business. This person can’t be our super-SOA architect who has all those other jobs!

The solution to me seems quite obvious – if a SOA is business aligned, the business must be more involved in SOA. this suggests that the owners of the service need to be directly aligned to the business owners of the associated business services. How this is done in practise will depend on the organization and its structures and goals. What will be true in every case is that the focus of this role should shift towards business skills and away from technical skills. The service owner can always go ask the architect for help and the architect can then focus again on ensuring that principles and guidelines are followed!