Enterprise Initiatives

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.