Enterprise Initiatives

I have been thinking about writing this post since I wrote this article about Second Life. As I was getting my daily updates from my Google Reader I came across Nick Malik's article called

Using Massive Multiplayer Online Concepts to Build a Shared Architecture

In this post Nick writes:

What I haven't seen yet (and perhaps it is the nature of the child-like games my kids play) is a MMO game where every person plays a role to build something instead of defeating something. It is easy to tear something down. Divide and Conquer. Building something up is much harder.

Welcome to Second Life. If you still are not up to speed on how Second Life is being used in the business world you must read this article called Alternate Universe. As I continue to follow the success of Second Life I often wonder why is it that Linden Labs can create such a successful architecture that runs a virtual world with over 8MM users world wide while most companies struggle to create an architecture to support the real world?

So I did a little homework and as I suspected, Linden Labs leverages open source technologies like MySQL, Apache, Squid, Mono, uBrowser (for online help) and Debian as its choice of operating systems to run its grid technology. Linden Labs provides developers with APIs that are simple REST style web services. They have their own proprietary XML format (called LLSD) that supports Perl, PHP, Python, and Ruby. They have a very robust portal and wiki which uses Mediwiki, another open source product.

The beauty of this architecture though is not the open source technologies that they have chosen but instead is the use of open standards which allows them to create a platform for others to build from. People can contribute to this platform as C++ developers, they can use Second Life's scripting language, they can leverage a host of third party tools and services, or they can simply use the tools provided by the user interface. This is a very open environment, much like many of the successful open source projects that exist today.

Now back to the topic of architecting the real world. As architects within an enterprise, we should take the time to review the benefits of the Second Life architecture and apply it to our work. Here are some of the obvious benefits:

1. Open; supports multiple development platforms
2. Easy to use; simple interface & documentation is easy to find on the wiki
3. Scalable; scale up by adding more nodes to the grid
   
4. Cost effective; use of open source reduces high cost of software licensing
5. Enables users; users are free to innovate and are not restricted by the architecture
6. Extendable; other companies can leverage platform to drive more revenue inward

Isn't this what we should be delivering in the real world? Do you think they spend a lot of time arguing over process? Do you think they spend a lot of time gathering user requirements? Or do they have a vision and know how to anticipate user needs? Have they tried to handle every possible exception in the world or did they create a robust set of standards that do not restrict usability and functionality?

There are still many people who are unaware of what is happening in the virtual world and others who are not taking this movement seriously. We just may be looking at the future of business where individuals and businesses do most of their commerce in virtual worlds. The architecture will definitely support it. Whether virtual worlds are the future or not, we should at least study the underlying architecture and the interactions that take place in their open development community.

I stumbled across this webcast that contains a 26 minute video explaining Microsoft's virtual licensing. When you need to spend a half hour just trying to figure out how you are getting shafted on licensing then it is time to look for alternatives.


Video: Licensing Microsoft Servers for Virtualization

Oh, and by the way, there are nice alternatives to VMWare also.

I started blogging in March of 2007 and have enjoyed the experience thus far. I have learned a lot about writing, received valuable feedback (both positive and negative), and have built a great network made up of very smart people. Heck, I even had a few people approach me about job opportunities out of the blue. The purpose of this post is to share a story about why I started blogging.

Back in February, I ran into an old friend of mine named Mary. Mary is a retired professor who co-authors a book on database management. She was telling me about her retirement and how she and her husband spend 6 months of the year driving their RV across the states. Every other year she writes a new addition to her book which is used in several graduate programs. I asked her how she was able to keep up with technology when she is on the road. Her answer....blogs. In her earlier editions of the book she spent a lot of time and money interviewing technology folks across the globe. Today, she relies heavily on blogs. As she travels the states, she stays up to date on emerging database technologies and case studies using her broadband mobile satellite dish. The blogs allow her to create a powerful network of top notch professionals whom she reaches out and collaborates with from the comfort of her RV.

Before I had this conversation, I read blogs but not religiously. On the way home I starting thinking about the conversation with Mary and came to the conclusion that there was a lot more value to blogs then I was aware of. Over the next few days I started researching blogs and seeking reasons why people choose to blog. Then I started studying blogs about enterprise architecture and was amazed to see so many relevant conversations happening in cyberspace. So I started subscribing to relevant content using Google Reader. In the past, I would buy and read book after book from Amazon to learn as much as I could about the topics that interested me. The down side of books is that they are based on the past where as blogs are based on the now. On occasion, I was lucky enough to attend some conferences where I would talk to as many people as I could to share lessons learned. The problem with conferences are two-fold. First, there is too much bias because of the amount of people who are associated with vendors and second, a lot of people there don't really have a clue and are just chasing the technology of the month.

After only a few weeks of reading blogs, it became real apparent to me why Mary was able to continue updating her book by the use of blogs. There are a lot of great minds out there sharing their experiences, refining other people's ideas, and giving writers feedback. Then I stumbled across a post where an architect described the reasons why he blogged (I can't remember who the author was). There were many valid reasons but one stood out for me. After a year of blogging the architect was able to look back over his posts and view his journey over time. That was intriguing to me. I was in the middle of launching a project that is transforming my company. We are implementing BPM and SOA. I thought that it would be a great idea to capture my journey. I also felt that I had a lot of good experiences that I could share with those who read technology blogs. So I started writing.

