Enterprise Initiatives

One of the challenges of explaining the value of Enterprise Architecture to your organization is the perception that EA is nothing more then a think-tank for high priced architects who practice philosophy from their Ivory Towers. Executives are concerned that the EA team will produce nothing more then nice documents and diagrams and will not contribute to the overall benefit of the company. I have seen three different approaches to EA based on this perception.

Not in my house!
In this scenario, the CIO totally buys into the perceptions and will shut down any attempt to invest in EA. This often occurs when the key decision makers are not highly technical and clearly do not understand the value of EA. IT shops who take this approach tend to work hard and not smart, reinvent the wheel over and over again, struggle to keep up with demands of the business, and lack a flexible architecture to adapt to change.

Half-baked EA
Some companies attempt EA with only "one foot in the water". In this scenario, they believe in the value of EA but fear the perceptions of EA. Instead of addressing the perception issue, they choose to create tactical deliverables so that they can "show" the business concrete evidence that they are delivering value. By giving their architects tactical tasks they take away strategic thinking time required to build out an EA. This becomes a distraction that may entertain the business for a short amount of time but it increases the likeliness of your EA effort to fail. To deliver EA, you must spend the time up front to create the vision, the roadmap, and then methodically produce the deliverables required to deliver the vision.

Full blown EA
These companies have fearless leaders who are able to sell the value of EA and don't let perceptions get in the way of creating real value for the organization. These companies will have to fight the good fight since many people in the organization believe in the Ivory Tower perception and will not be supportive of the initiative. It is critical that the EA group stays focused to the cause and does not get distracted with non strategic initiatives. In other words, they cannot get sucked into the machine! On the flip side, these companies must be very careful that they do not try to over analyze the enterprise and spend months or years creating documents and delivering nothing to the organization.

How do we get there from here?
My advice is to treat EA like any other large culture changing initiative. Follow the steps I highlighted in the post EA, SOA, and Change:

1. Build strong business case
   
2. Secure executive sponsor and top level buy in
   
3. Create a Road Map
   
4. Communicate the Road Map
   
5. Empower Others to Act on the Road Map
   
6. Start small, deliver early and often (agile)
   
7. Expand, leverage architecture
   
8. Govern

The challenge is getting through the first 5 steps in a reasonable amount of time so that you can start showing value in steps 6-7. Here is an important point. The business can never really "see" Enterprise Architecture which is why the half-baked EA methodology is a waste of time. Instead of trying to create deliverables that are visible to the human eye, the EA team should focus on getting the development teams to leverage your EA. EA is under the covers and should not be a puppet show for the business. The business should "feel" the impacts of EA when IT starts improving its time to market, delivering consistent and standard products and services, becomes flexible and agile, and becomes a partner in matching technology to business goals and objectives.

EA is a journey and should be treated as one. It will take years to mature an EA but it shouldn't take years to provide value. There are many books that describe the phases of EA maturity (Enterprise Architecture as a Strategy is my favorite). Each phase can produce real business benefits. Keep the long term goal in mind but set your short term goals on value added deliverables that are stepping stones for the final phases of EA maturity. And most important, stay out of the Ivory Towers!

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.

Yesterday I summarized my thoughts on Zapthink's article called Who's Killing SOA. Today I plan on answering the three questions that Jason Bloomberg asked his readers at the end of the article.

Do you feel that SOA is truly in jeopardy?

No. I think companies that don't approach SOA as a culture changing, long term investment are in jeopardy. The SOA value proposition is real. Implementing it is no walk in the park. You need strong executive buy in, significant funding which goes far beyond the stack, great people and great partners, world class tools, and a strong champion to take the team through the trenches and conquer the complex technology and culture challenges.

I believe that only 40-50 percent of the companies that try to implement SOA will eventually complete a few SOA initiatives. Half of them will get it right. The other half will confuse implementing a ton of web services with implementing a service oriented architecture. Those that make this mistake will not see the true value of SOA. So when the dust clears, I predict only 25-30 percent of the companies will get it right. This will cause a perception that SOA was another fad that has come and gone and left many companies in its wake. The reality will be that once again, many IT shops don't know how to manage large and complex projects.

