The Hope, Carrot and Stick of SOA Change Management

It is surprising how many enterprises I have worked with that realize the importance of change management when deploying a new technology but

rarely embrace it fully. For SOA to be successful an enterprise must change its behavior to make it effective; therefore, change management is a serious consideration for SOA.

Culture change is not something that can be achieved by flicking a switch on/off and hoping that the way “people act, interact, and collaborate” changes overnight.

Therefore, enterprises must not underestimate the impact on culture change, and must make sure they have an approach to cater for this fear of change. Resistance to the change must be accounted for and expected, and therefore the human side of SOA Governance should be addressed systemically. Consider the following as part of a change management approach.

  • Identify and engage all impacted stakeholders from executives to developers.
  • Communicate early and often regarding the message and have a central location for program information accessibility, such as a SOA initiative portal.
  • Make the case and rationale for selecting SOA as an approach.
  • Inform stakeholders of the changes to their environment and their role. Define metrics to help align individual behavior and performance.
  • Include lower-level employees in the decision process and implementation plans. This increases the likelihood to gain commitment. People are more committed to decisions to which they feel they had input.
  • Obtain broad buy-in in areas like the future state vision, goals, strategy, etc.
  • Provide training and mentoring both technical and business.
  • Perform team-building sessions among the major players that need to work closely.
  • Have strong, active, visible, vocal, and continual support from the sponsor.
  • Pro-actively communicate governance policies and, if needed, explain more than once. Ensure updates to policies are properly distributed with feedback solicited.

I have seen too many change efforts fail because they were not given the sustained attention, commitment, and time to take hold. Execute change management too slowly and an enterprise risks losing momentum because the initiative does not seem important enough and gets lost in the day-to-day priorities. Execute change management too fast and an enterprise risks leaving people behind, and when stakeholders do not understand why the change is happening they will tend to resist it. To assist in changing behavior a number of models (known as the 3Es) should be considered.

  • Encouragement Model – The encouragement model (also known as the hope strategy), focuses around traditional teams such as the Enterprise Architecture group whereby they define standards, best practices, products to utilize, patterns, best practices, etc. The EA group then “encourages” teams to use these standards. The EA group has the mandate to define standards but generally lacks any authority to force their usage. This tends to be the most common and unfortunately the least successful model.
  • Enforcement Model – The opposite end of the spectrum is the enforcement model (also known as the stick strategy), whereby the defined standards are enforced on project teams. Project teams are given ultimatums: use the standards defined or pay the consequences. Examples of these consequences range from career restrictions, placements on maintenance projects, and even termination of employment. This model tends to be the most successful but unfortunately can lead to low morale.
  • Enticement Model –  The enticement model (also known as the carrot strategy), links inducements to project success. Example inducements are bonuses, assignments to interesting projects, enhanced career goals, etc. Delivering a project on-time is not the only measure by which a project will be deemed successful. Example metrics focus around reuse, business/ SOA alignment, Service contribution, etc. Measures and rewards communicate the values of the organization and help to build the collective responsibility that will actually change behaviors.

I usually recommended that enterprises use a combination of the enticement and enforcement models. An enterprise can start with the enticement model but with the project teams knowing that the authority exists to use the enforcement model when deemed necessary. Where a large resistance is expected, I recommend enterprises to build a skunk works team from newly hired employees to engineer the Services required by the enterprise.

Lastly before I sign off I wanted to quickly cover the need for education and training.  An enterprise needs to approach education on multiple fronts, i.e. include both strategy aspects and technology aspects. Enterprises must inform their employees regarding the enterprise’s SOA strategy and how their work contributes to it, and how their environment and role will change.

Employees have to feel confident that the SOA initiative is “real” and the enterprise has to address the “ignore and it will go away” attitude of some employees.

Education has to be addressed at all levels within an enterprise from developers to executives. SOA requires an enterprise to be a learning organization. Employees require continuous education, must have the room to grow, and must feel that their opinions are being heard. It is rare that all employees will accept the way in which their roles and environment will change. With this in mind, it is important to identify the employees who are champions, laggards, and cynics: and deal with them appropriately.

Good Luck, Now Go Architect Manage Change…