Enterprise Initiatives

This blog focuses on Enterprise IT topics such as Enterprise Architecture, Portfolio Management, Change Management, Business Process Management, and recaps various technology events and news.

IT driven SOA
Over the past year I have collaborated with literally hundreds of IT professionals about SOA either at conferences, through networking, via blogging, or in person. From what I have learned, most SOA initiatives are driven by IT and the biggest challenge is getting the business to buy into the technology. The advantages of IT driven SOA is IT can take a top down approach to SOA, build the governance in from the start, and gradually ramp up their staff's knowledge of SOA. The downside is the business may not want or understand SOA and all you wind up with is an exercise on "what could have been". In summary, IT-driven SOA gives you the opportunity to do it right, but you risk the business rejecting it.

Business driven SOA
Business-driven SOA has a completely different set of pros and cons. Business-driven SOA gives you the strong sponsorship and the business resources required to align the technology to the business. It also makes it easier to tie BPM to your SOA initiative which greatly increases the value of the project to your company. Not only can you make great improvements in time to market, reusability, and reduced maintenance, but you also get operational efficiencies in the business by reengineering business processes.

So what are the cons? First, the business doesn't understand or care about governance. Once you buy the SOA stack, the expectation is to start delivering ASAP. In these scenarios, IT is typically forced to attack SOA from a bottom up or middle out approach. The risk here is that over time, you may never fully achieve a true service oriented architecture if you don't bake in the governance at some point. You run the risk of building JABOWS (just a bunch of web services). In some business-driven projects that I have seen, IT does not fully support the initiative. This creates a lot of wasted energy for the architect team who has to constantly deal with negativity, resistance, and even personal attacks by those who fear change or don't believe in the value of SOA. In cases like this, IT is its own worst enemy.

Resistance to Change
So how do we overcome resistance to change? Robbins and Judge, two thought leaders in organizational behavior, describe 7 tactics for dealing with resistance:

  1. Education and Communication - By constantly communicating, evangelizing, and training, resistance can be reduced by minimizing misinformation and rumors and can actually help in the selling process.
  2. Participation - Getting people involved and giving them accountability makes it harder for them to resist change. If they are any good, they will quickly see the value in SOA.
  3. Building Support and Commitment - You can't be everywhere all the time so you need change agents spread throughout. Their job is to evangelize the benefits of SOA and the value it will bring to the company. At the same time they must address any resistance immediately otherwise it will spread like cancer. The biggest reason for resistance is fear. The change agents need to find out what is causing the fear and communicate that to the person driving SOA so the fears can be addressed across the organization.
  4. Negotiation - Sometimes people just don't believe in the vision and there is nothing you can do to change their mind. This is where you hear the cries, "That will never get done here". For these people you must identify what is in it for them. If they are non management, you can explain the potential career path benefits and point to reduction in production support and other monotonous chores. If they are on the network side you can point to centralized security, the value of the ESB, and many other things that appeal to the networking folks.
  5. Manipulation and Cooptation - Steer far away from this one. This will destroy your integrity and will make you unable to deliver any project once this tactic is exposed.
  6. Selecting people who accept change - This is key. There are enough people who will throw daggers at the project from outside. The last thing you need is someone inside fueling the fire. As I mentioned in a previous post, we look for motivated people who embrace change and buy into the vision.
  7. Coercion - File this under unethical and see bullet 5 for consequences.
The higher up you have buy in, the easier it is to deal with resistance. If you don't have active support from the top, you can spend an enormous amount of energy fighting resistance. When I say active I am talking about participation. That means the IT leaders, even those who are not directly involved, must be actively involved in some form or fashion to show their support of the SOA initiatives. Even if the involvement is as little as inviting architects into team meetings to give updates. Any IT shop should be able to figure out the technical challenges of SOA. The hard part is dealing with people and change.


Post a Comment

Subscribe to: Post Comments (Atom)

My favorite sayings

"If you don't know where you're going, any road will get you there"

"Before you build a better mouse trap, make sure you have some mice"