Enterprise Initiatives

Day 2 of the LZA Bootcamp proved to be another solid day packed with great information about SOA. Today we covered abstraction, SOA and legacy systems, data services, XML, and security.

Here are some of the key take aways:

Abstraction - The business doesn't care how the service is built or where it is located. All that matters is that it works. Business services abstract both data and application functionality.

Legacy - SOA impacts Legacy in three ways.

1. Migration - You can use SOA to migrate off of legacy by abstracting the interfaces and then gradually replacing the pieces on the backend.
2. Enablement - Expose legacy capabilities and data as services.
3. Rejuvenation - Leverage legacy as an active SOA participant. This is common with mainframe systems today. Many companies have fully functional mainframe systems that need to be connected with each other and presented with new rich interfaces.

Data Services - One of the biggest problems integrating systems is dealing with data issues across systems. abstracting data as a service allows you to hide the complexity of the physical implementation of data from the other layers. Here is an example of its use. Let's say you have four different sources of the same data entity that has four different data structures and leverages four different technologies. The data service layer hides all of this from business services. Then let's say you have a goal to reduce the data sources down to a single source. If your business services are calling a data service that represents the logical representation of the data, then you can eliminate the other three data sources without making a change to your business service. In other words, your business service does not care how or where your data is stored.

XML - XML allows for standardization and maximum flexibility, but it sacrifices performance. XML is a widely accepted standard and leveraging it gives you the ability to connect more easily with external services. However, since XML contains huge amounts of metadata and is Ascii, it can consume large amounts of network bandwidth. This can be addressed with hardware and software solutions that compress and accelerate XML messages.

Security - SOA increases the risk of security breaches. In addition to the normal dangers (SQL injection, denial of service, buffer overflow, and trojan horse), XML adds XML injection, WSDL scanning, schema poisoning, and other threats. In the traditional distributed computing world, systems were closed and API's were proprietary. With SOA, we have open systems and distributed APIs. A much larger effort is required by architects to keep the "bad guys" out.

Day three focuses on governance and funding. I'll be back tomorrow for a quick recap on those topics. Here is the recap from day 1.

My company is hosting the current Zapthink LZA SOA Bootcamp this week. We have a mixture of attendees from various government agencies, consulting companies, and from the marketing and advertising industry. The class is being taught by Jason Bloomberg from Zapthink who knows SOA inside and out. I highly recommend this class for any company who is trying to implement SOA.

Day 1 was focused on the fundamentals of SOA and service-oriented analysis and design. I'll highlight some of the key take aways below.

Companies require agility. IT needs to respond faster to change. We must architect to change.

The reason for architecture is to support the problems of the business. In my opinion, many times architecture focuses solely on IT and forgets that we are here to enable the business to meet its objectives.

Service Oriented is a business concept. Many people think SOA is all about connecting things. SOA is really all about enabling flexible business processes and providing agility.

SOA is architecture. You can not buy SOA, you do SOA! It is a set of best practices and the discipline to follow them. SOA is all about abstraction and creating loosely coupled business services. These services should be interoperable, unbreakable, reusable, and composable.

SOA is not Web Services and Web Services are not SOA. SOA is an architectural approach while web services are a standards based interface. You can do SOA without web services.

SOA is distributed computing. SOA shifts us towards decentralization and empowers the business. It simplifies things for the business but greatly increases the complexity for IT. IT can no longer ignore governance if it wants to successfully implement SOA.

SOA doesn't replace anything, it extends it. The beauty that I see in SOA is its tie to BPM. I can deploy a brand new workflow driven, composite user interface that leverages SOA to extend the life and value of years of legacy systems, without having to spend years rearchitecting fully depreciated and working systems. In other words, I can provide the business with more modern tools and optimized workflow without blowing up my existing systems.

SOA is not about portability, it is about interoperability - If your implementation is dictating a certain technology, then you are not doing SOA. You must think in terms of the business. The business doesn't care if the you use Java or .Net, the business only cares that it works. You must architect the business service in a way that the underlying technology does not matter. Changing the underlying technology should not impact the business services. Think of the universal remote control. You can program it to work on any brand and on multiple devices (TV, VCR, DVD, CD, Home Theather, etc.). The remote control has no idea how the technology is physically implemented or even what it looks like. It does know how to send messages back and forth to the devices.