Which forces do you feel are most responsible for the dangerous situation SOA finds itself in?

Leadership, resistance to change, and project management. Let's start with leadership. The IT person leading the charge must truly understand the concepts of SOA. That doesn't mean that they attend a Gartner summit and then start a project. This person must perform extensive amounts of research and understand the concepts of a distributed architecture, the benefits of a layered and loosely coupled architecture, and the need to view requirements and design at an enterprise level as opposed to an application level. In addition, one must understand some of the drawbacks of SOA like performance trade offs, complexity of managing a distributed environment, and the extensive investment in governance that is necessary to make it all work.

Resistance to change. One of the biggest killers to any new technology approach is resistance. The project champion and executive sponsor must constantly apply change management principles. The stakeholders must understand WIIFM (what's in it for me?), what the road map looks like, and how to get there. Roles and responsibilities will change, IT must work closer with its business partners, waterfall methodologies must be cast aside for agile methods, and new skill sets must be learned and/or acquired.

Project management. Any project that touches the enterprise and radically changes the culture and alters the existing technologies needs a strong project manager with a thick back bone. Projects like this can easily get off track. Some companies spend months and months generating documents and going into analysis paralysis. The PM must set aggressive and short milestones that force the team to show value to the business early on. The business can't afford to have IT's top talent go off into a closet for a year without delivering. Set delivery goals every 2-4 months. Show value early and often to get momentum, continuous buy-in, and to help foster change.

How can we work together to overcome the challenges, and craft SOA into the mature, ubiquitous approach we all desire?

Keep writing articles like Who's Killing SOA. Continue to encourage the EAs to collaborate via Blogs, wikis, etc. Continue to host meaningful conferences with industry experts to share the knowledge and lessons learned. One of the reasons why I blog about SOA is because I am learning this stuff on the fly and feel obligated to share my successes and failures so those getting ready to walk down the path can learn from my experiences or give me advice. Much of the valuable information that I gathered while studying SOA came from discussions that I encountered on the internet. Whether it was a good article on Zapthink or ZDNet that sparked comments from architects around the world, articles from experts who shared their experiences on their blogs on in wikis, or networking at conferences, every person's perspective was an important piece of information that I used to formulate my own ideas on how and why to implement SOA. The bottom line is that we must leverage the collective intelligence of all those willing to share their experiences.

There are several good articles about running IT like a business (here and here). I would like to ask the question, "Are you running IT like it's your business?" What are some of the barriers for preventing IT leaders from being able to transform their IT shop into a well oiled, cost effective machine?

• Resistance to change
• Lack of resources (time, money, and human capital)
  
• Lack of tools
• Lack of metrics
• Lack of process

If you owned your own business would you let those obstacles get in the way of making your business more profitable? I didn't think so. So why should your shareholders tolerate it? In today's world of IT, there is a lot of pressure on CIOs to cut costs, pursue outsourcing, improve delivery, and enable the business to grow. If your shop is spending most of its efforts "keeping the lights on" are you really just managing a cost center?

Let's discuss the five barriers to success that I listed above. First is resistance to change. According to Prosci, the experts on change management, the top reasons for resistance to change are:

• Lack of understanding around the vision and need for change.
• Comfort with the status quo and fear of the unknown.
• Corporate history and culture.
• Opposition to the new technologies, requirements and processes introduced by the change.
• Fear of job loss.

In order to overcome these obstacles you must manage both the human and business aspects of change. To manage the human side of change you must define WIIFM (what's in it for me) for people at all levels. That equates to having distinct communication plans for Sr. management, mid level management, and non management personnel. You also must constantly reinforce and adjust your communication plan throughout the duration of your change initiative. It only takes one respected person to doubt the initiative and the whole house of cards can come tumbling down.

So define a clear vision, get executive level buy-in, communicate early and often, manage resistance, and measure your progress. I also recommend that you find a partner to help you foster change. Why learn everything the hard way? Accelerate the learning curve and secure a change management partner to guide you to a successful implementation of change.

In part 2, I will discuss the next barrier to success, Lack of Resources.

Stay tuned.