Friday, April 16, 2010
Governance and Organization
Moving to a transformative environment, SOA requires the establishment of governance and competencies adapted to handling the specific features of this emerging technology framework. Gone are the days of purely hierarchical structures with their military style command lines. SOA requires a comprehensive, holistic management approach. Indeed, transformation management requires the understanding that there are a variety of ways to view and control a project.
Just as with the proverbial elephant that is felt by a group of blind individuals (some touch the legs and “feel” a tree trunk, others the ears, and sense a flag, and so on) the system will appear differently to the various constituencies. The engineering teams will focus on the physical elements of the solution: access technologies, networking and the central computers. The business partners will be more concerned with the views of Clients and Services including the manner in which information is presented, processed, and consumed. Software developers will see specific service implementations along a 3-tier Model View Controller (MVC) paradigms; while enterprise architects and project managers will want to maintain the “whole image”; becoming the guardians of the holistic view of the system.
It is important to note that there is a time dimension as well. The optimum structure for execution is not necessarily the ideal way to structure the ongoing support of the deployed system. Ideally, the structure to execute the transformation should be one that gradually morphs into an organization that is capable of maintaining and supporting the new system on a steady-state basis.
The challenge is made more complex by the fact that business-as-usual operations must be maintained, even as the transformation is being executed. This means you will need to accept the existence of a dual organization structure for the required transitional period: the organization needed to support the legacy environment and the one executing the transformation.
The question is how to gradually sunset the skills, while ramping-up the new organization needed to support the future end-state. Most important is how to do so with regard to the issues presented by people considerations. People are not replaceable machines, and the transition from legacy to new will require a carefully crafted staffing plan that encompasses retraining, reorganization and evaluation areas.
It’s always disconcerting to mix the “old” with the “new”. The feeling is just like the one I had this morning when I accidentally used toothpaste as shaving cream. Blame the shape of those new toothpaste containers, though I have to admit the mint in the toothpaste gave me a curiously refreshing shave (completely unlike the nasty feeling one gets when confusing hemorrhoid cream with toothpaste!).
There is no escaping the reality that for a period of time, you will need to handle a mixture of “old” and “new”: old processes running in parallel with new processes, long tenured people not yet fully trained in the new dealing with younger staff not yet knowledgeable about the existing processes, senior staff versant in the “old ways” working with newer staff unacquainted with the cultural traditions, and so on. This is not an easy task. We all know that dual organizations are usually a recipe for conflict and duplication. You should therefore make certain that the specific governance and responsibilities during this messy period of transition are clear and agreed to by all concerned.
If there is a new tactical requirement, should you give it to the legacy team to “patch” the legacy system, even if in the long run the solution might be a throw-away? Or should you try to develop a hybrid solution that can be expanded to fit the strategic standards?
In the end, as leader of the effort, you will need to broker the assignments of emergent work so that new work takes place in the right sphere. In general, the easiest way to scope responsibilities is to task the legacy team with maintaining daily operations and service levels and get the transformation team to fix its sights on the new deliverables. The problem occurs when new urgent requirements demand shifting the focus away from the end state delivery. New requirements must be handled only when truly urgent and necessary and must be the domain of the legacy group only on an exception basis. At the start of the transformation, you will need to agree with the line of business as to the manner in which you will jointly handle tactical requirements, and the thresholds that must be crossed in order to trigger urgent and necessary changes to the legacy environment.
IT Transformation efforts require the involvement of other groups in the company other than technology. This means the business, finance, legal and general operations teams all need to be involved at some point. However, there are three specific groups whose roles you need to make certain are in place from the very start: Product Management, Architecture and the SOA Team. More on each of these three teams next.