SOA is declarative not programmatic. This means that the business logic is configurable as opposed to being hard coded. SOA provides the ultimate flexibility and agility.

SOA supports business goals. With this mindset, software plays the supporting role as opposed to dictating how the business works (ie. SAP, PeopleSoft, etc.).

BPM is the killer app. You can't do BPM without SOA and visa versa. Integration is a side effect of enabling business processes.

This summary is just a fraction of the wealth of information that was shared today. In addition to the great lecture and corresponding slides, the class had numerous group exercises that allowed the different companies to share their personal experiences from their SOA projects. These experiences were just as valuable as the presentation. All in all it was a very productive first day!

Thanks to Joe McKendrick I found a great post on the Financial Times by Kaushal Mashruwala called SOA strategy and execution is failing in many companies. The article discusses how companies are struggling with the value proposition of SOA and how the business tends to shy away from the next big IT buzzword.

One key reason is that the SOA value proposition is fundamentally unimportant to business people. It’s just another way to implement an application.

The article goes on to recommend combining BPM with SOA to give real value to the business.

Give business people a reason to care about SOA—give them BPM. It gives many businesses an approach that balances the architectural benefits of SOA against the cultural shift that business people are demanding.

I have been singing this tune for quite some time now (Selling SOA to the business). Many fellow EA bloggers called me out on my article saying that it does not make sense to talk to the business about SOA and that Top Down SOA is the only way to go. I disagree. There is no single way or silver bullet for delivering SOA as I mentioned in SOA Theory vs. Reality. I sold the business on SOA by explaining to them in business terms how SOA is the technology that enables BPM. The business understands BPM and how process reengineering and optimization can eliminate waste, improve customer and employee satisfaction, and provide visibility into the the state and health of business processes.

As a matter of fact, we were so successful in selling BPM with SOA that when the CEO announced the top 5 initiatives for the next three years, Business Processing Reengineering made the list. The company is now investing in training, tools, and various key initiatives which will leverage BPM and SOA. Without the link to BPM, none of this would have been possible. Like Kaushal mentions at the end of his post, if we had not combined BPM with SOA, our SOA would be SOL!

I will be sharing our story at Zapthink's Practical SOA conference next month.

As I mentioned in the past, I contribute to the Open Office project in the area of marketing. I found this great post today about switching to Office and I thought I'd pass it along.

read more | digg story

I will be giving a presentation at Zapthink's Practical SOA event in New Jersey on March 25. If you are attending the conference feel free to drop me a note if you would like to meet and discuss technology. I will be discussing how IT was able to convince the business to take on and fund a large BPM/SOA initiative and how it is transforming the company. If you haven't already registered for the event you can do so by clicking here.

My company is also hosting the next Licensed Zapthink Architect (LZA) Boot Camp in St. Petersburg, FL next week from 2/26-2/29. There are still a few spots available but hurry because they are filling up fast. Here is the link to the agenda. I recommend the Hilton which is in walking distance from the facilities.

I wrote a post several months ago called Tighter budgets mean more Open Source proclaiming that when budgets tighten up, more people look towards open source to get the tools they need to get their jobs done. Now we are in a recession and IT budgets across the globe are extremely constrained. Meanwhile, the amount of work we are being asked to produce is growing exponentially. We need to deliver faster, with more modern features, yet we have limited resources to meet these expectations. The smart folks who have already been leveraging open source software (OSS) have the edge.

When budgets were good, people who couldn't get over their perceptions of the pitfalls of OSS could easily turn the other way and continue to spend hundreds of thousands if not millions of shareholder dollars on commercial software without even evaluating OSS alternatives. Now, many of these same people are "opening their minds" because their budgets are limiting their ability to cozy up with their favorite vendors.

My company has already replaced a few commercial products with OSS. Recently our version control software was up for maintenance renewal and required an upgrade to a new version. We were already ready to move on to a different tool so we evaluated Microsoft Team Foundation Server and an popular open source alternative called Subversion (we are a Microsoft and Java shop). The Microsoft product was nice but was expensive and very proprietary. Subversion is free and we are able to use it consistently across both development platforms. We also use CruiseControl for the continuous build process that we implemented. These two tools have greatly enhanced our productivity for both the Java and Microsoft developers and did not add a single penny to my budget. No annual maintenance fees, no vendor lock in, no problem!

