The Linux operating system materialized through the work of Linus Torvalds, a Finnish student who introduced the first release in 1991 as an open source version of UNIX for x86 PCs. Although it wasn't the first open source version of UNIX, the unique advantages of Linux soon attracted a following, and it quickly emerged as a viable operating system alternative. The combination of x86-based virtualization and the widespread adoption of Linux eventually opened the door to a new era of business computing, fueling major changes to today's business information technology landscape.
Seven keys to success:
- Define business level objectives.
- Survey the application landscape.
- Develop a scalable infrastructure blueprint.
- Identify the right project.
- Conduct pilot studies.
- Start the production rollout.
- Transition to continuous process improvement.
Today almost every organization has open source technology somewhere in their IT environment, usually in the form of Linux. For example, Linux provides the underlying plumbing for much of the Internet and World Wide Web. In short, Linux has arrived as a mainstream operating system for organizations everywhere and it now plays an integral role in business computing.
While Linux has become a mainstream business technology, it's not foolproof. Successful Linux migrations should be well planned and deliberately executed. Although there's no real substitute for qualified and experienced Linux professionals - with basic IT competency your organization can follow these steps for a successful Linux migration.
1. Define Business-Level Objectives
To begin, you should understand your organization's business strategy. Find a pragmatic balance between the applications that represent parity services for your organization and those that serve your business strategy and provide a competitive advantage. From there, you can define your business-level objective and align your business needs with your IT capabilities and expected workloads. Doing this work at the outset helps you to ensure flexibility, stability, and sufficient performance to meet your business objectives at the lowest cost of ownership while avoiding vendor lock-in.
To begin, you should understand your organization's business strategy. Find a pragmatic balance between the applications that represent parity services for your organization and those that serve your business strategy and provide a competitive advantage. From there, you can define your business-level objective and align your business needs with your IT capabilities and expected workloads. Doing this work at the outset helps you to ensure flexibility, stability, and sufficient performance to meet your business objectives at the lowest cost of ownership while avoiding vendor lock-in.
2. Survey the Application Landscape
Next, survey your application landscape. At one time, not every application could be moved to Linux, so you didn't have the option of skipping this step. However, virtually all applications today run on Linux or have suitable Linux equivalents. Nevertheless, this important step lets you rationalize your application environment: separate the applications that perform useful work from the applications that consume resources but are never or rarely used - also known as "shelfware."
Next, survey your application landscape. At one time, not every application could be moved to Linux, so you didn't have the option of skipping this step. However, virtually all applications today run on Linux or have suitable Linux equivalents. Nevertheless, this important step lets you rationalize your application environment: separate the applications that perform useful work from the applications that consume resources but are never or rarely used - also known as "shelfware."
In addition to eliminating shelfware, you want to cull overlapping and redundant applications. Again, they take resources without advancing your business-level objectives. Finally, this gives you an opportunity to identify and document the interrelationships between applications and systems so you understand the various dependencies between them, such as applications that require data processed by other applications.
3. Develop a Scalable Infrastructure Blueprint
If, after you examine your current application environment, you find that you can directly apply Linux and open source to your business and its computing requirements, you should begin developing an appropriate Linux infrastructure blueprint. Because Linux and open source have spawned new approaches and methods for deploying your application infrastructures, you have a surprising number of choices. At this point, you want two things from your infrastructure: a solid, reliable base on which to run your applications and - since every business intends to grow - a scalable, flexible, extensible, and dynamic platform that can grow and change with your business.
If, after you examine your current application environment, you find that you can directly apply Linux and open source to your business and its computing requirements, you should begin developing an appropriate Linux infrastructure blueprint. Because Linux and open source have spawned new approaches and methods for deploying your application infrastructures, you have a surprising number of choices. At this point, you want two things from your infrastructure: a solid, reliable base on which to run your applications and - since every business intends to grow - a scalable, flexible, extensible, and dynamic platform that can grow and change with your business.
4. Identify the Right Project
This step is more complicated than merely choosing one of the applications from the first step. For this, you'll need your financial analysis and management skills. To move forward, secure management commitment and executive-level sponsorship from the outset. You don't want to start this level of infrastructure change without support from top management and a specific, named champion at the top. Generally, it's easiest for you to secure this level of management support through an objective financial analysis that documents proper validation and justification for the business-level objectives you identified in the first step. You'll need to identify the business drivers and assess the return on investment (ROI) and total cost of ownership (TCO) considerations and implications, making sure to document both the hard and soft dollars involved.
This step is more complicated than merely choosing one of the applications from the first step. For this, you'll need your financial analysis and management skills. To move forward, secure management commitment and executive-level sponsorship from the outset. You don't want to start this level of infrastructure change without support from top management and a specific, named champion at the top. Generally, it's easiest for you to secure this level of management support through an objective financial analysis that documents proper validation and justification for the business-level objectives you identified in the first step. You'll need to identify the business drivers and assess the return on investment (ROI) and total cost of ownership (TCO) considerations and implications, making sure to document both the hard and soft dollars involved.
5. Conduct Pilot Studies
Next you'll begin the technical work. Surprisingly, the success of the migration rollout depends not only on the organization's understanding of the importance of Linux and open source but also on all the ramifications of the technical changes facing the company. To that end, you'll want to conduct pilot studies and build appropriate interoperability labs that will provide the necessary training, usability studies, and technical validation to ensure project success. This is your first chance to discover the technical and operational issues that could delay or derail the project. (If your migration project is destined to be delayed or canceled completely, it's best that you discover it during the pilot study before you commit to the full expenditure.) To reduce the likelihood of problems leading to delay or failure, you'll also want to set up and test ongoing project management and risk management processes. This includes assembling your application testing labs, refining your change management processes, and initiating training and team building efforts.
Next you'll begin the technical work. Surprisingly, the success of the migration rollout depends not only on the organization's understanding of the importance of Linux and open source but also on all the ramifications of the technical changes facing the company. To that end, you'll want to conduct pilot studies and build appropriate interoperability labs that will provide the necessary training, usability studies, and technical validation to ensure project success. This is your first chance to discover the technical and operational issues that could delay or derail the project. (If your migration project is destined to be delayed or canceled completely, it's best that you discover it during the pilot study before you commit to the full expenditure.) To reduce the likelihood of problems leading to delay or failure, you'll also want to set up and test ongoing project management and risk management processes. This includes assembling your application testing labs, refining your change management processes, and initiating training and team building efforts.
To move forward, secure management commitment and executive-level sponsorship from the outset. You don't want to start this level of infrastructure change without support from top management and a specific named champion at the top. Linux and open source adoption requires forethought on how to manage logistics such as scheduling servers and data to be migrated, notifying users of planned outages, responding to user inquiries, and having processes to resolve reported software problems and errors.
6. Start the Production Rollout
Once you have the pilots and labs working and generating feedback, it's time to start the production rollout. You have a couple of options. You could try a "Big Bang" rollout, in which your company attempts to do it all at once, but experts don't generally recommend that approach. Instead try a staged, controlled, and well-managed rollout. Linux and open source adoption requires forethought on how to manage logistics, such as scheduling servers and data to be migrated, notifying users of planned outages, responding to user inquiries, and having processes to resolve reported software problems and errors. You may still encounter some problems, although you should already have caught most of them in the previous step. In addition, you'll want to automate as much of the rollout as possible. You can do this by using standard application and system configurations, plus a standard operating environment, which should be your selected Linux distribution. In some cases, you might choose to run the new and old systems in parallel, although this requires more effort and entails some increased risk, particularly the risk of inconsistent data.
Once you have the pilots and labs working and generating feedback, it's time to start the production rollout. You have a couple of options. You could try a "Big Bang" rollout, in which your company attempts to do it all at once, but experts don't generally recommend that approach. Instead try a staged, controlled, and well-managed rollout. Linux and open source adoption requires forethought on how to manage logistics, such as scheduling servers and data to be migrated, notifying users of planned outages, responding to user inquiries, and having processes to resolve reported software problems and errors. You may still encounter some problems, although you should already have caught most of them in the previous step. In addition, you'll want to automate as much of the rollout as possible. You can do this by using standard application and system configurations, plus a standard operating environment, which should be your selected Linux distribution. In some cases, you might choose to run the new and old systems in parallel, although this requires more effort and entails some increased risk, particularly the risk of inconsistent data.
7. Transition to Continuous Process Improvement
After you deploy, you'll transition to continuous process improvement and consistent management and operational processes. Both the business and technology groups must take all reasonable steps to use established methods of success, accurate financial analysis, and process improvement and controls. That means identifying process improvements, practicing consistent management, and applying proven best practices.
After you deploy, you'll transition to continuous process improvement and consistent management and operational processes. Both the business and technology groups must take all reasonable steps to use established methods of success, accurate financial analysis, and process improvement and controls. That means identifying process improvements, practicing consistent management, and applying proven best practices.
Finally, don't forget the "Golden Rule of Infrastructure Management" - simple and well-designed infrastructures shouldn't require extensive management tools. Don't try to compensate for a poor design and implementation with extensive management tools, because even the best management tools can't simplify a poorly designed infrastructure.
Linux Offers Choice
In the end, a Linux migration and adoption is a journey, not a destination. And although it may seem that transitioning away from your current computing environment is too daunting, this is truly an opportunity to build a better application infrastructure for your organization's long-term success. However, Linux and open source won't magically create a self-governing computing infrastructure. You should still make every effort to enforce the management controls and processes that allow open source computing to thrive. Adopting industry standards increases your ability to take advantage of future innovations. By using industry standards as a basis for selecting the best solution for your environment, you will find that those solutions will provide the right balance between cutting-edge innovation and proven industry approaches and strategies.
In the end, a Linux migration and adoption is a journey, not a destination. And although it may seem that transitioning away from your current computing environment is too daunting, this is truly an opportunity to build a better application infrastructure for your organization's long-term success. However, Linux and open source won't magically create a self-governing computing infrastructure. You should still make every effort to enforce the management controls and processes that allow open source computing to thrive. Adopting industry standards increases your ability to take advantage of future innovations. By using industry standards as a basis for selecting the best solution for your environment, you will find that those solutions will provide the right balance between cutting-edge innovation and proven industry approaches and strategies.
Finally, Linux and open source adoption is not an all-or-nothing proposition. The goal of adopting Linux and open source is to optimize the organization's computing infrastructure in the most economic way possible. This might mean having a mix of Linux and non-Linux solutions. That's part of having choice, and in the end it's what Linux and open source are all about - having choices.
Advantages of Linux
Open source technology licensing is neither new nor radical. It has been part of computer science programs since the 1960s, offering organizations everywhere access to a worldwide software development community - not captive to any one entity - thereby sharing global expertise and continuous innovation and enhancement. As open source technology, Linux is freely accessible - though not necessarily free. Popular versions of Linux typically entail fees of one sort or another.Even so, its low cost is the primary benefit for many people. Linux radically reduces the cost of computing through its low cost for deployment, better price/performance, and lack of dependence on any single vendor. Companies can rack up substantial savings in terms of hardware costs alone, since organizations can deploy Linux across inexpensive commodity hardware, such as cheap x86 machines. As a result, implementation and maintenance costs can be much less than the total cost of ownership associated with some proprietary technology.