I have been writing for five months now and I have benefited from it in many ways:

1. It has taught me how to write better.
   
2. It forces me to research topics thoroughly.
3. I have built a network with some top notch people in the industry.
4. It allows folks at my work to see what my thoughts are on different topics (I lead the architect group)
5. I get feedback (good & bad) on my thoughts and opinions.
   
6. I am able to see other point of views. People tend to challenge ideas more readily in blogs then they would face to face.
7. Most importantly, I learn from other people's experiences

The last bullet is extremely important for me. I have been at the same company for 12 years. I have a perspective of the impact of decisions over a long period of time. Many bloggers out there like my friend Eric Roch, are consultants who have experiences that cross many companies. I have seen a company grow from an IT shop of 30 to a shop of 200. I have a ton of lessons learned on how to grow and evolve an IT shop. Eric gives me the perspective of how different companies have tackled similar issues (both successfully and unsuccessfully). This is one example of how blogging has helped me build a valuable network that I was lacking because I haven't changed companies in over a decade.

I get so much value out of blogging that I kick myself for not knowing about it earlier. I am now on a mission to bring Enterprise 2.0 technologies like blogs and wikis into the workplace so that our shop can share similar experiences within our own walls.

The architects who blog are an interesting group of individuals. They are passionate about their topics and many are extremely opinionated. We tend to argue over definitions, methodologies, and approaches. In reality, there is no right or wrong answers. The "right" answer often depends on a variety of factors including company culture, budgets, leadership, and the talent level of the team. With that said, I still get a lot of value from the back and forth arguing because I get to see things from various perspectives. One of my favorite articles was about how we successfully sold BPM & SOA to the business. Computerworld.com, IBM, and a few other web sites linked to it. On the other hand, James McGovern had this to say:

Sadly, I hate when other enterprise architects give out bad advice such as selling SOA to the CEO by tying it to cost/benefit when in all reality, a good enterprise architect would know that the CEO should stay focused on business strategy while his/her deputies should stay focused on business architecture. At no time should SOA be sold outside of IT. If anyone tells you otherwise, run in the opposite direction.

Like I said, what works at one organization, may not work at others. In my case, the CEO has claimed that this is the top priority in the company and has backed it with funding. Sorry for the "bad" advice. I do love James's blog though. He has a built a rare brand that combines technical expertise with an in your face delivery style. I am always happy when my posts make it by without showing up on his site!

I write about the technologies that I deal with at work like BPM, SOA, Virtualization, and Portfolio Management. I often write about controversial topics like open source and offshore development. Both of these topics tend to get people animated and generates a lot of conversation. This is also a big benefit for me. If I am trying to sell the value of open source at work, it is helpful for me to understand opposing views. I sure get those views from the comments on my blogs. The same for offshore development. Whether I like it or not, my company has made a strategic decision to offshore certain projects. It is my job to make it work. I have written various posts about this topic which is a great way to attract opposing opinions. Understanding opposing views helps me understand the type of resistance that I might face at work.

To wrap it up, blogs are changing the way the world gets information. We no longer have to be force fed information from vendors and paid analysts. Now we can collaborate with experts across the globe. Here are some of my favorites:

Andrew McAfee - Associate Professor at Harvard Business School
Michael Hugos - His blog on Computerworld
Nick Malik - Inside Architecture
Eric Roch - SOA Blog
Don Hinchcliffe - Enterprise Architecture
Todd Biske - Outside the Box
James McGovern - Enterprise Architecture: From Incite comes Insight
Dana Gardner - FASTForward Blog
Joe McKendrick - Service-Oriented Architecture

and my all time favorite...

Athena's Blogs about Cats and Dogs - My 8 yr. old daughters blog (story here)

Virtualization is another hot topic in IT today. It allows you to run multiple virtual or logical representations of physical machines, side by side on the same physical server. Many companies are putting strategies in place to consolidate servers and to reduce the cost of hardware, maintenance, power, and floor space. At my work we have a cluster of physical machines using VMWare that have allowed us to run 115 virtual servers on it. There is room for more and we will continue to move to that platform. Virtualization makes a lot of sense in the eyes of the system administrator.

So why is a software guy like me so excited about it? To me, it is much more then a way to control costs. It also allows us to be more agile, to react to capacity issues faster, deploy easier, and create faster applications. Allow me to expand on each one of these points. The following statements assume that you have a cluster of boxes with available capacity to add additional virtual machines.

Agile - How long does the procurement process take in your company? I have seen companies' server procurement cycles take from two weeks to six months. The norm in my world is about a month. A virtual machine can be created in 15-20 minutes without having to purchase anything.

React to capacity issues - On Friday at 10pm, your web site generates a ton of unexpected traffic which causes your servers to exceed their capacity and fail. Your systems administrator logs on from home and quickly adds five more virtual machines using a snapshot of an existing production virtual machine. In under an hour he has the system back up and running.

Deploy easier - Your application can be configured as a virtual appliance. This allows you to create a virtual machine that consists of the operating system and application software for all the tiers of your application and bundle it as a single file. Microsoft is leveraging this approach as a way to allow people to try out the latest version of Outlook without having to install hardware and software. Think about being able to deploy your multiple tier environment as a single file. Take that snap shot and deploy it at your DR site and you have knocked a huge chunk of time off your implementation phase.