Last year we purchased a variety of tools in the SOA stack (BPM, ESB, Data Services). This year we needed to add several additional tools to assist the developers and testers. Here is a short list:

• Registry
• Repository
• SOA testing tools
• Run time governance

We have found very impressive open source alternatives to each tool in the list except for the run time governance (although we are still researching this one). It does look like the Mule project will be adding many tools in support of SOA in the near future. Centrasite has a good registry/repository tool and Testmaker is our leading test tool right now. We evaluated commercial products from Mercury, iTKO, BEA, and many others. All of them have outstanding tools but when you add the tools up for these four areas you quickly get a price tag around $1M plus annual maintenance.

We have also implemented some web 2.0 technologies and leveraged two popular OSS solutions. Mediawiki is our enterprise wiki solution. This is the same software that powers Wikipedia. We also use Wordpress for our internal blogging initiative that is starting to draw a lot of traffic. I am also testing Twitter and Bebo to see if social networking/messaging has any value at our corporation. Most of the top Web 2.0 software are open source products. It will be hard to justify spending tons of money on Web 2.0 software when the most popular tools are free and scale to support millions of users.

I believe that as the recession continues, more IT leaders will look at open source then ever before. Many will like what they find when they do their due diligence. Once they have success with one or two tools, they will no longer need a recession to evaluate OSS. For those companies that have a formal vendor evaluation process, make sure you update your process to include open source products. Just because Gartner and Forrester do not have OSS in their Magic Quadrant or Wave, doesn't mean that you shouldn't be evaluating OSS. Many OSS projects have become so dominant that they are being purchased by major vendors. Sun's purchase of MySQL is a recent example of this. As a matter of fact, OSS is becoming so mainstream that Gartner predicts 80% of all commercial apps will leverage open source by 2012. If vendors are leveraging OSS, why are some companies refusing to do so? I'll leave you with a good post from Matt Asay on CNet - Open source and the future of vendor-free IT.

I just read an entertaining post from Dave Linthicum called Do you Have a DSG (Dumb SOA Guy) Issue? A DSG refers to a person leading the SOA effort who has the political clout but has no clue what SOA is. If you have one of these, you could be in for a long painful and expensive journey. Here is a key point from the article:

Again, the technology around SOA is simple, and I never worry about how we're going to leverage technology to solve a problem. However, the people issues are more concerning and more difficult to fix.

My head was nodding when I read this. I can tell you from experience over the last 18 months that the hard part is culture change, change management, and establishing governance. If you have a few smart architects and a good implementation partner like I have, the technology part can be easily conquered. The hardest part I have experienced from the technology standpoint is getting all of the tools in the stack completely integrated and stable. But even these issues are a one time hit that you have to deal with on your first implementation.

Back to the DSGs. The person leading the SOA initiative needs to be strong in the following areas:

1. Technology - must understand SOA at a conceptual level or better
2. Political Clout - must have a high level of influence to remove roadblocks
   
3. Business - must align technically with business drivers
   
4. People Skills - must know how to motivate and direct people

If your DSG is lacking in any one of those four areas, your SOA initiative's chance of success will decrease dramatically. If your DSG is lacking in more then one area, cancel the project now or get a new DSG!

I have been experimenting with a few Web 2.0 tools at work over the last few months. We are working on a big BPM/SOA initiative and are trying to find better ways to communicate what we are doing to a very large audience. Email is becoming more and more useless everyday as a tool for information sharing. We are using a combination of Blogs and a Wiki to improve collaboration and knowledge sharing. We are also formalizing our SOA governance processes. A small team of about eight people are working on defining and publishing certain processes and standards. This effort requires a great deal of collaboration and in an effort to "eat our dog food" we will rely solely on our Web 2.0 tools to carry out the collaboration. No email allowed on this initiative!!!

After reading many interesting blogs recently and seeing how other companies like IBM are starting to leverage these tools, I am going to take my experiment to the next level. Up next, Twitter. When I first heard about Twitter a year ago, I couldn't understand how it would be useful for me at work. I could see the momentum building as more and more people starting signing up for this free service which led me to believe that it would eventually find its way into corporations.

