Friday, May 7, 2010

The SOA Team

In addition to having a strong, effective architecture group, you must create a group dedicated to SOA.  Since the data governance has historically been well defined for the roles of Data Base Administration, Data Analysis, and Data Architecture, there is a tendency to also organize SOA in a similar manner to DBMS governances. Don’t. Services are not data. While it is true there may be some similarity to the work of DBAs and SOA Service Analysts (e.g. Data Base Schemas vs WSDL Interfaces), SOA is so different enough, making it wise to establish the SOA governance separate from the data team.
Make this SOA governance responsible for the following service life-cycle areas: service interface validation, testing, service repository management, service deployment, versioning and services sun-setting. Note that since the actual service development is performed by the actual development organization, the role of the SOA Group is one of coordination and control. This function usually consists of a small group (two to four individuals) whose role is similar to that of a Data Base Administrator, but with a special focus on all things “services”.

In the diagram above, the SOA Group covers the roles of Service Analyst(s), Repository Manager, and Service Librarian(s). Of these three, only the Service Analyst is required to have a programming background (the stronger, the better!); whereas the Repository Manager will have a background related to operations (someone with experience managing LDAP servers comes to mind). The Services Librarian may well come from a data organization.
It is essential that the team be formed of very competent staffers. Now, before you say “Duh, that’s obvious!” let me remind you that we often fail to elect our politicians based purely on their competency. We vote for them because, “He’s the type of guy I could have a beer with,” or simply because we like the image he projects either or his fashion style.  As managers, we often incur the same biases and tend to empower those on our staff who better match our ideal image of competency. It often happens that when forming a new team, it is often with “volunteers’ from other groups who want to escape their current roles instead of wanting to contribute to the new group.  Don’t make the SOA group the Gulag of IT.
Competency does matter, but it is not always easy to define “competency”.  Recently there has been a trend to evaluate employee competencies around the concept of “certifications”. For example project managers are expected to show PMI (Project Management Institute) certifications, testers have their own certifications, DBAs get their certifications (usually from DB vendors), and so on.
Entire industries have been spawned from the certification business. Now, I am not suggesting that a certification is a bad thing in and of itself, but I have met many who have specialized in collecting all kinds of certifications and yet are not particularly competent. I suppose I could give them a certification for their ability to obtain certifications, but that’s about it!  My point is this: be suspicious of anyone flashing a long list of certifications. Either this individual has had too much time on his or her hands and has not been focused on performing actual  work, or this person’s certification portfolio proves he’s a genius; making you wonder why the need for all those certifications in the first place.  Forget the diplomas. Ultimately, competency is something that an employee either has or hasn’t. You’ll know if he has it by what he delivers.