Create faster applications - This is the topic that gave me the urge to write this post. Think about this architectural strategy for your web sites. Put all of your web servers, application servers, and database servers on virtual machines and create your virtual appliance. Since all of these virtual machines are on the same physical server, you could actually leverage the PCI bus instead of the Gigabit Ethernet. The PCI Bus is over 400 times faster then Gigabit Ethernet which should give you incredible response times for your application. What's even cooler, is that you can have your virtual web servers "sitting" outside the firewall in the DMZ while your application servers and database server is "sitting" inside the firewall. You read that right! Even though these virtual machines are physically installed on the same server, you can configure them to logically be located in different areas.

Think of all the possibilities. We all know the power of distributed systems. Distributed systems allow you to perform parallel processing across multiple nodes to achieve more work in shorter intervals. The downside of distributed systems is the cost of the physical servers and the management of software across the nodes. Enter virtualization. You can install several virtual machines at minimal cost and easily manage the software by updating one virtual machine and taking a snapshot. Then apply the snapshot to the other virtual machines.

To take that concept one step further, you can leverage this distributed model to create multiple virtual machines to act as an application server farm. If you are implementing an SOA and have an ESB in place, you can configure the ESB to load balance your services across these virtual machines to maximize your throughput.

The possibilities are endless. The point is that virtualization is more then just a great solution for consolidation and server management. Virtualization should be included as part of your application architecture strategy.

I stoled or as architects like to say, "reused" the title of this post from an interesting article in Computerworld by Steve Duplessie. The article starts out talking about how Web 2.0 will change our world and finishes with an example of a stupid business decision, hence the title, "You can't fix stupid". On the second page Steve has a point that gave me a reason to blog. Here is a quote from the article:

Free means crap, right? Wrong. How many of you keep Yahoo mail running on your BlackBerries along with Exchange because you know Exchange will be down sooner or later? When is the last time Google Mail was down? So my enterprise-caliber application running on an enterprise-caliber infrastructure with enterprise-caliber IT talent is less reliable than my free e-mail? Yep.

The "free means crap" perception is still shared by many people these days. Steve's email scenario is one of many real life examples that should help start putting this misguided perception to bed. I struggle to understand how smart people can refuse to at least investigate the possibility of leveraging Open Source software or Google Apps.

Many people are complaining about IT jobs moving offshore. One of the main reasons this is occurring is because IT is being asked to keep their annual budgets flat or even reduced year after year. This is extremely difficult to do when health insurance costs are going through the roof and the IT maintenance costs increase every year as we purchase additional products and services. The "easy" answer is cheap labor. Maybe it is time for an Open Source strategy. Look at how much money we are paying for Microsoft Office and Outlook. How much does it cost to purchase and maintain software like project management tools (project scheduling, portfolio management, requirements management, defect tracking, etc.)? Heck, their are even enterprise packages in the Open Source community for CRM, SOA, and BPM to name a few. Folks, there are alternatives out there that could save big bucks.

Does free mean crap? There are tons of quality free or inexpensive solutions in use by major corporations today. Let me ask you this. Does expensive mean good? Not necessarily.

I have written a couple of articles (here and here) recently about offshore development and how the success or failure of offshoring depends heavily on the US companies' ability to manage their offshore development partners. I may have come across as a strong supporter of offshore development, which was not my intent. My intent was to point out that if you are going to send work overseas you better have good processes and controls in place to manage it.

This takes me to my next point. I am a huge fan of agile development. One of the many things I like about agile development is that it does not require you to spend countless hours analyzing and documenting requirements and designs. Instead you cycle through many iterations of requirements, design, and prototypes with your key stakeholders and deliver functionality in small chunks.

Now lets look at the offshore model. Because of the communication barrier, the lack of business knowledge offshore, and often the limited experience level of the development team, the amount of documentation required to make this work increases immensely. Without the "war room" mentality of agile development, the projects tend to lean more towards a waterfall approach. Waterfall projects are rarely discussed in the same breath as "speed to market".

On my current BPM/SOA implementation, we have about a dozen projects that we wish to implement in the next 12 months. As we work with our SOA consulting partners (a US company with an offshore partner), we put together two different pricing models for our executive sponsor for each project. One price is for the most cost effective approach which leverages offshore development resources, and one is for the fastest to market approach which requires more on-site collaboration. So far the business has only chosen the speed to market solutions. Why is that you may ask? Well, all of these projects have a huge ROI if we replace our 20 year old business processes with new streamlined processes. Every day that we continue to do business with our legacy processes we are wasting valuable corporate dollars. For this reason, our sponsor is willing to pay a premium to get the work done quickly.

So if speed to market is your goal, agile development could be your answer. If you want to be agile and deliver functionality every 10 weeks or so, you must have great collaboration amongst your team and should not follow an extremely rigid methodology. In my opinion, this is when you should not rely on offshore development.

I came across this article in the WSJ where companies are testing job interviewing in the virtual world called Second Life. Huh? I thought this was another gaming environment where people could spend countless hours wasting their life away. So I Googled Second Life and looked for more business uses of this virtual world. There where way too many articles about virtual sex but I did find a few articles like this one about virtual classrooms in SL and this one where Dell set up Dell Island. As my research continued I stumbled across one grassroots initiative who started leveraging SL for streaming video of keynotes and allowed you to attend breakout sessions. Another article from Brandweek discusses marketers challenges as they try to use SL to promote brand awareness.