In my role as the chief architect, I am often working on various projects or research efforts that most people in IT do not have much visibility into. Most people in applications development work on a specific group of applications and don't have the luxury of time to see what's going on outside their world. At the same time, the architecture team is constantly getting feedback that we need to communicate more. We spend a lot of time presenting at team meetings trying to keep the company updated. The blogs have been extremely helpful getting information out. I think Twitter can be a great tool for "quick hit" communications. For example, in two weeks, we have the guys at Zapthink running their SOA Architect Bootcamp at our office for four days (register here). As I come across some good nuggets of information I could "Tweet" them and they will show up on my sidebar of my blog. After a full day session I can then provide a more detailed summary on my blog.

Here is another use case. Let's say that I am going to a board meeting to present a business case for the next significant SOA project. In the meeting I get the thumbs up to move forward. For the next three hours, I will sit through other presentations and attend two other meetings. I quickly pull out my iPhone and Tweet the news that the project is approved. Upon receiving the news, my project manager can then start moving forward.

I recently listed a number of events that I am attending and participating in. As I encounter interesting facts or viewpoints during these presentations, I can share them back at corporate via Twitter.

Think about all of the notes and action items that you write down in the old notebook that you tout around with you all day. Many of those notes could also be handled through Twitter. Having all of that information online and searchable is much better then thumbing through my coffee stained notebook, especially with my bad handwriting!

The use cases are endless. I am going to start experimenting with this next week and will share my lessons learned shortly after. I am also going to start researching different open source tools that provide similar functionality as Facebook. If you know of some good ones, please pass them on. I am also going to look at how Serena adopted Facebook as their intranet and see if that is something that could work for us.

Stay tuned for more on these experiments in the near future.

I have written about my wiki implementation in the past. We use Mediawiki, the same open source software that drives the most famous wiki of them all, Wikipedia. Initially loading content into your wiki can be an enormous task, but Open Office, another popular open source tool, makes this task much less cumbersome. The latest version of Open Office Writer 2.3 has the ability to export documents to Mediawiki markup code. We used this to upload hundreds of existing pages of content into our wiki.

If you don't use Mediawiki, have no fear. You can always download an Open Office add-on called Uniwakka to convert your documents to the wiki format of your choice. If you are interesting in launching a wiki in your organization I recommend you read Stewart Mader's 21 Days of Wiki Adoption.

A colleague of mine sent me an interesting article today called Don't give customers what they think they want. This article has a great quote from the early 1900's by Henry Ford, the inventor of the Model T. While talking about user requirements, Henry stated:

"If we ask customers what they want they’ll ask for faster horses".

If Henry would have implemented exactly what the users asked for (if he even could accomplish that) he never would have created the Model T. Instead of asking users what they want, we should ask them what problem they are trying to solve. The article recommends asking this same question in a more eloquent way by asking, "What is the desired outcome?" After all, it is the job of IT people to design systems, not the business. The business should know what they want to accomplish and IT should devise a few potential solutions and offer those to the business.

I have ranted in the past in a post called Why are you still generating reports?, how IT has a tendency to let the business design systems. If the IT industry would get the business to focus more on defining business problems and desired outcomes instead of telling us what to build, perhaps there would not be such a huge need for business process reengineering these days. In my 20+ years of IT experience, I have seen huge amounts of waste due to IT building low value solutions. This often occurs because a user with limited visibility into the entire workflow asks for a point solution for their small part of the world. Over time, IT builds hundreds of these point solutions which wind up creating redundant data entry steps and the need for more reports and "quality" checks to accommodate for bad processes. The business person has good intentions but typically does not have enough knowledge of the end to end processes to offer up proper solution. This is precisely why we should not build what they think they need.

As we all know, IT does not have a great track record for delivering projects on time and on budget. I believe that a major contributor to this is IT's inability to gather good requirements. If we focus the requirements gathering process on business issues and desired outcomes, I believe we give ourselves a much greater chance of success.

What do you think?

One of the challenges of process improvement initiatives is getting the subject matter experts (SMEs) to think outside of the box. Quite often, people defend existing processes even though they know that there is a better way to do it. I often hear statements like "sales insists we do it this way", "we can't expect our customers to change their processes", and my favorite, "we don't have time". We need to get out of our old habits of living under constraints of legacy rules and start challenging why these processes exist and see if they still support today's business.

