Enterprise Initiatives

An article written by Joe McKendrick called SOA eased the way for recent shotgun financial mergers inspired me to take this discussion one step further. To me, the biggest benefit of SOA done right is agility. I define agility in IT as the ability to adapt to change at the speed of business. Companies that invest in architecture, specifically in SOA, are in a much better position to adapt to mergers and acquisitions, connect to partners and suppliers, take on new business opportunities, and continually drive down the costs of maintenance and support.

I read many blogs and subscribe to numerous group discussions on SOA, EA, and cloud computing. There is so much discussion arguing the semantics, the ROI, and the viability of these technologies/architectures that it sometimes becomes discouraging. At some point we need to hike up our boot straps and invest in our business's future and stop fire fighting. Those companies that invest now (and do it right) will create a competitive advantage over those that do not. Here are just a few of the harsh realities that our businesses are faced with:

• Decreasing margins
• Fierce global competition
• Mergers/ Acquisitions/ Consolidations
• Recession
• Demanding, connected, and empowered consumers
• Increased regulatory constraints
• Dynamic business requirements
• Green initiatives

All of these things mentioned above are issues that we must deal with on top of our company specific issues and requirements that are far exceeding our capacity. To keep up with demand we need a flexible and agile architecture so we can make configuration changes instead of code changes, empower business users to change business rules instead of requesting expensive development projects, and leverage partner and supplier services instead of building everything from scratch, thus reinventing the wheel.

IT is only a cost center if the IT leadership allows it to be. The role of IT should be to innovate and help the business achieve its goals. IT must invest in strategies and architecture to allow this to happen. It is too easy to say we don't have the time, resources, and money. That's a cop out. As I have said before in my article The keeping the lights on mentality

The key business driver in a "keeping the lights on" shop is minimizing costs (usually over anything else). Which makes me wonder why more shops in this mode do not go down the outsource IT path. If lower cost is so important and large innovative initiatives are typically out of the question, why not radically lower the cost by outsourcing IT? I am not recommending that IT shops do this, instead I recommend that IT shops become good business partners and enablers of business success. But if I was a CEO or CFO and my IT's sole purpose was to be a cost center to keep the lights on, I would try to drastically reduce that cost. After all, keeping the lights on is not a core competency of most businesses. It is a necessary evil. Having hordes of full time staffers and paying for their benefits, stock options, and bonuses just to keep the lights on is not smart business. I know my view here will not be popular with most IT folks. I am not down playing anybody's abilities here. All I am saying is that if we don't need our staffs to be innovative, proactive, and be advocates of our business partners and instead just want to the staff to think short term, there is a much cheaper model out there.

So IT leaders have a choice. They can refuse to invest in SOA and continue to support and maintain an inflexible environment that takes a lot of time and money to change or they can invest in the future by justifying an initiative to provide the business with flexibility, agility, and empowerment. Is it easy to do? Heck no! It requires talented staff and partners and most of all top level support. Ask yourself this question. If your company was to merge with your number one competitor tomorrow, how long do you think it would take to integrate these systems? If your competitor was buying your company and your systems were archaic and hard to integrate with, what do you think the odds are that they would keep you around? That's what I thought! Pay now or pay for it forever.

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 just read Dave Linthicum's post on SOA World titled Should you Fire your CIO? This is a continuation of a discussion that has been brewing in the blogsphere for the past few months that started after the Burton Group commented that a new CIO was often a key ingredient for some successful SOA implementations.

To successfully implement enterprise wide SOA initiatives, strong leadership is required at the top of IT. The person must have integrity, creditability, technical and business know how, and must be able to lead the organization through the resulting shifts in cultural values. The problem is, as Dave points out in his article....

....in many organizations the role of CIO has resolved itself as the person who keeps things running, not the agent of change.

I call this the old "Keeping the Lights on Mentality". When IT stops being an enabler and simply acts as a cost center or a "necessary evil", then entertaining new projects that leverage one of Gartner Top 10 strategic technologies is unrealistic and doomed for failure or hardship at a minimum. Why? Because this mentality is reactive and sometimes even defensive. This mentality also does not encourage investing in the future whether that is in training employees, establishing and investing in architecture, or addressing problems with long term solutions. Instead, people are rewarded for quick fix fire fighting heroics and at the end of the day it is the user community that suffers. The users get band-aids on top of already outdated systems and are often forced to work in ways in which the technology and systems dictate, instead of the other way around.

It gets worse for the employees in an IT department in charge of "keeping the lights on". Their resumes become stale as their skills are not updated to reflect the newer technologies that innovative companies seek. The reactive nature of the culture can squash innovation and people who have valid solutions may not bring them forward because it would require more than a quick fix. In the end these types of shops become like an assembly line in nature where people clock in, work their shift, and clock out. This is not what must of us envisioned when we enthusiastically enrolled in IT related curriculums in college back in the day.

The key business driver in a "keeping the lights on" shop is minimizing costs (usually over anything else). Which makes me wonder why more shops in this mode do not go down the outsource IT path. If lower cost is so important and large innovative initiatives are typically out of the question, why not radically lower the cost by outsourcing IT? I am not recommending that IT shops do this, instead I recommend that IT shops become good business partners and enablers of business success. But if I was a CEO or CFO and my IT's sole purpose was to be a cost center to keep the lights on, I would try to drastically reduce that cost. After all, keeping the lights on is not a core competency of most businesses. It is a necessary evil. Having hordes of full time staffers and paying for their benefits, stock options, and bonuses just to keep the lights on is not smart business. I know my view here will not be popular with most IT folks. I am not down playing anybody's abilities here. All I am saying is that if we don't need our staffs to be innovative, proactive, and be advocates of our business partners and instead just want to the staff to think short term, there is a much cheaper model out there.

So to answer Dave's question, if the business wants IT to help the business achieve its mission by being proactive and innovative and IT is simply keeping the lights on, the answer to his question might be yes. If the business simply needs a low cost IT cost center, the answer may be to evaluate the outsourcing model. Keeping the lights on as a core IT function and doing it at a high cost is just not good business. That's my 2 cents.

Disclaimer: In no way is this article referring to or targeting any organization or individual that I have been associated with in my career. This is a generalized view that combines my own experiences with the experiences of thousands of other IT professionals that I have talked to, read about, or researched throughout my 20+ years in IT.

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.

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?

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.

A few years back, many "experts" were telling us to build systems to last. Fast forward to 2007 and the message is clear: Build to Change!

In the age of the ever demanding users, requirements change quicker then the ink dries on your last requirements document. In the days of "Build to Last" we would anticipate every users' needs and build the "ultimate" solution so that we would not have to spend a fortune maintaining it. The end result, we built more stuff to maintain then we should have.

Taking the Build to Last approach is like buying your 4 year old adult clothes hoping that they grow into it. Technology is changing so rapidly you can't possibly anticipate user needs. Take the IPod for example. Do you think that you have purchased your last MP3 player when you bought your Nano? Did you realize that in 3-5 years a hard disk will be a thing of the past like my old 8-track player. 3-5 years from now you will be laughing about only being able to store 4000 songs on your IPod and you actually had to burn songs to disk instead of virtualizing them in memory. In fact, the only device you will carry will be a phone and it will be your debit card, MP3 player, mobile computer, and much more.

So, my point is, don't try to think too far out in the future because the future will be totally different. Build to Change and move towards a service oriented architecture. That way, when the technology changes, your business processes and rules can easily adapt to the new and emerging technologies of tomorrow.