Welcome to the Linux in the Enterprise column! This column will focus on the use of Linux and Linux-based application in enterprise settings.
This series will help you explore ways to get Linux-based systems and Linux-based applications in the door of your company painlessly, and how to make a big, positive impact once you get past the door.
Among the topics I'll cover in this series are:
After that long list I'm sure you're wondering who I am and what qualifies me to speak about Linux in the enterprise. I'm a systems-admin-programmer-security-and-network-designer type who has spent almost 20 years doing everything from running large collections of VAXes and Suns through bringing the Internet to Wall Street back in 1991 when I put the first bank on the Internet. I'm also the author of the O'Reilly book Building Linux Clusters, which is an introductory, hands-on volume about building Beowulf-type clusters out of commodity hardware.
During normal business hours, I'm the chief technology officer of an Internet startup called TradingNews, which specializes in financial news based on technical analysis--a form of stock performance analysis. About 95% of the infrastructure that my staff and I have designed and built is based on Linux and uses open source software such as Apache, PHP, and Perl to make everything work.
One of the first tasks facing a Linux enthusiast is getting a Linux box in the door. Just because Linux is portrayed as the greatest thing since sliced bread in the press doesn't mean that your IT manager is going to give you the green light to put a Linux box on your desk or in the your company's data center.
If you're working at an Internet company, getting Linux in the door is probably easier than if you're at a Fortune 500 type of establishment, but in either situation, making the case for Linux as an enterprise option will take planning, persistence, and willingness to personally do the work to make it happen
Many technologists try to get new things in the door by proclaiming their glories rather than making a solid, supportable business case for them: I've done it myself, after all, I'm the technology guy, these management suits should listen to me, what do suits actually know about technology, anyway?
Right? Sound familiar? The Dilbert-inspired possibilities are endless...
One of the traps that anyone with a good idea falls into in the corporate environment is, unfortunately, an excess of enthusiasm. IT managers are used to being peppered with "good ideas" from well-meaning staff members and end-users who think that they know how something should be done. Technology problems in the minds of most IT management are a lot like the weather: Everyone complains about it, but no one does anything to change it. In their day-to-day existences, managers hear a lot of complaints, hear lots of self-proclaimed "good ideas" on how things "should" be run, but at the end of the day, there is often no one willing to own a problem and manage a solution.
This is where a solid Linux business plan can help you get your ideas implemented, as long as you are willing to do the work, and where others will fail because their proposed solutions to problems won't pass corporate muster.
Writing a business plan for a Linux-based technology solution doesn't have to be as complete as one you'd use to try and get a startup funded, but it must tell a convincing story. You want management to understand why your idea is right for the company in terms of the problem it solves and clearly show where the "value proposition" is in terms of "where does it save money in the firm's bottom line?".
A good business plan has seven major elements:
Let's look at each of these sections and see what they mean, and how they can be used to sell the use of Linux in your company.
A problem description or business need
This one is pretty straightforward. What problem do you think needs solving where a Linux solution would fit in? When proposing a solution, keep your targets very well defined. Don't overreach. If there is a need for a robust file server that can serve Windows machines, Macintoshes, and other Unix machines, stick to pitching a file server. Don't throw in all of the other wonderful things Linux can do for the organization. There'll be more than enough opportunities should you pull off the first project.
Keeping the problem description simple also focuses the attention of the people you're pitching your idea to and doesn't muddy the waters with unnecessary details.
A proposed solution to that problem or business need
Here too, describe your proposal in simple, direct terms. If you are pitching the use of Linux as a universal file server, talk about it in terms of a low-cost system running the Linux operating system and concisely describe the features that you plan on implementing. Brevity is the soul of wit, and simplicity is the key to keeping the attention of your audience. Don't overreach by adding too much detail.
A listing of the costs associated with the solution
How much will your solution cost? Be specific. List the components that you will need, including people to manage and run it, any data center or other space you will need, and networking or other connectivity costs. If you don't know what something will cost, list it as a line-item anyway and list its cost as "TBD" (to be determined). Then ask for the help of the management in determining costs that you are not privy to. Including the folks you are pitching in your plan is a clever tactic that often lets them know that you are a "team player." Make it clear that you're not above asking for their help, and, most importantly, you're not trying to do an end-run around them.
Make sure you take into account the total cost of ownership of your solution. How much is the initial hardware? Will it need to be upgraded or replace in a year? Do you need to have a backup/spare system in case of failure? Do you need access to external services that have variable costs (such as phone lines or network circuits)?
Description of competing solutions
This is perhaps the most important section of a business plan. Very few organizations will fund an effort without knowing if there are other ways to accomplish the same goal and how much those other solutions might cost. Obviously, you want to make your Linux-based solution the obvious and easiest, "no brainer" choice, but you should make an honest effort to explore the product space so that you know all of the players.
Of course, if there are no other competing solutions in the area you are describing for your Linux solution, say so. But, make sure you are correct in your assertion; if you're wrong you will hear about it and will probably have a hard time getting the ear of management again.
When describing competing solutions to the one you are proposing, keep your descriptions short. List the key features of the competing product and list the features that it is missing. Above all, resist the temptation to bash other people's products. It's bad form and doesn't help your case. This should not preclude you, however, from pointing out how expensive competing solutions are. In fact you should list the total cost of ownership, including software licensing (including per-user costs where appropriate), hardware costs, annual maintenance for both software and hardware, and upgrade costs for each competing solution. When commercial proprietary solutions are compared to the total cost of ownership for Linux solutions, the Linux solution will often win hands-down.
A description of the growth possibilities
Does your proposed Linux solution work for more than one group, location, or organization in your company? If so, this is the place to point that out. Saving money in one group or organization is a good thing--if you can divine a way to save big bucks for more groups in your company, you can become a real hero.
Another thing to consider is whether or not your proposal could be "productized" and sold as a product or service to another company. This may not be in the overall business plans of most companies, but it is something that might be worth exploring as a potential revenue opportunity.
As part of a business plan, you don't have to provide an MS Project style project plan, but you should make sure that your implementation plan clearly spells out how your project will be rolled out. You should also be ready to draw up a full project plan if management wants to see all the dirty details of how your implementation would be carried out.
Make sure you cover all of the areas that your project touches. For example, if your Linux-based service will need modem lines, note this as a requirement that will have to be dealt with. If you need data center space, this will need to be accounted for in terms of setup, rollout, and so on. The implementation plan should also attach rough numbers in terms of personnel and number of hours that will be required for implementation. Don't forget to include people who might not work directly in your area, such as the installers who might install the modem lines mentioned previously.
What's the exit strategy?
Is this proposed solution something that you will run forever? Or, will it be handed off to some internal or external support group? How will that be handled? What kinds of support mechanisms will need to be built to allow your solution to be run by someone other than you? Having an exit strategy defined will show that you are thinking beyond just getting approval for your project and this can make a big impression
Having a good idea is only a starting point on the path to getting your idea implemented. The major point to take away from all of this is that the process of selling a new idea has less to do with what the idea is, and more with how it is presented and executed. Projects, Linux or otherwise, succeed because someone has an idea that is well presented, and takes ownership of the process from idea to implementation.
The process of "Linux World Domination" is a slow, grinding one where we must work in well planned, calculating ways to ensconce ourselves in the very inner workings of enterprise computing. If you make your case clearly and in a way that "traditional" business people can understand, showing off what Linux can do will be an easy sell, rather than a long fought battle.
In coming columns, I'll cover the topics presented in the series overview. If there are other issues pertaining to the use of Linux in enterprise that you think need to be covered, please let me know and I'll try to fit them into the series.
Copyright © 2009 O'Reilly Media, Inc.