Perform this search and you can see countless businesses dabbling in SL ranging from recruiting, advertising, educating, collaborating, to countless other innovative ideas. Then I found this article that shows how the Weather Channel, IBM, and Cisco are leveraging SL to advertise and create brand awareness.

All of this is mind boggling to me. I can understand people using SL as a gaming environment. But for someone like myself who has a full time job, a family, and a life, how can you justify spending countless hours "conducting business" in a virtual world? As the head of the architecture team at my work, it is my job to learn about all emerging technologies. I am constantly studying topics like Web 2.0, Open Source, SOA, virtualization and best practices such as change management, project and portfolio management, and IT governance. I feel obligated to take a deeper dive into SL but after walking around SL aimlessly for 30 minutes I decided to let others do the research for now and I'll stick to reading articles on this topic for the near future. Besides, it is hard enough to get new initiatives going in the real world. I can't even imagine selling management on the virtual world!

I would love to hear from anyone who has some real experience using SL for business reasons.

Nick Malik has a great post on this topic. Here is how he defines the terms:

1. Top down - central group decides everything and the dev teams adopt them.
   
2. Bottom up - central group provides a directory and dev teams make whatever services they want. Dev teams go to the directory to find services they can use.
   

I am in the early stages of implementing a SOA. About five years ago we embarked on a project to create a component based architecture where we isolated the business rules as business components. Back then, we did not have a central group focusing on architecture. I was driving this initiative without the necessary authority to make it an enterprise solution. We successfully create a repository containing many reusable components. Another team bought in to the idea and started architecting their application in the same manner. In true Bottom Up fashion, they chose to create their own component library for their application specific business rules. They were able to reap some of the benefits of this approach but because we had no authority to govern this project we wound up with two separate repositories. This speaks to Nick Malik's warning that "Bottom Up SOA is harmful and should be discouraged".

Now, five years later, we do have a centralized architect group with the necessary authority to govern our SOA initiative. We will use a Top Down approach to ensure we don't relive the mistakes of our past. This works for us because we are a small shop (about 200 IT staffers). Development is done in three business units, two at corporate and one in Europe. Our approach is that the architect group controls our repository of objects and services. All teams can access the repository in read-only mode and submit candidates for consideration to be added to the library. If the artifacts meet our architectural standards then they will be added to the repository.

I believe Top Down SOA will work for us because of our size and because there is a limited amount of staff who have experience with SOA. If we were a large shop with several different groups actively working on SOA then this might be a major challenge. Bottom Up is a faster way to market but can lead to maintenance nightmares if any group thinks departmental instead of enterprise.

I would love to hear from those who have experience in either Top Down or Bottom Up SOA.

A few weeks ago I posted a few articles about Open Source (Still afraid of Open Source?, Eating my own dog food, and Open Source and loving it!). I have now been Microsoft-Free at work for about 7 weeks. I have also found solutions for almost all of the initial hurdles I encountered in the first week. Here is the list:

1. Email - I now have Thunderbird working flawlessly as my email client in sync with Exchange. I do need to talk to the Exchange admin to change a setting on the Exchange Server so I can use the Calendar functionality with Sunbird. I am currently use Webmail for my calendar.
   
2. Office - Open Office has worked well with Word, Power Point, Excel, and Adobe documents. I can use Wine to install Visio on my Ubuntu desktop. This doesn't allow me to be totally Microsoft-Free but there is no answer for Visio's proprietary format that I am aware of. This is not an issue with Open Source, the problem is that Microsoft doesn't use an open standard for their Visio product. Open Office Draw works fine for creating new drawings but can't import Visio documents saved in Visio format. I also downloaded OxygenOffice Professional that gives me the much needed templates and clip art that Open Office was missing.
3. Browser - I have been using Firefox at work for years so this a no brainer.
4. Printer - I do have one unresolved issue. I have an old HP Laserjet (about 8 years old). Although I can see the driver I can't get the printer to work. I have not invested a ton of time trying to fix it.

Before all of the Microsoft defenders start slamming me, let me put my disclaimers out. My goal of this article is to prove that people can be productive at work without the need of Microsoft software. I am not saying that because I can be productive that everyone should abandon Microsoft and start a project to implement Linux corporate wide. However, I do recommend to those who are open to exploring alternatives that they should start a small pilot project with a handful of desktop users. I think a 5-10 person pilot with Ubuntu or Mepis would be a great way to learn about the opportunities and challenges that an Open Source OS presents. This is low risk and high return. A pilot like this will give your IT shop an opportunity to try out alternatives without disrupting the day to day business.

When I first started my experiment I was trying to keep it a secret out of fear of attacks from angry Microsoft worshipers (especially from the admins and desktop support). What I am finding out is that most of the folks that I was hiding from are sick and tired of supporting Windows and are proponents of Linux. Several of them are using Linux at home. One of the guys I talked to has Vista and XP installed on his laptop. He swaps out the hard drive when switching between OS's. He is less then impressed with Vista and complains about the slow boot time (2 times slower then XP). I recently moved to a new office and a desktop guy saw my Ubuntu desktop when I was moving. I expected an ear full but instead the guy said he fully supports a move to Ubuntu and wished the company would move in that direction. These stories are coming from Microsoft certified engineers who have spent years supporting Microsoft tools. These stories are not coming from anti-Microsoft people who worship Linux.

