Enterprise Initiatives

Back in September I shared with all of you the presentation I gave about SOA and Organization Change Management. Today I am happy to share the podcast from that discussion that took place at the quarterly SOA Consortium meeting in Orlando. Here are the slides.

And here is the podcast that goes with it.

The panel discussion at the tail end of the presentation is fantastic. There were a lot of great questions and many lessons learned shared from experts like Todd Biske, Brenda Michelson, Fill Bowen from IBM, and others. If you have the time, listen to this podcast. Failure to recognize and counteract the resistance to change is the number one cause of failure for all enterprise initiatives, not just SOA.

As I look out into the future of IT over the next 5 to 10 years, I see a huge shift in how IT shops will need to operate in order to help their companies survive. We are already well aware of the pressing needs for IT to provide agility and flexibility for its business partners due to the speed at which the business landscape is changing. The forces of globalization, economic pressures, and advancements in technology are creating as much change in an 18 month period than we used to experience in a decade. In order for companies to survive and thrive, they need to adapt. As Charles Darwin once said,

“It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change.”

I wrote a post last year called How did we become a Dilbert cartoon which discussed my theory on how IT has become so out of touch and bogged down with trivial issues. I see Dilbert every day whether it is at the places I have worked, the case studies that I research, the discussions I have with peers at conferences, or from the forums and user groups I participate in. Somewhere along the line, many IT professionals in the US have forgotten what IT's purpose is and take their IT profession for granted. These people put themselves and their favorite technologies first and their business and shareholders second. How many important initiatives have you seen stalled because certain individuals refused to change or learn something new? Look how many companies are struggling implementing transformational initiatives like SOA, ITIL, business process reengineering. All of these types of initiatives can make a huge impact to the bottom line. But how many of these have stalled because people fought these initiatives with all of their might? The basic problem is that transformational initiatives requires transformational leadership! How many leaders within IT do you know who excel in the three critical areas of transformational leadership required to deliver technological solutions: Business Acumen, People & Organizational Skills, and Technology skills?

From Misc IT

Looking down the road, I see certain technologies maturing and becoming critical to helping businesses staying competitive. These technologies are:

• Infrastructure as a Service (IaaS)
• Platform as a Service (PaaS)
• Social Networking/Software within the enterprises
• BPM, SOA, and Event Processing working in harmony
  

