Enterprise Initiatives

One of the many websites I visit, SOAGovSource, published a free pocket guide today for all of their registered users. This guide has quotes from numerous articles about SOA Governance taken from a variety of popular blog posts including yours truly. You can see the tables of content on the right hand side of this post.

To download this guide, go here. This PDF file gives you great quotes from various authors and links to articles written by industry experts, analysts, and practitioners.

Enjoy!

I have worked on many large enterprise initiatives over the years. Some were successful and some were not. As an avid researcher of my trade, I have also read about many failures of large initiatives. Being the lessons-learned kind of guy that I am, I always try to understand what worked and what didn't so I can make sure that the next enterprise initiative can avoid failure. Whether you are implementing SOA, Enterprise Architecture, forming a PMO, introducing a new programming language, or merging with another company, I have seen a consistent pattern of failure that can be summed in the following 10 categories:

1. Poor Communication
Enterprise projects usually impact a large amount of people. This requires constant communications to all levels of people throughout the organization. A strong communication strategy can help with this. Use a combination of town hall meetings, portals, blogs, group meetings, emails, wikis, bulletin boards, posters, and any mechanism you can think of to get the word out. In larger companies, this can be a full time job for somebody.

2. Underestimating or ignoring impact of change
This is another way of saying poor change management. People need to know WIIFM (what's in it for me). Resistance to change can kill any project. Your initiative must have a champion who carries a lot of clout. The leadership, lead technicians, project managers, and all of the visible people in these projects must be positive forces and constantly promote the vision and the future state. I wrote a post called BPM, SOA, and the Swing Voters that discussed how important it is to stay focused and positive and not to show frustration. People will feed on the attitudes of those leading the initiatives. You must address resistance head on and address people's needs to help them turn the corner. For those who just refuse to buy in and become roadblocks, show them the door!

3. Lack of Leadership
IT Leadership requires excellence in three key areas: Technology, Business, and People. If the leadership is missing any of the three components you are doomed. I have seen some projects succeed where the leader was not technical but relied on strong technical people below them. I have never seen a large enterprise initiative succeed when the leader did not have people skills. Not having the business knowledge often kills projects because the projects tend to be done for the sake of technology and not for business reasons. In this case you can deliver the most impressive solution in the world, but the business might reject it because their needs were not taken into consideration. The leader must work just as hard if not harder then the people on the team. I have witnessed one "leader" assign his team a ton of work over the weekend and then left at 5pm on Friday and said "See you Monday". That created an all out revolt. The leader must have integrity or nobody will follow.

4. Lack of strong executive sponsorship
For these projects to succeed you must have somebody high up in the organization with a lot of clout. There will be many obstacles to overcome and key decisions to make. You need somebody strong to help make and enforce those decisions and remove major hurdles so the team can get the work done. This is a critical part of change management.

5. Poor project management
Scope creep is a project killer. Managing scope and requirements are the key to any project. Often, large enterprise initiatives have a ton of logistics that need to be identified and managed accordingly. These initiatives also tend to span multiple teams across various departments. The project manager must coordinate all this and effectively communicate to people at all levels. And don't forget risk management!

6. Poor Planning
This could also fall into a category of unrealistic expectations. Initiatives like SOA require a well thought out strategy. Many IT shops do not have the patience for this and rush into their project head first without a clue of how to actually accomplish their goals. When it fails they claim that SOA doesn't work. If you are going to take on a big culture changing technical project take the time up front to do the necessary research and create a roadmap. Then put a plan together to get you from initiation to implementation.

7. Trying to do it cheap
Another common mistake. Organizations want it all, but they don't want to invest the time and money. I have seen many projects get completed using this strategy, but they almost always run over budget, are late, are missing many features, and have many various quality or process issues due to the quick-n-dirty approach. Remember, the dirty stays around long after the quick is gone. Doing things cheap often costs more in the long run. I have witnessed many projects that didn't fund the appropriate number and types of resources. You wind up not creating documentation, not having the bandwidth to sufficiently test all of the use cases, not having time to architect it right, and you burn people out in the process. Another issue is that underfunded projects usually don't provide the team with the necessary tools to do the job and do not prepare the organization for life after rollout. Even worse, you may wind up picking the wrong vendor, whether it is software or professional services. Picking the wrong vendor can be disastrous.

8. Lack of technical knowledge
I'll use Enterprise Architecture as an example here. If the person leading an EA initiative does not have a solid understanding of architecture, application development, security, infrastructure, process, and the business, you might as well not even start this initiative. You can have all of the leadership and communication skills in the world but if you lack the technical know how you are doomed. Many enterprise initiatives are very expensive undertakings. Don't pick a leader with the "I stayed at the Holiday Inn Express" mentality. You wouldn't ask me to remove your appendix so why would you have somebody with little or no knowledge of the technology at hand lead your enterprise initiative.

9. Lack of sound business case
You can get all of the other issues right but if your solution has no business context then you are wasting your time. I have seen this happen with many SOA projects. IT teams with great intentions go off into their ivory towers for months or years and come out with tons of great documents (usually outdated) and a nice service oriented architecture. Then they try to convince the business to use it. Good luck. Justify these initiatives with business drivers. I have beaten this horse to death on this blog (here, here, and here).

10. Poor vendor management
I have seen this happen far too many times. Somebody hires a high priced group of consultants and let's them run wild. Consultants goals are similar to your goals but that is not a good thing. Both the consultants and your goals are to make as much money as possible for the company. The difference is you are trying to maximize profits for your company and they are trying to maximize profits for their company. If you don't manage them closely they will succeed at their goal and you will fail at yours. Also, the consultants will not have to stick around to support what they build, but your team will. You should make sure that what they build meets your requirements, your standards, your needs, and your timelines.

Summary
I have a saying from my 20+ years of working on IT projects. It goes like this.

"I have worked on so many projects that I know all of the things NOT to do."

That's the easy part. Knowing what to do is much harder. I'll leave you with this post called EA, SOA, and Change which has a very successful formula for enterprise initiatives.

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, add incremental value
   
8. Govern

Lately I have been getting a ton of calls from recruiters who are looking for some really smart people for various technology jobs. I don't know where they are getting my name from but they all know that I have a very solid network of talented people. Most of the jobs are in the North East or the West Coast. I am in Florida and have no plans to leave the Sunshine State any time soon. The gentleman who called me today said, "I was told that you are the guy to call because you know a lot of people in IT". That got me thinking. Between my connections on ITToolbox, LinkedIn, Plaxo, Facebook, and Twitter, I have about 500 IT people in my network with various talents. Why not share these opportunities with my friends and colleagues? I sent out a couple Tweets on Twitter but I want to try out this blog for a new way to share job leads with my network.

So if you are a recruiter or employer and are looking for some good people, shoot me an email (mkavis@yahoo.com) or a Tweet (madgreek65) and I will start a weekly post on job openings. This is totally free for both the talent seekers and the job seekers.

Here is my motivation. I have been contacted on some very attractive, high paying positions in states that I cannot move to. I would like to give those in my network an opportunity to inquire about these jobs that are typically not posted anywhere. Also, I would love to build a trusted network of recruiters and employers. You never know when they might return a favor for me or for someone I know.

So here is an attractive job that I sent out on Twitter today:

Recruiter called and is looking for IT Director for small loyalty marketing co. in Rochester, NY. Call Alan 732-463-1414.

I will send job notifications like this out on Twitter when I get them and will have a weekly post that summarizes all of the jobs I hear about during the week (if I get any). Currently I get 2-3 calls/emails a week on average. If you know any recruiters, forward them this post. If you are looking for a certain job opportunity, let me know so the next time they call about a particular job I can send them your way.

If I get enough people participating, I'll create a new blog dedicated to sharing job leads to connect recruiters with talented IT people. If I don't, no big loss. Let's give this a try. It is so hard to get your foot in the door these days. It is all about who you know and who can get your resume passed the paper shredder in HR. All I ask in return is that you check out my blog every now and then!

Recently, I provided senior management with a presentation of the value of Enterprise Architecture. For those of you who are tasked with a similar assignment, I thought I would share an example that has worked for me. Keep in mind that some of the bullets are specific to my environment, but hopefully the presentation gives a perspective of how to explain EA in simple terms to people who have never been exposed to EA. I did alter the original presentation to try to make it as generic as possible for my readers.

Feel free to critique this or use it for your own benefit.

There has been so much hype about SOA and now WOA that sometimes I think we focus more on fantasy then reality. Yes, both of these technologies offer huge potential benefits but they are both just another tool in the toolbox. Neither one of these will solve world hunger as some media types tend to think.

The WOA craze seemed to start shortly after Anne Manes pointed out that many of the companies she talked to were failing in their SOA efforts. Then came the quick fix, WOA. Many pointed out how the business can grasp the concepts of WOA and not SOA. Others pointed out that it is easier and quicker to implement then SOA, which they claim takes years to implement. I believe WOA is a great compliment to SOA, but I fear many people are thinking about WOA instead of SOA.

Implementing SOA takes vision, leadership, planning, and architecture, something that many IT shops don't have the patience for. Instead they opt for quick and dirty habits that lead to the inflexible, costly to maintain systems that so many of us are stuck with today. I fear that if we bypass SOA instead of complement it with WOA, then we are are going to wind up with "Quick-n-Dirty 2.0", a web enabled mess. There are no shortcuts to developing a sustainable, flexible, and maintainable architecture. We should use these technologies where they make sense. They are not the end-all, do-all answers to our problems. The excitement that I hear about WOA reminds me of the day trading craze of the late 90's. Everybody was looking to get rich quick. We need to make sure that we don't get too crazy with WOA and quickly build nice eye candy systems that we can't maintain, have no control over system performance and SLAs, and can't fix when they are down.

I know this sounds like doom and gloom. I am actually a fan of WOA. But I am concerned that many companies will dive in head first without much thought about architecture, infrastructure, support, change control, dependencies, and many of the other critical areas that a sound enterprise must consider when it introduces new applications into the production environment.

Remember, we are architects not day traders.

In part 1 I debunked the "OSS is bad for the economy myth". In part2 I showed six different models for OSS support. In this third and final post on debunking OSS myths, I will address these two statements:

• OSS products are second rate ("created in the garage" mentality)
• OSS can't be good because it is free

There are many OSS products that are highly reliable and run the systems of very successful companies and web sites that have millions of users. Just look at some the names of highest traffic web sites ranked by Alexa that use the LAMP (Linux, Apache, MySQL, PHP, Python, or Perl) stack (the link next to the website shows their underlying architecture):

1. Yahoo (LAMP)
   
2. Google (LAMP)
   
3. Youtube (LAMP)
   
4. Windows Live (Win)
   
5. MSN (Win)
   
6. MySpace (Win)
   
7. Wikipedia (LAMP)
   
8. Facebook (LAMP)
   
9. Blogger.com (LAMP)
   
10. Yahoo JP (LAMP)

Go to this link to look up the architecture of your favorite sites.

Other major companies using LAMP are Amazon, Disney, Boeing to name a few. Read this article called How Linux saved Amazon millions to see the real value in open source software. Twitter is another site that is growing like crazy. Look at the OSS that it uses:
But major websites aren't the only ones leveraging OSS. Most of the major technology companies have an open source strategy now. How about this list (click on the links to see each company's Open Source page):