So when people declare that "sales insist we do it this way" we should find out why. What business reason does this rule apply? What is the cost of this business decision? Is there a better and more cost effective way to do this? What would it take for this rule to change?

When people say "we can't expect our customers to change their processes", do we know that for sure or are we making assumptions? Have we engaged our customers in a discussion about process improvement? Are they happy with the existing processes? Before we write off any process improvements we should first ask the questions.

When people say "we don't have time", do they realize that this excuse is the underlying reason why the processes are ineffective to begin with? Always taking the short cuts leads to ineffective and non-value added processes that waste company time and money. If you don't take the time now, don't expect to find time later to fix it.

In an effort to break the bad habits of old, we must constantly educate people on the value of process improvement and the true costs of waste and low value processes. When people resist changing an obviously inefficient process, you owe it to your company to not give in without at least asking some questions. Here are some questions to ask:

• What percentage of time does this occur? (does the 80-20 rule apply?)
• How frequently does this occur? (are we addressing something that happens infrequently?)
• Does this apply to all customers or a few? (are we addressing our high or low value customers?)
• If we were starting from scratch, would we still do it this way?
• What problem does this solve?
  

In addition to asking questions like these, we should perform an analysis to discover what the cost of an existing process really is. Not everyone understands process improvement, but most people understand money. Computing the cost of low value processes is often an eye opening experience for users. Once they see the expense, the amount of waste in labor, and/or the impact on quality, they become more open to change. Simply telling them to change without any real data is a tough sell.

Over time, the users will experience the power of process improvement as they work on new systems that leverage BPMS tools. The more hands on time they get with the tools the more they will see the benefits in the form of ease of use, visibility into the workflow, assess to information, and improved quality. When you first launch into your BPM initiative, these benefits are not as obvious. The best way to break them of bad habits is to quantify the costs of the waste. You will not always be able to convince people of a better way, but if you simply accept defeat without asking the questions, you may miss a huge opportunity to make a significant impact to the bottom line.

Another lesson learned I encountered recently is to clearly define the intentions of your BPM projects. There is a huge difference between attempting to improve processes versus automating processes. First let's discuss the pros and cons of each:

Process Automating in a BPM world

Pros

• Quick wins (unless processes are extremely complex)
• Less culture shock
• Reduce human error
• Start collecting process metrics baselines to analyze future process improvements
• Reduce paper, fax, emails, etc.

Cons

• Only small efficiency gains are realized
  
• Automating non-value add processes
• Missed opportunity to optimize work flow
• May never get a chance to improve processes

Process Improvement in a BPM world

Pros

• Reduce or eliminate waste
  
• Potential huge return on investment
  
• Improve employee performance and customer experience
• Reduce complexity of systems
• Financial justification of process steps
  

Cons

• Potential culture shock issues
  
• Requires more executive support
  
• More expensive to implement
  
• Requires more attention to change management

Like any other large enterprise initiative, a company must have a vision or a roadmap. Some companies may want to achieve financial benefits as soon as possible. For those companies, they should embark on a process improvement initiative right out of the gates. This means that the company must invest in training the business on process improvements with tools like lean sigma, TQM, and others or bring in talent to assess and recommend new processes.

Other companies may want to ease into the culture transformation and start with process automation. This allows the employees to get familiar with the BPM tools and to start collecting data about the current processes (time, costs, bottlenecks, etc.). This information can lead to process improvements down the road. The downside to this approach is that it will take the company much longer to reach the "promised land" of having streamlined and cost effective processes. The real danger that I see is other priorities may take precedence and the company may never get the opportunity to eliminate waste. In my opinion, process automation by itself may not justify the expense of purchasing a BPMS tool. The real value is in process improvement.

Fellow ITToolbox blogger Vladimir Stojanovski wrote a good post on this topic several months ago called Synergies of Process Improvement and Process Automation. In his post he pointed out some interesting statistics that I will mention here:

• Process automation resulting from technology investments yields 2 percent productivity gains. These are the types of projects where technology is used to make old, tired, and broken processes run faster.

• Process improvement through re-engineering yields 8 percent in productivity gains.