There is one myth I would like to discuss. I keep hearing how difficult it is to install Linux. I have two comments about this:

1. I found the Ubuntu install to be quite simple. Maybe some of the older versions of Linux where cumbersome but the recent versions are very straightforward.
2. If an organization chooses to go with Linux on the desktop, trained professionals will be responsible for installing Linux. This is how Windows gets installed today. People tend to accept that fact that Windows is a simple install because they receive their desktops or laptops already configured. Is the Windows install really all that much easier then the Linux install or is it the fact that most people never have to bother installing Windows?
   

Once again, these are my observations. I have been using Windows for years. I don't hate Windows, although I am not a fan of Microsoft as a company. I do give Microsoft credit for creating a product that has changed computing forever. For companies with huge budgets it might make sense to continue down the Microsoft path. For small and medium sized companies with limited budgets, startups, and educational or government funded operations, I believe they should consider exploring alternatives. The worst thing that can happen with a small pilot is that you discover that Linux won't work for your organization. At least then you can sleep at night knowing you did your homework and made a strategic decision based on real information. One word of caution, though. If you take on a pilot, make sure you have a few people on the team who are not married to Windows or Linux. Get some folks with an open mind who are interested in the overall good of the company and are not married to a certain technology.

I posted this article called "Offshore blunders. Who is to Blame?" on CIO.com the other day. The story discusses a few case studies that I have personally witnessed over the years.

There are many reasons why offshore development fails:
* Resistance to Change
* Unrealistic Expectations
* Lack of repeatable processes
* Poor vendor management
* Poor vendor performance

Usually when there is a report of an offshore development project failing, the critics immediately jump on the anti-offshore bandwagon and declare that offshore development can't work. When you look at the reasons these projects fail (listed above) how many of these are the vendor's fault?

Resistance to change - This is the number one reason for failed offshore projects. Companies tend to ignore the basics of change management. The staff sees offshore as a threat to their jobs and becomes unwilling to cooperate and allow the vendor to be successful.

Unrealistic expectations - Some companies struggle to deliver so they think throwing projects across the ocean will solve their problems. If you can't manage projects onshore, how the heck do you think you can manage them offshore?

Lack of repeatable processes - Regardless of whether your vendor is CMM level 5 or ISO certified, your home based staff needs to have some form of process in place or your project will most likely end in a disaster. You still need to deliver the appropriate specifications to the vendor, have valid change control procedures, perform code and design reviews, and perform project management best practices to keep the project on schedule.

Poor vendor management - Shipping projects offshore may reduce the amount of development that you need to take on, but it increases the level of oversight that you must provide. Keep in mind that the vendor does not have the business knowledge that your staff has. If you let them make all of the decisions you are doomed for failure. Let them make recommendations, but approve all decisions.

Poor vendor performance - Ah, finally something I can blame on the vendor, right? Wrong! Who is responsible for selecting the offshore development team? That is the person who is accountable. This is no different if you performed a vendor assessment for a CRM package and you picked a package that did not meet the business needs. Is it the software companies fault? Will the CEO blame the vendor or will he hunt down the CIO?

Let me add that as a taxpaying American citizen, I don't like the fact that our beloved IT jobs are moving offshore. I can moan and groan about it all day long or I can figure out how to make it successful so I can satisfy my users' needs. As a leader in IT and a shareholder of my company, I understand the economics of offshore development.