• IBM
• Sun
• BEA
• Oracle
• HP

All of these companies are using OSS along side their own products to drive costs down. Most non-Microsoft development these days leverage a ton of open source tools. Look at the tools in the J2EE stack:

• JBoss
• Tomcat
• Struts
• Hibernate
• Spring
• PHP
• Perl
• Python and more

So much for the comments "Free means crap" or the ignorant "garbage.com" comments. These tools are the real deal. Are there crappy OSS products? Sure, but no different then the crappy proprietary products. Even Microsoft is starting to pay attention to Open Source. Although they are doing because OSS is a threat while the other companies are leveraging it as a competitive advantage.

So this concludes my 3-part series on debunking OSS myths. Anytime you hear the myths or FUD be spewed by those who refuse to acknowledge reality or just have not done their homework, please forward them these articles so they can learn what most of the rest of the world already know.

I just downloaded the last release of Open Office (v2.4) on both my Windows and Linux PCs. This version has some minor tweaks and fixes from v2.3. I can't wait for the 3.0 version which is scheduled for this summer. This version has many new features related to Web 2.0 and also works with Vista (God forbid) and Office 2007. In the meantime, you can download this file to make Open Office compatible with Office 2007. Check out this document for the full set of features and future direction of this excellent office product.


Open Office 3.0 - Get more documents