• When done together, productivity improvements from both process automation and improvement yield 20 percent in productivity gains.

Mark Smith wrote a post back in 2005 called Process Automation Can Undermine Performance. The key take away from this post is his closing statement:

To succeed at BPM, assess for success, think beyond automation and make performance improvement your number-one process improvement goal.

My point is, the real value in leveraging BPM is process improvements. Process improvement combined with process automation is a powerful combination that can bring real value to an enterprise. Process automation by itself is nice, but it still allows waste to exist in the organization. But whatever your BPM strategy is, make sure it is clear to all team members what the direction is. If some people have an expectation that the goal is automation, while others think the goal is improvement, you will create a lot of unnecessary conflicts.

As I mentioned a few weeks back, I have partnered with Zapthink to secure a four day Licensed Zapthink Architect (LZA) Boot Camp in St. Petersburg, FL from February 26-29. We have close to 20 people registered to date and have room for several more. By the way, it's sunny and over 70 degrees here! For those who like the cold or would prefer to attend a one day event called Practical SOA in Newark, NJ (home of the world champion Giants), go to this link to register for the March 25 event. I will be attending this event and might even be speaking about a case study that I am involved with. I will update everyone when I know more.

I will be attending the Gartner EA Summit in Orlando on June 11-13 and SOA World in New York city on June 23-24. If any of you plan on going to these events and would like to meet to talk technology with me, drop me a note.

Here are links to the events that I am attending:

• LZA Boot Camp in St. Petersburg, FL (2/26-2/29)
  
• Practical SOA in Newark, NJ (3/25)
• Gartner EA Summit in Orlando (6/11-6/13)
• SOA World in NYC (6/23-6/24)

I have written about my experiences implementing Web 2.0 in the work place and the initial reactions to the technology when I first mentioned it. My architecture team has been piloting Mediawiki as our wiki for several months and have been testing Wordpress as our blogging software. Last week we launched both of these tools to the company. We restricted the blogs to the architecture team as a vehicle for communicating our vision, progress, and lessons learned for our BPM/SOA initiative. After only one week, here is what I have seen.

Adoption has been relatively slow (as expected) but people are starting to collaborate with us through blog comments. They are asking questions which gives us an opportunity to further clarify the direction of the BPM/SOA initiative. Several people have now come forward and asked us for their own blog to communicate the status and direction of their projects. I can already tell that over the next few months the wiki and blog usage will sky rocket which should greatly improve our ability to communicate more effectively to large audiences.

My company is working hard to optimize business processes and bring more modern tools and technologies into the organization. Some areas are further ahead then others. One area still far behind is user documentation. We still do the 1980's thing and create huge manuals in large clumsy binders and hand it to the end user. The end users of many of our systems today are mainly comprised of Gen-Y people. One of them was recently handed a huge binder and responded by saying, "Do you really think people learn this way?" That sent a clear message!

So as my title suggests, when it comes to Web 2.0, or if you prefer, Enterprise 2.0 technologies, Just Do It. Trying to explain the ROI or justify costs with Baby Boomers is a tough sell. Some of the best tools are open source and require very little time to setup. Get the tools implemented and in the hands of the users. Unless your workforce is mainly older, you should see rapid adoption of these tools. Just Do It.

For those of you that know me, you know that I am a huge fan of the New York football Giants. As I bask in the glory of the greatest Superbowl upset of all times, I can't help but reflect on the amazing transformation that Tom Coughlin engineered over the course of the year.

As the 2006 season ended, the promising Giants finished as a team in decline with players calling out coaches, countless mistakes being made at crucial times, and sub par performances being displayed on a weekly basis. The coach and his young QB were being chased out of town. For some reason, the Giants gave Coach Coughlin one last chance. So how did he respond?

First, he was wise enough and open enough to perform an assessment of the performance of his players, the team as a whole, and most importantly, of himself. He listened to the constructive criticism of his bosses and players and decided to make some changes. What he found was that his vision was not fully understood by all of the players on the team. So he formed a leadership committee made up of various players on the team who could help him clearly communicate the vision. Better yet, he let the players select the leadership team. Since the players participated in forming the leadership team, it gave them a sense of ownership in the process.