I am amazed at the number of pundits that exist for all of these technologies, especially cloud computing. Many people are strongly against these advancing technologies at the expense of their own careers (they just don't realize that they are making themselves the equivalent of Y2K programmers yet). Sure, cloud computing has its challenges with data security, privacy, and in some cases reliability, but it is in its infancy state. Instead of focusing on what the limitations are, we should focus on the huge strategic and financial opportunities that it creates. Let me quote Darwin again.

“Ignorance more frequently begets confidence than does knowledge: it is those who know little, and not those who know much, who so positively assert that this or that problem will never be solved by science.”

I still remember the naysayers doubting PCs and distributed computing and declaring that nothing could beat the mainframe. Do you here the negatively by some about social networking and social software? Doesn't it sound like the negativity we heard when people were trying to bring the Internet into corporations?

Why do we get in our own way of progress? Why are we living in Scott Adam's world of Dilbert? Why do system administrators fight cloud computing? Is it fear of job elimination? Loss of control? Not wanting to learn something new after 20 years? Why do IT professionals revolt against SOA? Does it require them to actually architect something rather than drag-n-drop some code in their favorite Microsoft IDE? Does it force them to collaborate with other people including business people and take them out of their comfort zone? Is it hard work? I don't know what the answer is but I do know that with out transformational leadership, the resistance can put up huge barriers and can kill initiatives that can give a company an edge over its competition.

What about outsourcing? Do you really want to get IT professionals fired up? Just the mention of the word brings anger and negativity to many. But why? Maybe we all need a lesson in economics or should simply read the book The World is Flat. While we in the US are sitting here complaining about change, countries like China, India, Taiwan, Ireland, and many others are graduating engineers by the thousands. These folks are more than willing to work on any task that they have the privilege to be given. And there lies the problem. To these people, work is a privilege, a way to have a better, more prosperous life. In the US, many people see their job as something that is owed to them. How many people in your shop are actively working on improving their skills? Just the fact that you are reading this post puts you many steps ahead of most. Many people that I have worked with in my 23 years do not invest their own time and energy required to continue to learn and adapt to the world around them, both from the technology and the economic standpoint. I am fine with the fact that many people value their personal time way more than some of us do, but if you don't invest the time you do not have the right to impede in the advancement of the organization!

Getting back to the emerging technologies that I mentioned above. To be successful implementing the transformational change to embrace these technologies, IT shops need the following foundation:

1. Strong leadership with the ability to promote and manage change
2. A well run and planned Enterprise Architecture
3. Solid working relationships and trust with the business partners
4. Discipline
5. Fiscal awareness
6. Numerous Strategic Partners
   

Strong Leadership
The leader(s) must be visionary, strategic, emotionally intelligent, and must be able to execute. I have seen leaders who have great ideas and are pretty smart, but they fall down when it comes to execution. Nine times out of ten, the failure can be contributed to people not the technology. In other words, resistance to change prevails and the company reverts back to the status quo leaving IT with the reputation of a cost center. The following presentation speaks to how to anticipate and plan for change up front to reduce the odds of failure.




Enterprise Architecture
To enable a flexible and agile enterprise, it all starts with an architecture that maps to the overall business strategy. No longer can we afford to build software in silos and continue to pay huge sums of money to keep the lights on. In order to be efficient with our ever shrinking budgets, we must have an IT strategy that is supported with an architecture geared towards maximizing our resources (both human resources and technology resources). The more standard and consistent the architecture is, the easier a company can move to the clouds, alter business processes in days instead of months, change business rules on the fly, adapt to mergers and acquisitions, and connect to partners, suppliers, and customers. Remember this, your biggest threat tomorrow might be a company that does not exist today! Why, because a startup does not have legacy to deal with and will most likely embrace these new technologies from the start and race right by you to the finish line. Companies must change or die. The following presentation speaks to the value of EA.


Relationships and Trust
In order to accomplish transformational initiatives, IT must forge great working relationships with its business partners, both internally and externally. Without the trust, funding and executive level support will be extremely hard to come buy. To earn that trust, IT must understand the business and put forth solutions that are beneficial to the business first and IT second. The following presentation shows an example of how SOA was explained to the business in tangible business terms (increase sales, customer satisfaction, etc.) instead of technology terms (reuse, ESBs, services, etc.).


Discipline
This is critical. We can no longer fly by the seat of the pants anymore. It costs the company too much in maintenance and hinders agility. That is not to say that we should all embrace heavy methodologies like CMM. There needs to be the right balance between process and agility. And for those IT professionals who will fight process to their death beds, there are millions of knowledge workers in foreign countries hungry to do your job for you. Today's resistance is tomorrow's unemployment.

Fiscal Awareness
Being fiscally aware is a key contributing factor to allowing IT professionals to see the "big picture". After all, the main purpose of most companies is to make money, or in government, to make the best use of tax payer dollars. It's all about money! So why are so many IT professionals so clueless about the financial impacts of the work they do and the decisions they make? How many times have you sat in meetings with armies of people for an hour or two and nothing gets accomplished? How does that contribute to the bottom line. When technologists argue about .Net vs. Java, or IBM vs. Dell for months on end while projects get delayed, why doesn't anybody seem to care? When IT professionals make technology decisions primarily for the sake of technology, they often make a choice that is not fiscally responsible. When making these decisions we must think about more than how we will use the products within IT. There are many factors that need to be consider. We should look at the feasibility not just from a technical standpoint, but also from an economic, operational, and political standpoint as well.

Strategic Partners
And finally, there is so much change and so much to learn, it would be suicide to think that we could deliver anything transformational in a reasonable amount of time without the help of partners. The business can't wait for IT to train an entire staff to a high level of competence on these emerging technologies. They also can't wait for us to stumble and learn from failing in production. Instead we will need strategic partners in many areas to help build the agile enterprises of tomorrow. These partners may be used for the following reasons:

1. Business Process Outsourcing (BPO) - (example: Payroll, HR, web site hosting, etc.)
2. Acquire new skills (SOA implementers, BPM experts, Cloud specialists, etc.)
3. Strategic partners (Organizational Change Management expert, EA help, etc.)
4. Technology outsourcing (IaaS, PaaS, SaaS, etc.)
5. Project based outsourcing

Outsourcing does not mean the same as offshoring and outsourcing does not always relate to development. When cost is an overriding factor offshoring is a no-brainer. Of course without EA and discipline, outsourcing may cost more than expected. There is simply too much to do and so little time to do it. Find the right partners and hold them and yourself accountable for transferring the knowledge to members of your staff.

Summary
I apologize for the length of this post (if you made it this far). I am very concerned for the future of my IT colleagues in the US and had to do a "core dump" on this post. After many years of prosperity, many IT professionals in the US have become intellectually lazy and blind to the opportunities and challenges that this new economy has created. The combination of our financial crisis coupled with the forces of globalization and technological advances will create radical changes over the next decade. Many professionals are too wrapped up in reality TV to realize that the world is catching up and is ready to pass us by. Those who understand that can embrace the new opportunities that these conditions will create. The others will be the equivalent of the Y2K programmers who did not embrace the post 2000 innovations. I'll leave you with another great quote from Darwin...

“In the long history of humankind (and animal kind, too) those who learned to collaborate and improvise most effectively have prevailed"

I was invited to speak at a forum for IT executives in Detroit this week sponsored by Information Week. The purpose of the forum as described in the agenda goes like this...

This executive breakfast, specifically designed for senior business-technology executives, will explore why the pressure is on IT to help the business transform, and how it can meet those expectations. More than ever before, companies are demanding their CIOs to be strategic thinkers in helping them innovate and operate at peak performance - especially as businesses are under pressure from the poor state of the economy and the ever-faster pace of change in a global market. In this environment, you can't miss this opportunity to gain insight into the tactics and strategy that will help you be on your best game.

I was specifically asked to talk about why transformational IT initiatives like BPM & SOA fail and what advice I would offer to prevent failures from happening. I put together the following presentation which is a combination of some of my previous presentations, Preparing for SOA and SOA & Change.

I wrote a very popular article on CIO.com a while back about the Top 10 reasons why SOA fails. I speak to each of these points in the presentation and present solutions for each. I also discuss using John Kotter's 8-step process for managing change which I highlight in the presentation. Here are my keys for preventing failures.

1. Plan for and manage organizational change


2. Key drivers should be business focused not IT focused


3. Evaluate internal skills and fill gaps. Do not try it without help!


4. Don't let the vendors drive your architecture. Do your homework.


5. Grow your governance model over time

Speaking of governance, here is an analogy I like to use...

Implementing SOA without a solid governance model is the equivalent to having an airport without a control tower. Sure, there are some very good planes and talented pilots, but without the proper planning and timely information the end results would be disastrous. So make sure you build a control tower and hire some air traffic controllers!

If you would like me to create and present a custom presentation like this one, feel free to contact me

There is no shortage of advice on the web of the do's and don'ts for tackling SOA. One topic that I don't see discussed much is the assessment of a company's IT skills as it pertains to the ability of a company to comprehend and actually deliver on the promise of SOA. This is part one of a series that addresses the many skillsets required to deliver a Service-Oriented Architecture.

I have mentioned in the past that companies that have not invested in enterprise architecture may struggle as they shift from software development to software engineering.

Here are the wikipedia definitions of these two terms:

Software development is the translation of a user need or marketing goal into a software product

Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.

There is a major difference between the two. Software development is the creation of software regardless of the means used to accomplish the task. Software engineering involves using a defined set of processes, procedures, and standards with the goal of improving the reliability and maintainability of the systems being built. So for companies that don't take a software engineering approach to software development, they may have huge challenges doing SOA with their existing staff. Throughout this series I will make reference to the shift from development to engineering as a key aspect of each skills assessment as I discuss SOA evangelists, architects, developers, testers, and many others.

When kicking off an SOA initiative, companies should perform a readiness assessment to identify areas of concern and create action plans to address them. For this series of posts, I will focus on internal skills in the IT organization.

First and foremost, a SOA Evangelist is critical to the success of any SOA initiative. This person must understand SOA inside and out from the perspective of both IT and the business. From the business standpoint the evangelist must understand the business drivers, the financial impacts and ROI, and can speak to the business in their language. From the technology standpoint, the envangelist must understand all aspects of the archtiecture in order to communicate effectively to developers, testers, security professionals, architects, network and infrastructure personnel, project managers, business and process analysts, and management. The evangelist should promote SOA and importance of governance and should help establish the Center of Excellence (CoE) needed to provide oversight and enforce the principles of software engineering. I have seen and read about several instances where SOA initiatives that were successful quickly turned to chaos upon the departure of the company's evangelist. In one case, the company quickly lost sight of the business drivers and began to debate on technical issues like whether the services should be done in .Net or Java. These are the unfortunate consequences that happen when SOA is left to those who don't have a full understanding of the technical and business benefits of SOA and focus on software development as opposed to software engineering.

Characteristics of an SOA Evangelist
An SOA Evangelist should have strong leadership skills, strong technical or even architecture level skills, should be business savvy, have a grasp on core financial concepts, and be comfortable presenting to people at all levels. On the same day, the evangelist can be expected to discuss key issues with C-level executives and then roll up the sleeves and explain the advantages of the distributed nature of SOA to the technicians. This person can expect to be confronted with various pockets of resistance which is natural for initiatives that introduce new concepts to an organization. Organization change management skills are a necessity for a person in this position. One of the key challenges for a person in this position is to get the staff engaged and give them a sense of ownership. Without this, the staff may look at the the initiative as a pet project of the evangelist instead of what it is, a key initiative for the business. The evangelist will have to lean on the exectuive sponsor and top level management to help with this.

Life without a SOA Evangelist
I feel that without an SOA Evangelist, companies will struggle for a number of reasons. First, having an expert on SOA who spreads the knowledge throughout the organization is much more efficient than having various individuals coming up with their own definitions and perceptions of SOA. An evangelist can brand and market the vision of SOA for the entire company so everyone is talking the same language. Second, the evangelist also bridges the gap between the business and IT and ensures that the technologies being implemented are focused on the business needs and not the needs of IT first. In addition, the evangelist can translate IT speak to business speak and spare the business of technical details that tend to dominate conversations when technicians discuss SOA. But most importantly, there is usually many different silos within both the business and IT that must be brought together to work as one. The evangelist is likely the person who knows enough about each silo (at a high level) to help bring all of these parties together. Without cohesion between the silos the SOA initiative can spiral into chaos.

In my next post I will discuss SOA and the architects.

Below is the presentation that I am giving tomorrow at the SOA Consortium. Today we discussed numerous case studies. In each case, there were major changes within the organization that had to be overcome. In some cases, the business had to standardize their business processes which required them to change the way they think and work. In other cases, developers had to shift their mindset from the way they have always built things to a more service-oriented approach. In several of the government case studies, large organizations with completely different cultures and processes had to work with other government agencies that they have never worked with before. I could go on and on but the common theme in all of these case studies was that change was one of the most challenging parts of the SOA implementations, not the technology. In fact, one initiative took a year and a half just to get 18 different government agencies to agree on a standards, requirements, and data definitions. Talk about change!

Anyways, here is my presentation about change and how to plan and manage it.

To successfully lead an IT organization, one must excel in three key areas: Technology, Business, and People.

When attempting to implement enterprise initiatives, those leaders who do not excel in people skills will have some serious challenges. For whatever reason, many IT leaders neglect the "people side of change" (listen to my podcast with ZDNet's Michael Krigsman) and do not address a critical need - Organizational Change Management.

I am a huge fan of Harvard's leadership guru, John Kotter. Kotter has a proven 8-step methodology for leading through change. Here are the steps:

1. Create a Sense of Urgency
2. Pull Together the Guiding Team
3. Develop the Change Vision and Strategy
4. Communicate for Understanding and Buy In
5. Empower Others to Act
6. Produce Short-Term Wins
7. Don’t Let Up
8. Create a New Culture

For more on this topic I recommend his books "Leading Change" , "Our Iceberg is Melting", and also "Change Management: the People Side of Change" by Jeffrey Hiatt and Timothy Creasey.

And remember, now matter how good you do with the technology and business side of the equation, if people resist change your project will more then likely fail.

I was asked by Michael Krigsman to be a guest blogger on his blog IT Project Failures on ZDNet. My post focused on IT Leadership as the main cause for most failures. Read the rest of the post here.

I did a podcast with Michael Krigsman on his blog IT Project failures. We talked about SOA and how to prevent your SOA project from failing. You can read his commentary and listen to the podcast from Mike's post here

The last few years have brought many great advancements in technology and the upcoming years promise to bring more. As companies push to drive the costs of IT down while increasing productivity and output, many large enterprise initiatives have become high priorities. The chart below shows IT's top 10 Management priorities for 2008 (source: CIO Insight):

When you look at this list it is obvious that today's IT leaders need to be experts in more than just technology. They need to understand the business and they need to have good people skills. I created the following diagram which I call the leadership triangle. I feel strongly that IT leaders need to excel in all three areas: Business, People, and Technology.




From the business perspective, not only do IT leaders need to know how the business's products and services function, they also need to be able to speak in business terms. This requires MBA type skills in the area of Finance, Economics, and Accounting. When you produce your business case for initiating a large new technology project like SOA, Green initiatives, or ITIL you must be able to describe business benefits in terms of NPV (net present value), IRR (internal rate of return), and payback periods. When dealing with infrastructure projects like disk consolidation, virtualization, and others you should understand the different rules of depreciation, lease options, contract and vendor management. The list goes on.

From the people perspective, the IT leader must be a coach/mentor, great communicator and presenter, skilled in leading through change (organizational change management), a negotiator, a sales person, and a visionary.

From a technology perspective, IT leaders must have at least a high level knowledge of a variety of areas including architecture, security, infrastructure, regulatory/compliance, data, quality assurance, operations, etc.

It is rare to find one person who excels in these three areas. If you find one, good luck keeping them around for a long time because they are highly sought out. Some companies can accomplish this by assembling a strong leadership team that works closely together towards common goals. This requires the leader of this group to be exceptional from the people perspective.

IT must embrace itself for constant change.
The next chart shows IT's top ten technologies for 2008 (Source: CIO Insight):

Some of the key IT initiatives that could come from this list are SOA, BPM, Business Intelligence, Master Data Management (MDM), Virtualization, SaaS, ITIL, Portfolio Management, Social Computing, and many others. Each one of these initiatives requires people to change the way they have traditionally worked. Some roles and skills may go away and new ones may be created. Many of these initiatives require very specialized skills and demand more collaboration across different areas of expertise, including business SMEs (subject matter experts).

But the technology is the "easy" part. Getting the business sponsors to own and help drive the initiatives and leading people through change is where IT has a huge skills shortage. Many people in IT don't even acknowledge that these two things are important. I can't count how many articles I have read that claims SOA is a failure and is nothing more then hype. The same is said for enterprise architecture (EA) where recently EA has been called a joke. The joke is that companies try these large enterprise initiatives without relevant business drivers and without having an organizational change management (OCM) plan. Many think by simply having smart technicians, they can get any IT project done.

The future will drive even more change.
Over the next few years, cloud computing will become a key driver for reducing complexity, reducing costs, and improving agility. I recently made a short vlog (video blog) on this topic. Software as a Service (SaaS) and Platform as a Service (PaaS) will cause a major shift in the way we think and work. There will be all kinds of resistance from the infrastructure and security staffers. Moving to a platform in the cloud is a threat to the current roles and responsibilities for these folks. Over time (5-10 years), PaaS will become mainstream and IT shops will likely become smaller and will definitely have a different technical makeup then it has today. People will have to retool and stay current with trends. Software will become a true engineering exercise that requires knowledge of distributed systems, security, data management, and networking. Drag-n-drop n-tier developers will become the Cobol programmers of our next decade. Globalization and social software will radically change the team structures. Project teams will be scattered across the globe. Rising oil prices will lead to more virtual offices. Ten years from now we will look back and laugh at the notion of cramming hundreds of people into cubes. Companies will be able to hire staff from around the globe and won't be restricted to local markets. Users will have the power to assemble their own applications by leveraging mashups and software in the cloud. How will we manage the future?

IT Leaders need to change with the times
So what does this all mean? When you add up all of the things I just mentioned, the role of management has become far more demanding. If your managers are struggling today, how will they survive tomorrow? Just think of the cultural and ethical ramifications of managing a remote team of workers from around the world. IT leadership will be even more demanding then it already is and we already have a shortage of leaders who excel in all three areas of the leadership triangle. So how will we solve this dilemma? Currently, many IT shops just "stay the course" and do not adopt any of these large enterprise initiatives. In the future as cost reduction becomes a matter of survival, many of these initiatives won't be optional.

Unfortunately, I don't know the answer to my own question. There is already a skills shortage in IT across the board. There isn't a shortage of people applying for management and leadership positions, but there sure is a shortage of people who are qualified! Where will the next generation of leaders come from? How many companies will recognize the importance of the leadership triangle? How many more IT projects will fail before somebody does something about this dilemma?

What do you think needs to be done? How will we overcome the Leadership shortage?

I stumbled across a video blogging website called Seesmic today. I spent several days at the Gartner AADI conference in Orlando this week and created the following video summing up my thoughts about cloud computing and Platform as a Service (PaaS).



In summary, cloud computing and PaaS are emerging technologies that will drastically change IT over the next few years. IT Leaders need to get better at organizational change management or these initiatives will fail.

Please provide me with some feedback. I want to know if this type of content has any value.

In response to the recent surge of bad publicity that SOA has received, I have been screaming from my soapbox that SOA is the real deal, it's just the people who keep screwing it up. I offered my recipe for success and my ideas about change management. As I look back at my SOA journey, I identified one new role that I would add if I ever get an opportunity to lead another SOA initiative. That role is an Organization Change Management (OCM) specialist.

What is the OCM Role?
The OCM role is critical to the success of any large scale culture changing initiative. This person is responsible for accessing the readiness of the organization to change and then creating a change management strategy to help the organization transition from its current state to the desired future state. Developing a communication plan is also a key deliverable. People at all levels of the organization need to receive frequent communications of the impact of change, when the change is coming, what it means to them, how their jobs will be impacted, what the deliverables are, what training they will receive, and when will it be delivered. To make matters more challenging, each layer within the organization will need this information in a way that makes sense to them. For example, developers will want the low level detail, the business will want it in business terms, the financial people want it in dollars and cents, and senior management want an executive summary. There is no one communication fits all.

Then there is the skills assessment. What skills do we need? What can we address with training and what do we need to go outside for? Do we need to change our incentives and rewards programs, our recruiting process, our software development life cycle process, etc.? Does our existing job titles and pay scales make sense for the skills we need?

You can see that from this list of questions the scope of this role is more public relations (PR) and human resources (HR) then it is architecture.

Who fills this role?
There are a few options. This can be filled internally by an executive sponsor, an HR generalist, or even a project manager. However, only fill this internally if the person has clout and is near 100% dedicated to the project. If they have another day job then don't bother. External resources are also an option. This has many benefits. First, you can get someone who lives and breaths change management and has been through many of these types of initiatives before. Why reinvent the wheel and learn this from scratch when there are experts in the field. Second, the hours needed each week may fluctuate. You may need 40 hours one week and 20 the next. With an external resource you can pay only for the hours you need. Third, it is advantageous to have a fresh perspective from an outsider who is not tied to existing processes and cultural barriers. Fourth, this person can give candid feedback to the higher ups without worrying about getting fired. For example, let's say a senior executive is not pulling his or her weight in one area of the project. The consultant can confront that person and in extreme cases go above that person to provide feedback without worrying about their next pay check.

What are the benefits?
Investing time and money in change management can make or break a project. In my case, several of us took on various tasks in this area, but collectively we did not have sufficient time to communicate at the level we needed to. Some areas we didn't even get a chance to address. Leveraging an OCM specialist greatly improves communication, addresses project risks, helps people adjust to change, and greatly reduces resistance. You can survive without this role, but it will be much harder, cost more, and take longer due to resistance to change and communication gaps. Take it from someone who has spent the last two years fighting the good fight, change is good, but dedicated change management specialists are better.

There are many critical success factors for implementing SOA. They range from strong executive sponsorship and business alignment to acquiring the proper talent and implementing the right amount of governance. But even if you have all of those ducks in a row, it all comes down to the basics of project management and leadership. The biggest challenges that I see implementing SOA are the same challenges that I have seen throughout my career implementing any other large initiative. This article called Avoiding Project Failure: It's not Rocket Science, gives an overview of the things that typically go wrong:

Typical problems here are scope creep, poor work-plan, lack of change control, poor communication and poor management of risks and issues.

The article goes on to state a few more killers:

There are many occasions during the lifecycle of a project for issues that may lead to failure. Examples of these include:

• Failure to define the requirements clearly, resulting in expectations not being met
• Cutting edge or new technology that causes unforeseen problems
• A poor technical design preventing the solution from being changed or scaled in the future
• Poor change control allowing change requests to cause the project to drift
• Changing priorities diverting attention away from core work

Since implementing SOA can be a culture changing event, the basic change management principles must be applied to prevent derailing the entire initiative. Here is a summary of the high points of this article:

1. Address the human-side systematically
   
2. Top level support
3. Involve every layer
4. Clearly communicate the business case
5. Create ownership, install change agents
6. Clearly and continually communicate the message
7. Assess the cultural impacts
8. Address cultural issues
9. Prepare for the unexpected
10. Define WIIFM (What's in it for me?) for each individual

I know that early in my SOA initiative, I spent most of my time digging into the technology. Once we defined what our target architecture was going to be, my role changed dramatically. I turned most of my architecture duties over to my enterprise architects and started focusing my energy on the project deliverables and the change management. I can tell you from personal experience that figuring out the target architecture was a cakewalk compared to what I am dealing with now.

So while many people lose sleep over the technical challenges of SOA, I stay awake at night worrying about scope creep, top level support, cultural issues, risk lists, and action items. If I put enough smart people in a "war room" I know we can tackle any technology problem, but coordinating the work of all these people is where the challenge is. The big challenge in my eyes is that SOA forces many different departments (inside and outside of IT) to work together as one cohesive team. This is not a technology issue, it is a people issue. So for those of you early on in your quest for SOA, don't under estimate the importance of project management and change management.

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.

I have been blogging about my SOA & BPM implementation for the past few months. My earlier posts talked about how we sold SOA to the business, the vendor evaluation process, and our bottom up approach. We have been partnering with a SOA implementation consulting company for the past 10 weeks practicing an agile approach to delivery. In this short time frame we have installed our stack (BPMS, ESB, Data Services) and built a beta version of a B2B portal. Life is good!

So why can't I sleep at night? Because I have only a few months to ramp my organization up to take this over from our consulting partners. This may be the biggest challenge of implementing SOA that we have faced so far! We have formed a business process management organization in the business and hired our first Process Analyst. I feel good about that. We created a team of architects including a testing architect to help build out and govern the architecture. I feel good about that. We have access to network and hardware architects and moved someone into the role of administering the stack. Real happy there! But that was the easy part.

The hard part will be getting the rest of the organization on board with SOA. There are numerous challenges. First, SOA introduces numerous new roles and responsibilities for our staff. We will have to move from being SMEs (subject matter experts) in an application to becoming SMEs in a layer of the architecture (see chart below)
Second, we are moving away from our current methodology which is slightly waterfall in nature to a more agile and iterative approach. We are currently ramping up to implement our governance model.

But the biggest challenge is organizational change management. SOA concepts are drastically different then the way we currently develop applications. We are moving away from thinking about stovepipe applications and moving towards building business services. We still have some legacy apps that are written in VB6. For the folks maintaining those apps, they have not been exposed to web services yet. The world of testing changes drastically with this layered and loosely coupled approach. The DBAs now need to create a logical representation of data to hide the complexity of the joins and relationships from the services. The business analysts role is practically a different skill set now. Traditionally, our project managers have been assigned to applications and work side by side with the development manager who has a fixed team of resources. With SOA, we are moving more towards the classic PM role where the PM drafts a team from a pool of resources. I could go on and on.

So as you can see, every single person's role is changing. At the same time, we have a third party who is cranking out code faster then we ever dreamed of. We are unintentionally setting an expectation that we will be able to move this fast once we take this over. We are not getting incremental head count so we need to figure out how to transform our existing staff from application SMEs to specialists within the architecture over the next few months.

Anyone who has been responsible for managing culture changing initiatives understands the challenges that this presents. For each individual, we must answer WIIFM (what's in it for me) , how will this help the business, what's wrong with the way we do it now, and many other questions that cause resistance when left unanswered. At the same time we need to quickly educate everyone on SOA. Meanwhile, everyone has a current full time job and are assigned to existing projects.

A while back I wrote an article about the role of the enterprise architect. Many people only consider the technology side of the equation. There are days where I don't even have time to deal with technology. Some days are spent evangelizing to create more buy-in throughout the organization. Other days are spent working with business owners on a plan to reprioritize projects to free resources up to work on our SOA initiatives. And even more days are spent working with the development managers on plans to free up resources for temporary assignments (learning opportunities) on SOA projects.

So as we continue down the road with our SOA implementation, I have discovered that the most challenging part of the project thus far is adapting to change. The technology part seems easy compared to this. I will write more about this as we work through future opportunities and challenges.

In part 1 of this series I asked the question, "Are you running IT like it's your business?" Then I highlighted five 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

In part 5, I will focus on Lack of Process.

Many people in IT think of process as paperwork, overhead, or even a total waste of time. I have seen some processes that fit those descriptions. But in those cases, somebody implemented processes for the sake of having processes instead of implementing a set of processes that help IT deliver quality software and services.

Companies with no processes or ineffective processes have the following issues:

1. Reactive mode, constant firefighting
2. Consistently deliver late and over budget
3. Sweat shop mentality, working hard instead of smart
   
4. Low morale
5. High turnover

All five of these issues are extremely expensive. If you owned your own company and it had these issues would you ignore them? Many IT shops that have these issues look to offshoring as the answer. Can you say doomed? If you can't manage your own internal resources and projects, what makes you think you can manage a group of people in another country? Even if you pick the best offshore resources in the world, the overall success of your projects still rely on your ability to manage them. In other words, it depends on your processes.

There are many types of processes and methodologies that are proven. They range from strict methodologies like CMM and its 5 levels to Agile Methodologies and Extreme Programming (XP). The proper methodology depends on your company culture, your products and services, and your budget. If you are sending a man to the moon, you should use a very strict methodology like CMM. When lives are on the line or millions of dollars are at stake then no short cuts should be taken. If you are implementing infrastructure projects then the PMI methodologies can be a good fit. They provide a good step by step or check list approach that helps you assure that you have not missed a step. If you are delivering applications on the web or providing features for internal or external customers then you probably want speed and that is where Agile and XP come in. With these methodologies, you want to iterate through all phases and deliver in quick intervals. These methodologies focus on getting the right features into the hands of the users quickly and discourage trying to anticipate every user need.

But process isn't just about delivering new software and services. Project prioritization and production support are two critical areas that need to be managed effectively. If either of these two areas are not under control, your chances of success are greatly diminished. Here are the effects of not having a good prioritization process:

1. Over allocation of resources
2. Not working on the most important projects
3. Constant changing of direction, lack of focus
4. Frequently run over budget and delivering late

Here are the effects of not having effective processes to manage production support:

1. Putting out the same fires on a daily business
2. Poor quality applications due to constant patching
3. Poor customer satisfaction
4. Low morale and burn out
5. IT unable to launch strategic initiatives due to high cost and resource constraints
   

So what should you do? Two things. First, implement portfolio management. I wrote an article that could help you get started quickly. Second, look at implementing change management or service management best practices like ITIL or Cobit. By using the best practices for managing change and support, you can reduce your costs, improve your quality, and free up resources to work on high priority projects.

I grew up in a family business and brought the entrepreneurial spirit with me into corporate America. I struggle to accept how some IT leaders do not manage IT like it is their own family business. These leaders are smart people (usually) and I know that they would be taking a different course of action if it was their own family fortune that was on the line. For you IT leaders that live in the world of chaos and firefighting like I have described throughout this series, if you won't drive change for your company, consider doing it for your people. Working hard instead of smart is not what we all envisioned when entered the exciting world of computer science.

This wraps up the 5 part series on running IT like it's your business. I will follow up with a conclusion that discusses how to implement some of these initiatives. Thanks to those of you who have stayed with me for this long series. Please provide some feedback. I would be happy to clarify any points or dive deeper into any topic.

In part 1 of this series I asked the question, "Are you running IT like it's your business?" Then I highlighted five 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

In part 2 I will focus on Lack of Resources.

What are some of the most common phrases you hear when attempting to promote change within your organization? The top one I hear is "I don't have time", followed by "I don't have money", followed by "I need more resources". These are the biggest cop outs in the world. The reason why nobody has time, money, or resources is because they don't put any initiatives in place that allow them to do anything other then put fires out.

At some point you should reach a threshold of pain and realize that there must be a better way. Everybody is working 50-60 hours, all the projects are late, production support continues to increase, and the users are screaming. Everybody is working hard, but nobody is working smart.

If this sounds like your shop, you might want to take a step back and put a plan together to stop the madness. If you owned your own trucking business and you spent most of your time repairing your fleet of trucks you would probably be out of business. So why do so many IT shops spend countless hours every day in repair mode? It's time to make time, time to spend your shareholders' dollars effectively, and time to maximize your precious resources.

Let's start with time. Where are you spending your time? Do you have any metrics that allows you to proactively manage and control your projects or your production support? In many shops, the main cause of all these issues is lack of a sound project prioritization process coupled with a lack of a resource allocation model. If projects get accepted at will, priorities change like the seasons, and you have no data to show that your resources are over allocated, you will become a reactive culture. If you are not practicing Portfolio Management, you should make that a priority (view this article I wrote on Portfolio Management). If you have no visibility into how much time you are spending in production support, what categories of issues you are encountering, and how long it takes to fix issues then you should make change management a priority. If you are meeting with the business to discuss the next wave of new projects and do not have a clear picture of your resource capacity, you need to start practicing human resource planning.

Next is money. Obviously, if you are spending too much time keeping the lights on then you are wasting money. But are you wasting money on infrastructure? Are you still pouring millions of dollars into big name vendors like Microsoft, IBM, Oracle, and HP? Are you paying huge amounts of money for "Gold Support"? You need to start evaluating Open Source alternatives. If you believe in the myths of Open Source, it's time you start doing your homework and read about these 50 Open Source success stories. Oh, and that Gold Support you are paying for each and every product...there are many Open Source Support Providers who can support a variety of open source products at a fraction of the cost. What is better is that these folks earn their stripes supporting customers and are actually extremely interested in helping you resolve your issues. This is their core competency. I wonder how much effort Big Blue would put forth to help a small $100M company resolve its problems. The days of saying, "Nobody every lost their job buying Microsoft and IBM" are long gone. If that is all you are buying you are definitely not seeing the big picture and your CEO might start giving you that look.

Are you still buying rack after rack of servers to support your test, development, staging, and production environments? Have you embraced Virtualization Software like VMWare yet?

And what about human capital? We already talked about spending too much time keeping the lights on and spending too much time maintaining rack after rack of servers. But what about development and testing? Do you have an architecture that allows rapid deployment and reusability? Have you separated your business rules from your applications? If your business rules are embedded in your applications then you are creating additional work to maintain and test your applications thus increasing your chances of creating defects.

Let's say you are a retailer with 1000 stores and you have a business rule for defining what a high volume store is. You have several different systems that use this business rule (billing, inventory, eCommerce site, financials, etc.). Now you want to change the definition of a high volume store. You now have to make that change in each of these systems and implement all of the systems at the same time. This simple change has turned into a project. Wouldn't it be better to go to one place, make the change, test it in one place, and roll? You don't need to practice agile methodologies to be agile. You just need to be smart! My recommendation is invest in your architecture. Create a business rule layer that sits between your applications and your presentation layer. I would go one step further and create a service layer to orchestrate your business rules and allow other applications and/or customers to access your business rules.

Well, I have rambled a lot longer then I usually do so I will pause until part 3 which focuses on Lack of Tools. I will add a conclusion after part 5 that tells you how to prioritize these initiatives and how to get started.

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.

A good buddy of mine forwarded me this article from eWeek by Deborah Perelman. The following quote from the article summarizes the content: “In the simplest terms: too many IT workplaces have become Dilbert-ized—micromanaged, bureaucratic and stifled creatively. It's become an environment where busy work is praised and morale is low.” The article talks about IT as a commodity with trends in outsourcing. Flextronics CEO, Michael Marks, goes one step further in this Businessweek Online article Design is a Commodity. He recommends outsourcing the engineering process for electronics.

How did we get here? In my opinion, IT has done this to itself through the years due to the following reasons:

1) Not working closely with the business

2) Inability to successfully manage projects

Let’s talk about the first point. In the 60’s and 70’s, the business was dependent on IT for information. There were no high powered PCs and the Internet was not for commercial use. Most of what IT worked on in the public sector was business enabling applications. During the 80’s and 90’s, huge advancements in processor speed, memory, and disk technology enabled personal computers to do the work of the massive mainframes from the previous decades. Then the internet came of age which changed the way people and businesses interact with one another. These two important technology advancements changed business for the better but not without consequences. The days of IT being in control with centralized and reliable systems gave way to the complex, distributed, and multi platform environments that we live in today. This in turn, directed a lot of IT’s attention towards infrastructure projects. In today’s world, a large portion of IT budgets go into projects and services that keep the lights on for the company (email, voice & telecommunications, security, compliance, etc.) and do not contribute to additional revenue. In addition, software vendors started delivering shrink wrapped solutions (ERP, CRM, Financial applications, etc.) that was not feasible for companies to build internally. I believe these factors have all contributed to the fact that many IT shops have become disconnected and/or out of touch or alignment with the business. IT has become perceived more as a cost center then an enabler. Employees have become known as what Catbert calls “Headcount”.

Point #2. The PMI Institute states that 72% of IT projects they studied were late, over budget, lacking functionality, or never delivered. Of the 28% “successful” projects, 45% were over budget and 68% took longer then planned. These numbers are frightening! Lack of project management best practices have caused many companies to lose faith in IT. Many business units have started buying their own software packages or paying outside vendors to solve their business problems. This is another reason why IT and the business have become unaligned.

When a company views IT as an expense and not as an enabler, the IT shop becomes a poster child for Dilbert cartoons. Companies tend to look for ways to reduce or eliminate expenses. Once you view your employees as “headcount”, the creativity, passion, and drive gets drained right out of you.

So is IT doomed? Many experts believe that in order for companies to stay competitive and survive in the upcoming years, IT needs to focus on business processes. In the article, The How, Why, and Where of Future I.T., Mark Gibb’s states that, “I.T. has to be able to show that it delivers a real return on investment.” To accomplish that, I believe that IT should start embracing:

1) Project management – to improve delivery and communication

2) Portfolio management – to maximize IT investments, align priorities w/business, and control workloads

3) Business process management – to optimize and automate business processes

4) Enterprise architecture – to align technology with corporate goals and strategies

5) Change management - to manage change and impacts on people and processes

6) Agile development – to deliver value early and often

What are your thoughts?

I am beginning a long journey to implement both a BPMS and SOA solution at work. What I am finding out is that the technology is the easy part (and it is not all that easy). The real key to success is change management. The reason I say that is when I list out and rank the barriers to success, the top 5 are not related to technology. Number one: Resistance to change. Number 2: Becoming a process centric culture. Number 3: Governance. Number 4: Conflicting project priorities. Number 5: Lack of in-house skills.

If you look at this list you can see that all of these issues are related to people and processes. Change management, by definition, is managing the human aspects of change. The 5 barriers I listed are all issues that need to be addressed by either changing the culture, changing the organization structure or processes, or by training people. If we don't address all of these issues up front, then our chance of success is greatly reduced.

I am confident that we will successfully tackle the technical challenges, but we will need some help with the big 5! Any advice would be greatly appreciated.