For those of you who still think that OO is not ready for prime time, think again. I have been using it at a Microsoft shop for a year and nobody can tell the difference. There have been over 1 million downloads of OO in just over the last 100 days. Version 3.0 will take it to the next level.

Here is my presentation from Zapthink's Practical SOA conference in New Jersey back on March 25. My topic was How to Sell SOA to the Business. My three key take aways:

1. Align SOA w/Business Drivers
2. BPM is the Killer App
3. Speak in Business Terms
   

Click this link and go to the 4th video (you must register on Zapthink...it's free)


Feel free to leave comments or send me your questions at mkavis@yahoo.com.

In part 1, I highlighted four myths (FUD) that I felt needed to be addressed:

1. OSS is bad for the economy and defies the values of capitalism
   
2. OSS support is bad, slow, and/or non-existent
3. OSS products are second rate ("created in the garage" mentality)
4. OSS can't be good because it is free

In this post I will discuss the myths about open source support. I have heard every quote from "You can't get support for open source" to "Where are you going to get support, in a chat room?" It is obvious that people who make these statements have not done their homework or just choose to dislike OSS because of their long history of snuggling up with their favorite vendor(s).

There are many options for getting OSS support. I will list six that I am aware of.

Single Vendor Support
Many well established open source projects offer support for a fee. Typically these support fees are minimal when compared to proprietary software where they charge 18-21% of the purchase price. Some projects offer a totally free version of their software with a subset of features but offer an enterprise license with full support that has the complete bundle of features. In either case, this model is similar to the normal proprietary model where you pay for the support of your product. Also, many major software vendors like IBM, Sun, and Oracle are leveraging open source products within their software offerings. In cases like this, these vendors provide support for the OSS products. The only downside to this is they are often not certified on the most recent version of the OSS products.

Stack Vendor Support
In this model, a single company provides support services for a suite of products. Companies like SpikeSource & SourceLabs provide support for a suite of products while Redhat provides support for its own "appstack" which includes jBoss, Red Hat Linux, Apache, MySQL, PostgreSQL, and languages like Perl and PHP. The following diagram is from SpikeSource's web site that shows a few different stacks that are supported.


Community
All OSS products have community support. Many people not familiar with OSS believe that this is nothing more then interacting with some hacker in his garage. This might be true if you are betting your business on a product with a development team of three (which is not highly recommended). But most serious OSS contenders have a huge community following which provides 24x7x365 support from people all around the world. This is where I see an advantage of community support over proprietary software support. In the OSS world, it doesn't matter if you are a billion dollar company or a startup, your issues are equally important and addressed. In the proprietary world, top customers typically get priority over others because huge contracts carry a lot of clout. Many critical fixes and security issues are fixed and patched literally overnight. In fact, if you know how to fix the issue, you can make the changes and submit it to the project team to be reviewed and possibly patched. That beats waiting for the next service patch!

Do It Yourself
You also have the option to not pay any support and fully support the OSS yourself. This makes sense for most non-mission critical products like blogging software (WordPress) and wikis (Mediawiki), but is not recommended for mission critical products like server based Linux and ESB's like Mule.



Use consultants
Another option is to use consultants. This can be individuals who are experts with certain OSS products or companies that specialize in installation and/or support services for various products. You can see a huge list of consulting companies on Sourceforge.net who specialize in certain areas. Some companies use consultants for installations and upgrades, but chose the "Do it yourself" method for everything else. Sourceforge also offers support services for several products.

Mix and Match
The sixth model is to mix and match a combination of the five support models above. Many OSS products rely on a LAMP (Linux, Apache, MySQL, PHP) stack. A company may already have a stack support vendor it deals with and may choose one of the other models to support the specific product. I'll use my Mediawiki example again. Mediawiki may not be a mission critical application at your company, but a few other applications might rely heavily on LAMP, including the wiki. The LAMP stack may already be covered by a stack vendor so you may chose the community or "Do it yourself" models for the wiki.

So the next time somebody tells you that you can't get support for OSS, forward them this link. This myth is pure FUD. I am not saying the all OSS products have good support, but then again, that is true for proprietary vendors also. Part of the vendor selection process for OSS should include your support requirements. If support is critical, make sure you pick a product that has strong support options in one or more of these models.

On the ITToolbox community, we have some very passionate bloggers both for and against open source software (OSS). I am a proponent of both OSS and proprietary software. As an architect, I view both of these as tools in my toolbox. The trick is to know when to use the right tool for the right job. It is unfortunate that some people think there is no place for OSS. Here are a few of the myths (FUD) that I continue to hear from people who insist on depriving their company from leveraging OSS tools even when it may be the best solution for a given problem.

1. OSS is bad for the economy and defies the values of capitalism
   
2. OSS support is bad, slow, and/or non-existent
3. OSS products are second rate ("created in the garage" mentality)
   
4. OSS can't be good because it is free
   

Myth #1 - OSS is bad for the economy
This could not be further from the truth. Here is a real life scenario from my trip to France last week.

One of our business partners is in the software development business. They are a small company with small IT budgets whose customers are primarily in the retail industry, mainly grocery chains. The retail grocery industry is a very low margin business and one where companies are in real danger of being crushed by the likes of Walmart and Carrefour. These companies are extremely frugal and the big boys have a major say in the price of goods and services. One of our partner's core strategies is to leverage open source technologies to keep both their costs down and to keep the cost of their solutions down. Due to privacy concerns, some of these retailers are demanding that solutions providers shift from the current ASP or SAAS models to a shrink-wrapped model (buying the software and running it locally). This is currently not feasible for companies heavily invested in proprietary software due to the licensing costs of vendor software that is involved. The retailer would have to pay for the operating system, the database, the application server, the BPM tools, the middleware, etc. This would add up to a hefty bill. Using OSS like the LAMP suite (Linux, Apache, MySQL, PhP) and Intalio for BPM, this solution becomes affordable and a competitive advantage to sell to the hundreds of retailers in this space.

Please read this article from Wired called Free! Why $0.00 is the Future of Business so you will understand my next point. Here is an excerpt from the article.

Technology is giving companies greater flexibility in how broadly they can define their markets, allowing them more freedom to give away products or services to one set of customers while selling to another set.

Let's look at this blog for starters. I use free tools to publish my lessons learned and ideas on both Blogspot and ITToolbox. In both cases, a software product and a service was offered to me for free. In return, Google and ITToolbox get value by increasing traffic which increases advertising revenue. I paid nothing for the software or the services. I dedicate a lot of my personal time and expertise to my blogs because I get recognition, increase my network, and I learn from others. So in this case, "Free" is actually a revenue generator and is good for the economy. In the example above, free software allows my company and our business partner to compete by controlling our costs. These OSS products allow us to generate revenue and allows the retailers to improve their products and services by leveraging our loyalty marketing solutions. Once again, "Free" is generating revenue.

The anti-OSS folks argue that OSS is taking food off the plates of developers and giants like Microsoft. Yes this is not good news for Microsoft but there is more to the world's economy then the market share of software giants. Without OSS, this new surge in Social Networking would not be what it is today. Look at all of these new startup companies that have emerged over the last few years. Starting a Internet company from the ground up has never been more affordable. Look at tools like Twitter, Facebook, Wordpress, MediWiki, Joomla and others. These tools are changing the way the world communicates and they are all free. The more collaborative the world is, the stronger the global economy gets. These are all good for the economy.

I believe if people would stop thinking of OSS as Linux versus Windows, we could look past our "religious" beliefs about our favorite operating system and start focusing on things like controlling costs, share holder value, flexibility, negotiating power against vendors, and more. In part two I will discuss the myth about support for OSS. Until then, I look forward to the debate that follows. I ask that we keep it professional!

I am supposed to be landing in France in one hour but instead I am posting this blog from my hotel in Philadelphia due to a missed connection. This situation could have been avoided if there were better business processes in place. This unfortunate situation coupled with inflexible business processes on the customer service side of the business has cost this airline a few customers for life. I bet a company with good business processes, like South West Airlines, would have handled the situation better.

Here is my story. My flight out of Tampa on US Air was supposed to leave at 2:15 en route to Philly. Due to weather we left 75 minutes late. When we arrived in Philly, we had 15 minutes to get to our gate which happened to be on the other side of the airport. We showed up at the gate at 6:02 for a 6:00 flight and the plane was gone. My colleague and I were not the only ones left stranded. Here is an opportunity to improve business processes and leverage technology to avoid losing customers. Business Process Opportunity #1. US Air should consider having processes that detect the impacts of delays in connecting flights. They should have known that there were a few customers who were arriving from Tampa and were at risk of being late for the connecting flight to France. The flight to France is seven hours so holding the flight for an extra 15 minutes would not cause a delay in the arrival time. They could easily make up that time in the air.

The story continues. We then had to get another flight to France. We were told that there was no other solution then to wait 24 hours for the next flight to France. We asked about other airlines and the answer was nobody had any other flights. She did not look this up on the computer she just declared it. We argued and argued and it went nowhere. Business Process Opportunity #2. A business process that explored alternative flights on other airlines would be nice. If they could have put us on another flight I would be able to write this off as a bad weather issue. Since they had no acceptable solutions, I will write this off as poor customer service and inflexible business processes.

It gets better. Now we need to get a hotel. This process seems to take an eternity. We get sent to different hotels and get $15 of meal money for a 24 hour period. That's enough for one Philly cheese steak sandwich! If you want to go on a diet fly US Air! Then I ask about our luggage. She has no information on it and directs us back to the original gate that we arrived on. Business Process Opportunity #3. Part of a customer retention strategy should be to have business processes to easily accommodate displaced travelers. Better collaboration with hotel partners and information about the whereabouts of my luggage should be a click away.

Not done yet. Then we grumble and moan our way back to the luggage claim another 15+ minutes away. The good news. Our luggage is at the airport and did not go to France without us. The bad news. We can't have it! It is checked into customs and cannot leave the area. I asked for them to rethink this since I have some mediations that I need to take each morning for my kidneys. Her response, "That will be a problem". Arguing led to yet another reality that their existing processes are very rigid and they have a culture of procedures over customers. Business Process Opportunity #4. Revisit legacy business processes and make sure they still meet the needs of the business. Identify exceptions and see which ones make economic sense. How hard would it be to get me my bag. Luckily I can go a day or two without my pills before my blood pressure goes off the charts. I hope no heart patients had the same scenario.

In total we had to talk to four different people in four different locations to get all of this done. The outcome was totally unacceptable (24 hour lay over with $15 for food and no access to my luggage). Every time we asked them for alternatives we heard the same clear message, "We can't". This is not a people issue, this is a process issue. In fact, the employees were very sympathetic and professional, but their hands were tied due to ineffective business processes. I am sure with the right business processes, these same people could have helped us out. Since US Air does not seem to think that business processes can be a competitive advantage, they have lost these two customers for life and possibly anyone else who reads this.

I would love to hear from anyone in the airline industry how your company deals with delays and exceptions.

I read this post from Stewart Mader's blog on wiki patterns today and it talks about a challenge to the adoption of wiki is the fact that the new tools are too inexpensive or even free (open source).

Here is a key quote:

Sandy Kemsley’s fourth challenge to social media/enterprise 2.0 in organizations:

The fact that these technologies are inexpensive (or even free) and quick to implement causes them to be discounted by executives who are used to spending millions on information management systems.

Isn't it time that executives stopped running their IT shops like it is 1980? Spending millions on large vendors may make it easier for one to sleep at night, but it is not the best use of corporate dollars. I have been in IT for a long time and I have witnessed the same pattern across several companies over the last 20+ years. The pattern that I am talking about is IT puts more weight on "manageability" then they do on customer requirements. Some shops are so married to big vendors that they are not taking advantage of open source solutions or even worse, they are limiting the vendor selection process down to a set of tools that do not meet the customer's needs. When this happens, IT becomes its own worst enemy. First of all, adoption of tools that the users do not want or do not value as high as other tools can be a major challenge. I have seen my share of shelf-ware over the years. Second, forcing customers into solutions does not bode well for customer satisfaction and may cause the customers to look elsewhere next time. Third and maybe the worst case of all, sticking to the major vendors at all costs may prevent IT from selecting any tool due to high costs or lack of a sufficient tool. To put this into perspective, the user suffers because our favorite vendor can't deliver.

Here is an example. If you look at Web 2.0 tools today, most of the top tools are either open source or provided by startups or companies without billions of dollars in revenue. IT shops who still stick to principles from 20 years ago will simply not invest in enterprise blogs, wikis, and social networking tools. The big vendors either do not have the tools or the tools that they have cost a significant sum of money. Trying to justify spending a large amount of money on better collaboration tools is a major challenge. With open source or low cost alternatives, it is much easier to start small and grow adoption over time.

At the end of the day, we should understand that the reason that corporations fund IT departments is so that our internal and external customers have the tools, products, and services they need to do their job. The world is changing and IT must change with it. In addition to the normal technical requirements (manageability, scalability, etc.), the vendor selection process should consider the following:

• Buy vs. Build (is it a core competency?)
  
• Evaluate open source alternatives
• Evaluate SaaS alternatives
• What is the vendor's SOA strategy (integration and agility)

Is your IT shop still stuck in the 1980's? If so, what are you going to do to educate your executive team? Do the research for them and show them where technology is going. The worst thing that can happen is that people will learn something.

I received a call from a recruiting firm today for an EA job in Maryland. Maryland is no place for a die NY Giants fan like me! I told the guy thanks, but no thanks. He asked if I could pass the job description out through my network. He said he knows that us EA types stick together in packs (like wolves I said). So I told him to email me the job description and I would send out a quick Tweet to my network.

Then I started to wonder. Why are recruiters not using Twitter? Think of the time they could save calling, emailing, and searching for candidates if they could create a Twitter account for EA jobs and start connecting to candidates. Twitter messages are viral. One Tweet with a link to a job description and the recruiter could have his phone ringing off the wall. All candidates would have a ton of content on the web (blogs, tweets, etc.) which could easily serve as the first screening process.

What do you think? Am I on to something or is this already happening?

By the way, drop Anthony Johnson an email at johnson@fitzdrakesearch.com if you want details of the job.