During the course of each week, Coughlin and the leadership team would meet and discuss strategy for the upcoming game. The players, highly respected veterans like Michael Strahan and Antonio Pierce, would spread the word to the younger players in a language that they could understand. This did a few things. First of all, the leadership team now felt accountable because they were given ownership in the process. In order to clearly communicate to the other players they must fully understand their coach's message. The second thing it did was give the vision creditability since the message was being delivered from highly respected players in the trenches.

Another important thing that Coach Coughlin did was emphasize the importance of every single player's role and how it related to the overall mission of the team. The Giants, unlike the mighty Patriots, were not loaded with superstar talent. Only one player made it to the Pro Bowl this year. They were, however, solid at every phase of the game (offense, defense, special teams). This was due to the fact that everybody knew what their job was and what was expected of them. Backup players prepared as if they were starters. As starters fell to injuries, backups (mostly rookies) stepped in and filled roles without the team missing a beat. There was truly no "I" in team.

So let's summarize. The creation of the leadership team accomplished the following:

• Clear understanding of team's vision
• Participation in overall strategy
• Constant feedback
• Clear communication
• Accountability
• Buy-in
• Shared goals
• Clearly defined roles and responsibilities
  

This sounds like a successful formula for any kind of transformation. You don't have to be shooting for a Superbowl to take action like Tom Coughlin did. If you want to be the best leader that you can be, make sure you have a method of achieving the eight items that I listed above.
If you are trying to transform your IT organization, look at Coach Coughlin's recipe for the 2007 season. If you want people to change, first change yourself. Otherwise, the message you send is everyone needs to change except me. Value every person in your organization and clearly define their role and the importance of it to the organization as a whole. Surround yourself with leaders and change agents and have them spread the vision. Taking that burden solely on your own shoulders is challenging and can be viewed like a dictatorship. And finally, don't listen to the nay sayers who tell you that it can't be done. You can accomplish anything if the whole team is buying into the vision.

Go G-Men!

Many articles that I have read speak about the complexity of BPM and SOA technologies. In my experience, the most complex part of implementing these enterprise wide initiatives is dealing with change. And the number one way to address change is to have a solid communication plan. But is a good communication plan enough? Managing perceptions, attitudes, fears, and confusion takes more then a communication plan. The execution of the communication plan is where the rubber hits the road.

What I am getting at is the Chief Architect, the business sponsors, the enterprise architects, the CIO, and all of those people who are thrust in the spotlight need to be consistent in their message, their attitude, their goals, and their delivery.

With many culture changing initiatives, you have people who are ready for change, people who fear change, and people who take the "wait and see" approach to change. The wait and see people are like the swing voters in the upcoming elections. They need to be convinced before they commit. What that means is that they scrutinize everything about the candidates from what they say, to how they say it, to how they react to certain questions and circumstances. They same thing applies in your BPM/SOA implementations. If the people driving the change show signs of weakness, frustration, or stress the "swing voters" will pick up on this and may be turned off. The people driving these initiatives must also speak publicly as careful as a politician so not to say things that can cause the swing voters to run away.

Early on in my implementation, we had some challenges with some of the vendor tools that we purchased. I was pushing the vendor hard to resolve the issues but also expressed some frustration with the vendor that many swing voters picked up on. The next month or two I was in damage control mode fighting the perception that our SOA stack was a pile of garbage. The SOA tools in the market place today are early in the maturity phase and tend to have various integration issues across the various components of the stack. That doesn't mean that the products are garbage, it just means that stabilizing the new environments are challenging. Because I am very visible on this project and people saw my frustration with the vendor, I had to spend a lot of energy changing the perception of the tools. This is just one of many examples of how the swing voters' perceptions were swayed by the actions and delivery of both verbal and non verbal communications.

After dealing with and heading off many issues, perceptions, and fears, we have put together a more strategic plan for communicating going forward. The business leaders and the CIO will now send out frequent communications to all employees on the progress of the projects. We are spending more time showing demos and prototypes to anybody who wants to see them. The architecture team started blogging about the vision, the technology, and the project. But the most important part of these communications is the delivery. All of these communications must be delivered with confidence, consistency, and must explain the value of the initiative to the audience. We must think of our audience as swing voters looking to decide if they want to join the campaign or turn and run. After all, it is the swing voters contributions to the cause that will make the difference in the long run.