IT is not the only industry that has been losing jobs overseas. Manufacturing and engineering jobs have been leaving the country for years. It just took a while longer for the IT industry to follow suit. Until our government gives companies incentives to keep jobs at home (don't cross your fingers on seeing this any time soon), jobs will continue to move offshore.

The next time you see an offshore development project fail, before you post your next "I told you outsourcing doesn't work" article, research the reasons why it failed. The odds are that they failed for one or more of the reasons I highlighted above. If that is the case, then who is really to blame?

I just read this article from eWeek which talks about who actually adopts Web 2.0 technologies in the workplace. The myth is that only the Gen-X and Gen-Y employees will use Web 2.0 but the reality is that age is not a factor in the adoption. It is upper management that typically does not embrace the technology while most everyone else does. Here is an excerpt from the article:

TobyRedshaw, chief technology officer of Motorola, said that rather than an age bias, he noticed more of an executive level bias to collaborative efforts: the higher up in the company's hierarchy the less social networking technologies get used. "That's a good thing," he said. "The real work gets done not in the board room."

So the question is, if the executive level is bias towards Web 2.0 technology, how can you get the backing you need to get a Web 2.0 initiative on the company's IT priority list? The answer is start small. Years ago when open source was still a mystery to most executives, I faced the same scenario. Instead of trying to sell people who were dead set against something that they didn't even understand, I took a different approach. One of my teams had been researching Linux (in their spare time) for a long time and were chomping at the bit to prove its worth. After failing to get any buy in from anybody in management and being looked at like we had a third eye in the middle of our head, we went into stealth mode and created our own proof of concept project that was low profile. To make a long story short, we built a low cost system that outperformed our existing production system for a fraction of the cost. We then went old and sold our ideas that were backed up by performance and financial data. The sale was a no brainer which eventually led to several other open source wins down the road.

This plan can work for Web 2.0. Get a group of early adopters together and implement a few Web 2.0 technologies like wikis, blogs, document tagging, etc. and measure the benefits. Once you have most of the major kinks ironed out, invite others to participate. Once you have data to prove your business case, then go to the senior executives and sell them on Web 2.0. The senior executives are typically very smart people who understand a good business case when they see it. The further up the chain they go the more focused they are on the financial aspects of the business and they tend to get further removed from technology. It is your job to show them the value but unless you have an incredible power to persuade, you usually need some numbers and/or a viable case study to sell them.

The beauty of this opportunity is that you can rely totally on open source technologies to put your Web 2.0 pilot project in motion and you don't need to spend much on hardware (if at all). Low cost, low risk, and high potential benefits. Why aren't you starting your Web 2.0 pilot today?

A colleague of mine uses a great analogy to explain the purpose of an ESB (Enterprise Service Bus). He starts by reminding us of how PCs work. The PCI Local Bus within the PC is a high speed channel for providing a centralized mechanism for connecting multiple hardware components within a PC. Without the bus, the inside of your PC would look like a spider web of wires with each component having to connect to all other components. The following diagram shows a simplified view of a PCI local bus.


The ESB performs a similar function within a service oriented architecture (SOA). When architected correctly, the ESB becomes the centralized mechanism for controlling all messages and events that occur between the various layers of the architecture. The ESB centralizes security, routing, transformation, invocation, and service management. Look at the diagram below and see how it looks similar to the PCI local bus.


I have seen a lot more head nodding and a lot less glass eyes when using this analogy to explain the role of the ESB. Give it a try.

Nick Carr who is famous for his book "Does IT Matter" has a new article about Open Source, "The Ignorance of Crowds".

This article is a very interesting read and talks about both the good and the bad of Open Source. After reading the article, I believe what Nick is trying to say is that good Open Source projects are not as open as you might think. Here is an excerpt from the article:

.... the open source model — when it works effectively — is not as egalitarian or democratic as it is often made out to be. Linux has been successful not just because so many people have been involved, but because the crowd’s work has been filtered through a central authority who holds supreme power as a synthesizer and decision maker. As the Linux project has grown, Torvalds has gathered a hierarchy of talented software programmers around him to help manage the crowd and its contributions. It’s not a stretch to say that the Linux bureaucracy forms a cathedral that coordinates the work of the bazaar and molds it into a unified product.

He also mentions that Open Source is not where creative ideas come from but where people take a great idea and refine it. I not sure I agree with that but I do see his point of view. Regardless, Open Source provides alternatives to buyers who traditionally were at the mercy of billion dollar software giants.

I have seen some people comment on the article. A few of them perceived the article as a bashing of the Open Source community. I didn't see it that way. I saw him pointing out some of the challenges of peer production and the need for some form of governance.

What are your thoughts?

The supply and demand for SOA and BPM tools and implementors is way out of wack. On the tool side there are way too many vendors and products and you will continue to see the big guys like IBM, BEA, Oracle, HP, and Microsoft go shopping. The implementor side has a different twist to it. There are many niche players who have staffs that range from 100 to 1000 people. These companies have been implementing SOA and BPM before they became the hottest topic since Paris Hilton's jail sentence. Now that the demand is so high, they are having problems staffing up.

I work at a medium sized company. We have been looking for a partner to help model our current and future state processes for a few areas in our business. The big guys like Accenture, IBM, and Bearing Point turned us down because the contract was too small. The medium sized companies are turning us down because they are out of resources. We had a bad experience with a boutique vendor on our first business process assessment so we are staying away from the small guys.

Our SOA partners are extremely busy and in high demand. We have over 20 projects that we need help with and we want to work on three or four of them at a time. They will soon be out of resources. So where am I going with this?

Everyone already knows that there will be mass consolidation as BPM and SOA pure players get gobbled up by the the billion dollar companies. The pure players are having problems competing against the stack players because more companies are using BPM and SOA together. What is not being talked about is the consolidation of the implementors. Accenture, Bearing Point, and others are going to start buying many of these niche players so they can go after the mid market dollars. The niche players are going to need to expand at rates that they can't manage. I am not a wall street analyst but something tells me that there is a lot of money to be made if you own stock in the right niche player.

Another trend that I am seeing is private equity companies buying up successful companies with plenty of cash flow. Look at Doubleclick. Hellman and Friedman bought them in July '05 and sold them for more then a billion in profits in April of '07. I can see this trend happening in the SOA and BPM consulting space. Private equity firms like H&F can buy these companies at a decent price, cut out the fat, stream line the operations, and flip them to the big industry leaders as they start competing for these types of companies. Look at the crazy shopping sprees that Google, Yahoo, and Microsoft are in the midst of. They are overpaying on many Web 2.0 startups just to beat their competitors to the punch. I believe that this same trend might happen in the next year or two in the SOA/BPM implementation space.

I would like to hear from those of you that work as consultants in BPM and SOA. Am I on to something or am I way off track?

I posted my opinion on CIO.com (The Role of the Enterprise Architect). Here is a summary...

The EA should know how to code and should have spent many years developing, designing, and managing technical projects. So when I say that the EA should not be coding, that does not mean the EA doesn't know how to code.

With that said, the EA's focus should be on strategy and vision. The architects below the EA should turn the strategy and visions into reality.

I have read many blogs that argue both sides of this question. James McGovern's article states:

You probably have ran across architects that don't code. Hopefully you aren't one of them...

I am hoping that he truly means architects and not Enterprise Architects (EA).

Colin White has a good article called Architects don’t code, they whiteboard. I tend to agree with his stance on this topic.

Here is another article by Simon Brown who has a similar opinion.

On Bill Barr's blog, Agile Enterprise Architecture, Bill phrases it slightly different. He says that EAs should not write production code but...

When it comes time to talk to people about a new idea, get feedback and even sell the idea, that's when a page or two of some clearly written examples are worth a thousand powerpoint slides.

What do you think?

I wrote a few articles about my recent switch to Ubuntu and my position on open source. Today I stumbled upon Alan Pope's article called "The Truth about Switching".

Alan's first bullet goes like this...

01. People will ridicule you for using Ubuntu

I have witnessed this first hand. A few people at work have busted my chops (in a nice way) for switching. Of course, they have never used Linux themselves. A fellow blogger took some shots at me and some how ended by comparing the open source movement to a communist revolution. I was almost ready to raise the terror alert to Red.


With all joking aside, I have found a few spare hours in my busy day to find additional open source products for my toolbox. Today I downloaded the Open Source Visio equivalent called Draw from OpenOffice.org. Draw worked great and was able to import files from many different formats. A cool blog that I subscribe to had a funny article about Visio and listed a few other alternatives.


I am currently working on a big BPM/SOA implementation. The team has a ton of requirements in a Word document that has use cases mapped to each requirement. This will quickly become a pain in the butt to manage and screams for a requirements management tool that will feed into our Mercury testing tools. Unfortunately, I have no budget for a requirements tool. Can you say Open Source to the rescue? I have started researching requirements tools and expect to have a solution in place and running by next week. The total cost will be...you guessed it...Zero dollars.

So let's look at all of the open source components that are being used on this project. First we will start with my desktop. I am using Ubunto, Open Office (for word, excel, power point, and visio), OpenWorkbench (for MS Project), and Firefox for my browser. Our BPM/SOA stack are all BEA products that leverage Eclipse. Our source control, defect tracking, and requirements management tools are all open source. We have the option to run our stack on Linux or Windows. We have more expertise on the Windows platform so we will stick with Windows there.

One place that I believe that Open Source really shines is in IT tools. In my lifetime, it has been very difficult to get funding for software development tools. The business invests so much money in infrastructure, CRM, financial systems, HR systems, and other enterprise initiatives that it is usually challenging to justify spending $100K-$300K on SDLC tools like portfolio management suites & CMDBs. Development tools like Reflection (a terminal emulator), Toad (a SQL tool), and many others are expensive. Multiply the cost of the license by your number of developers and the costs can get astronomical. Tools like these are no-brainers for open source alternatives. They are low risk replacements and save thousands of dollars.

That's my rant for today. I'll be back to share my experience of our new Open Source requirements tool. I have already found a few tools that have a decent sized community. They output xml which we can feed into our Mercury suite. This will eliminate the need for me to pay for licenses for our outsourcing partners. Stay tuned.

In a previous post (Another Benefit of SOA - Career Path) I talked about how SOA can create a career path that consists of specialized technical jobs.


We just launched the requirements and development stage of our BPM/SOA implementation. We partnered with my buddy Eric Roch and company to assist in the implementation. We brought in specialists for each layer of the architecture. The specialists include a Web Designer for the presentation layer, a Process Analyst for the business process layer, SOA architects, a project manager, and my own architects (Software, Data, Network, and Test) who know the business and the existing infrastructure.

The first day was for introductions, general admin and housekeeping tasks, and a kick off. Today was day two. The first draft of the UI and the business process model was completed today! This was accomplished because we specialized or to put another way, we had experts assigned to specific technologies. My architects are incredible talents but they are not experts at UI development or business process modeling. Had I tried to tackle this internally it would probably have taken us 2 weeks instead of 2 days.

Another reason for the success is that the resources are 100% dedicated to the project and live in a "war room" where they have access to all of the people they need. We bring users and technicians into the war room when needed and never have to worry about meeting schedules. We will also follow an iterative approach and deliver weekly builds so the users can touch and feel the application early and often. This allows us to make changes on the fly and keep the users involved throughout the life cycle.

All that in the first 2 days! I will recap our progress each week and share the good, bad, and ugly as we encounter it.

5. Your consultant's one month contract ends tomorrow and his PC just arrived from desktop services.

4. Your company is rolling out its proprietary CRM solution.

3. There is a large line of people waiting on the fax machine.

2. By the time your new server gets installed it is off of maintenance.

1. Your company buys a 30% stake in a paper manufacturing company as a way to combat the high cost of generating mounds of paper reports each day.

So many exciting changes are happening in the world of IT today. Look at all the hot topics from around the net that we read about each day:

• Virtualization
• Web 2.0
• SOA
• BPM
• Saas
• Outsourcing
• Open Source
  
• Mobile Computing
• Event Driven Architectures
• Mashups
• Collective Intelligence
• Super fast chip technology
  

What does this all mean to the future of IT? Most of these technologies (if done right) will impact the workplace in a variety of ways. Some of these technologies will enable people to be fully functional from remote locations (Mobile Computing, Web 2.0, Mashups, Collective Intelligence). Some of these technologies will eliminate human processes both in the business (BPM, SOA, Event Driven Architectures) and IT (Virtualization, Outsourcing, SaaS). Others will make us less dependent on the big vendors (Open Source, Virtualization). Then there are the advancements in chip technology and memory which can really rock our world. Can you say diskless PCs?

So as I read article after article, day after day, I begin to wonder what this all means to the working people in IT. I can be pessimistic about the future of IT and paint a picture that looks like this:

• Mass virtualization - elimination of many systems administration and networking jobs
• Mass Outsourcing - Most of development farmed out due to cost effectiveness of remote development (both onshore and offshore)
• Less internal development - Reduction of development jobs due to effective end user tools (BPM, Mashups, Web 2.0), external development (Outsourcing, SaaS), and improved collaboration and automation (Collective Intelligence, Event Driven Architectures, SOA)
  

Or I could take an optimistic view of the future of IT:

• Business Alignment - business heavily relies on IT for automating and streamlining business processes (BPM, SOA, Event Driven Architectures)
  
• Enterprise architecture - Architecture becomes key differentiator and enabler
  
• Rapid development, less maintenance - Tools (Mashups, Web 2.0) and architecture provide a platform to rapidly deploy. IT delivers loosely couple services, not proprietary monolithic applications, which reduces maintenance and allows for more new development.
• Cost effective computing - Business looks to IT as a partner and an enabler instead of a cost center. IT makes the business efficient (Mobile Computing, fast chip technology, collective intelligence) while being cost effective (SaaS, Virtualization, Out Sourcing, Open Source, BPM, etc.).

My belief is that it will come down to the IT leadership, mainly the CIO. The CIO needs to measure and promote the value of the IT department as we move through these dramatic changes in technology over the next few years. He or she must be a trusted business partner to the CEO, CFO, and COO. IT should be proactive and start implementing these technologies (where it makes sense) to enable the business, as opposed to waiting for the business to tell IT to implement these technologies to reduce costs and headcount.

So what is your view of the future of IT? Is it pessimistic or optimistic? If it is pessimistic, what are you doing to change it?

I recently have experimented with Ubuntu at work and wrote an article called "Eat my own dog food" about my experience. I got into a philosophical debate about the value of open source with one of my readers and also was the recipient of smears and smirks from a few folks at work.

Obviously there are a lot of folks in IT who are not doing their homework when it comes to Open Source. In this post I will educate those who haven't been paying attention to the monumental shift in acceptance of Open Source technologies over the last few years.

So where do I start? For those who still doubt and/or dislike Open Source, here is the definition of Open Source from www.opensource.org

"Open source is a development method for software that harnesses the power of distributed peer review and transparency of process. The promise of open source is better quality, higher reliability, more flexibility, lower cost, and an end to predatory vendor lock-in."

For the uninformed, Open Source is more then just Linux on the desktop. Ok, enough housekeeping.

Now let's dive into how companies are making strategic business decisions to embrace Open Source technologies. In this article from CNet, Forrester Research states that "over 60 percent of 140 companies surveyed plan to use, or are using, open-source products". Many new startups are leveraging open source to reduce startup costs and improve speed to market. The article continues by saying, "By tapping into the open-source world, fledgling software outfits can assemble their software products from freely available components". Continuing further through the article they point out how "established software companies, such as BEA Systems, Computer Associates International, IBM and Novell, have spearheaded open-source projects as a way of vetting new code and getting their products into the hands of potential customers."

This is a very important point. Many of the people who mock Open Source are using it in the products and services they use everyday. Google and Amazon both run on Linux and Yahoo runs on BSD. IBM is a big believer in Linux and both IBM and BEA leverage Eclipse for their development environment. Go to this page and you will see Oracle pushing Python, Ruby, and many others. So if using Open Source is strategic for billion dollar companies like IBM, Oracle, and BEA, why do I get crazy looks when I mention it at work or on this blog?

Here is another believer. Researcher IDC states that Open Source is "...the most significant all-encompassing and long-term trend that the software industry has seen since the early 1980s and predicted it would fundamentally change the value proposition of packaged software for customers." But don't stop there. Take a look at what is going on around the world. Apache is powering 58% of all websites. Firefox has increased its market share by over 43% in the last year up to 13.67%. IE is down to 79% from 99% a few years ago. Some universities are moving to gmail and other free alternatives because they are tired of the costs and the headaches that come with trying to maintain and secure Outlook. IBM just endorsed MySQL. Dell is now shipping laptops and PC's with Ubuntu. I could go on forever but you get the point by now.

What is even more interesting to me is that with the adoption of SaaS, Web 2.0 technologies, and services, the relevance and the dependency on operating systems is dramatically decreasing. Once you start running your critical applications using the SaaS model or you start deploying your applications with robust UIs in a browser, who really cares what the OS is any more?

You can ignore Open Source but it isn't going away. As leaders in IT, we have a responsibility to the folks who write us checks to put aside our personal preferences and pursue technologies that make good business sense. For those companies that put together 2 and 3 year plans, you should at least have a strategy to investigate opportunities to leverage Open Source and spend a few R&D dollars to understand it better.