|
|
Enterprise IT and Open Source: A prosperous match?
Posted On April 10, 2006 by GB Shah filed under Miscellaneous
Till a few years back, usage of Open Source products and technologies within an Enterprise IT System group was considered a completely illogical and impractical move. Yet, as we have seen in the recent past, Enterprise IT has been fuelling the usage of Open Source and Free Software. However, despite some promising starts, even Open Source has not quite solved many Enterprise IT problems.
In this article, we will explore the reasons why enterprises have not been able to explore Open Source opportunities to the fullest extent and reap benefits. We will also attempt to come up with a model that blends the best of breed practices from the Open Source development world and Enterprise IT world.
There have been innumerous reports from prominent media products, research agencies, technology vendors and independent industry bodies on issues plaguing the Enterprise IT market. The least common factors of all these reports give us the following data:
1. Anything between 40-70% of Enterprise IT projects are a failure;
2. More than 80% of projects go over the budget and are never executed in time; and
3. At least 30% of all IT investments in the Enterprise marketplace never give any return on investment.
Further analyses of these reports unveil three very important reasons why Enterprise IT projects fail.
1. There were failures during the stage of requirements capture and system analysis;
2. There were wrong assumptions made while arriving at the estimation costs, including the time required to deliver the project as well as the manpower required for the project; and
3. Design changes were required midway of the project, either due to one of the above reasons, or because of business considerations.
While the above three points look academic and elementary, and one may think that a process-oriented software development or IT Services organization must be able to resolve such issues, in the real world it is easier said than done.
Though in the recent past there have been a plethora of tools, commercial and free, that help you manage Application Life Cycles, few of them have been able to resolve most of these issues. This is because tools can only automate processes and help you in executing them. It cannot take intelligent decisions in cases of requirements capture and Design challenges.
Again, most tools depend on data provided by a project leader or senior IT staff of a company. When mistakes happen there, because of human errors (not clerical errors), very little can be done by some of these bloatware.
This is not to discard efforts made by the ALM vendors. These tools are indeed useful, for most purposes, but they can only automate processes. However, when processes itself are wrong there is nothing that the tools can do!
One of the biggest advantages of traditional Enterprise IT projects is that they are heavily process oriented. It is important for large enterprises to have processes. This is because these organizations have mammoth teams, often multi-location that are even spread across continents and have people working together coming from different work cultures.
Processes help organizations resolve most of the people related issues. However, processes are often a bane, as no process exists that provides a solution for all problems addressed in its domain. One of the issues of a process-oriented approach in a typical IT organization is that it forces you to plan upfront. This often results in coming up with a design for a system too early in the project, which in most cases needs to be altered during the progress of the project. This normally results in chaos unlimited and has often resulted in projects even being scrapped.
I have nothing against designing anything upfront. It is the best-recommended way for any job. However, designing elaborately before you launch an IT project is no more practical as requirements change very often. And as requirements change, your design needs to change.
Another issue with large IT projects is that you often start off a start point with the single goal of reaching a fixed end point. With some chary planning, a good project leader will also include milestones in-between. However, the gap between these milestones is often large. This is again not good in many cases, as project leaders need to depend on feedback from customers (end users) to arrive at solutions.
Many enterprise companies have deployed Agile development methodologies to solve this issue, where they use a process called releases planning and release the product quite often.
Finally, there is the people factor. Not all people factors can be solved by processes. Attrition rates are real and many a time the cost of a professional, trained and experienced individual in a specific proprietary enterprise platform is substantially high. Consider the market rates of an Oracle or SAP professional. Retaining professionals is also a challenge for an organization.
Hence, the real costs of building Enterprise software on proprietary platforms using traditional methods of software development is considerably higher than whatever a project leader or CIO would have estimated on paper. There have been recorded instances of projects being shelved mid-way just because professionals with key skills-sets are just not available.
Open Source to the rescue
Open Source and Free Software (FOSS) is a phenomenon that has revolutionized the computing industry. While currently the benefits are being enjoyed by developer companies, educational institutions, R&D organizations and some SMEs, large enterprises have not quite exploited the benefits of Free and Open Source software.
While deployment of Linux to manage some of the non-critical issues in Enterprise companies is a trend that has been observed for sometime, very few Enterprise companies have used FOSS products, technologies and methods in more critical areas.
There are some obvious benefits of Open Source Software, such as:
1. It costs almost nothing to acquire the software and source code;
2. You are free from licensing concerns; and
3. You can modify and even re-distribute modified versions of the software
Let us now get to know three pitfalls of using FOSS products:
1. Not all FOSS products are stable;
2. There may not be a vendor who can provide support for the product;
3. Finally, most FOSS products do not have a fixed road map and a timeline where releases can be planned. This is because most FOSS products are built during the free time of a developer.
To a casual observer, the pitfalls outweigh potential benefits. One cannot blame this line of thought, because many enterprises subscribe to the same belief.
However, there are enough reasons to argue.
First, let us consider the cost of deployment of an IT solution based on a proprietary system and standards. There is the cost of license, which usually accounts for 25% of the cost of the solution. Then there is the matter of costs in various brackets – deployment, support, training and migration. Now add the cost of maintenance to the aforesaid list.
It is a no-brainer that using an Open Source solution will at least save the costs of licenses. However, it is safe to assume that the costs of deployment, support, training and migration will be the same or less than that of a proprietary solution. Any doubts? Check out the costs of a SAP or Oracle professional, and a Python guru. You will see that the costs are similar or even lesser in case of the Open Source professional.
Then there exists the cost of maintenance, which is variable. Maintenance costs of proprietary solutions include, apart from manpower, the cost of re-licensing. Today, most software companies offer timed licenses, which means to say that these licenses are valid for a specific period. Then a customer is forced to upgrade, which brings the recurring costs to a new high.
In case of Open Source software, you again save the costs of licenses. Since maintenance costs are a function of manpower costs, your costs are again in control, if you are using managed Open Source development.
In the big bad world of business, enterprise software companies often get merged and acquired. Though during the merger both parties involved state that customers will not be affected, history sings a different tune. In reality, many millions of dollars worth of investments in proprietary solutions are written off during some of the mergers or are integrated using multimillion dollar integration toolkits and mammoth implementation teams.
This is where using Open Source solution helps. Even if the original developers disappear, there are other hands that can be hired to manage the development. Many a times the original developer kick starts a project and moves out; it is the enthusiasts who actually pick up the cue and take it forward.
You are essentially securing whatever investments you make in your next project by investing in Open Source.
While the reasoning mentioned in the previous section may sound logical, there are still practical hurdles ahead. You need to evaluate the right product and technology since in the Open Source space you have a plethora of offerings addressed in each domain. And again, not all products and technologies available will suit your needs. You need to customize these software to your liking.
Again, this is true when you invest in proprietary software. The amount of time and effort you need to spend to customize a SAP R/3 installation can easily outdo the amount of money spent in acquiring the product. This is usually estimated at three to five times the cost of acquiring a license.
Chances that you can easily find a product that specifically takes care of a domain problem is certainly high in the Open Source space. On the other hand, a chance of the Open Source product being unstable is equally high. Then how do you ensure stability to open enterprise class software, which is actually a cluster of products built out of Open Source code?
This can be achieved through a few meticulously planned strategies that can either be outsourced or done in-house.
Managed Open Source
In the past few years, we have seen the phenomenon of outsourcing of different services. Managed Open Source development is a phenomenon that the whole world will subscribe to.
What is managed Open Source?
Open Source development is essentially software development done by a community of developers. They generally write software to solve a problem they are facing and contribute their code to the developer community. Other developers usually write patches, updates and improvements to the code base. After this point, the code can be downloaded free of cost.
The process is extremely cost-effective, as almost all of the source code is written during spare time. However, many enthusiastic Open Source developers are out there who could spend extra time in writing code for an Open Source project if some incentive is provided. This can be achieved through a method called ‘Managed Open Source Development’, which is something that my company specializes in. The code thus developed at a fraction of the cost of developing software using closed source models, can be made effective using a group of volunteers who get involved for the sake of participation.
The actual cost of managed Open Source development is extremely low as you are billed just for a small team of experienced developers who get involved in the project full-time. The rest of the developers are all volunteers, who get involved for their own personal reasons. Typically, a managed Open Source development team takes care of the following activities:
1. Develop the software or software component;
2. Popularize the same through blogs, forums and wikis; and
3. Promote it among developers and user communities.
Well, almost the whole of the aforementioned activities are done at no cost. It all works within the framework of programming democracy.
The question of security
Common sense somehow tells us that if the code is available for free, it will not be secure. But the truth is far from that. Since there are several eyes pouring over the code, it is bound to have lesser bugs. Also, remember, there are developers with varied experience checking out the code and this is better than having a number of developers checking the code just for the sake of checking. And as Linus’ law states, “Given enough eyeballs, all bugs are shallow”.
An important idea that many enterprise IT managers miss is the spirit of Open Source. An IT manager who has only seen the proprietary world of software may not be able to appreciate the true sense of Open Source. They often wonder that when something comes in free, it cannot be worth it. The world of Open Source and Free Software is an exceptional case.
When you use Open Source, it does not mean that you necessarily have to distribute the code free. You are always free to make changes and keep using the version. When you distribute the code, you have to honor the original licensee of the software.
There are several Open Source software licenses that you can look at if you are worried about the veracity of the code you create for applications. If you plan to use Open Source for your internal use, you can very well keep the modifications to yourself, provided you abide by the rules.
Again, you can safeguard certain portions of the software that is critical for your operation. Let us consider the very simple example of a portal. You can build a portal using FOSS tools like Python, PHP, Ruby, etc. You can take the help of the large community of developers for specific components of the portal. However, no one expects you to give away the code that is written for your very specific application. In case you have developed something that you feel is critical for your business, you can very well keep it secure. However, as you delve deeper, you will discover that it pays if you are opening up as much of your code base as possible. It saves a lot of work in the future.
For an enterprise, it is how well you deploy and use software that matters. Unless you are in the business of selling software that you build, Open Source is the way to go.
The author can be reached at: satheeshg@o2a.org.
In this article, we will explore the reasons why enterprises have not been able to explore Open Source opportunities to the fullest extent and reap benefits. We will also attempt to come up with a model that blends the best of breed practices from the Open Source development world and Enterprise IT world.
There have been innumerous reports from prominent media products, research agencies, technology vendors and independent industry bodies on issues plaguing the Enterprise IT market. The least common factors of all these reports give us the following data:
1. Anything between 40-70% of Enterprise IT projects are a failure;
2. More than 80% of projects go over the budget and are never executed in time; and
3. At least 30% of all IT investments in the Enterprise marketplace never give any return on investment.
Further analyses of these reports unveil three very important reasons why Enterprise IT projects fail.
1. There were failures during the stage of requirements capture and system analysis;
2. There were wrong assumptions made while arriving at the estimation costs, including the time required to deliver the project as well as the manpower required for the project; and
3. Design changes were required midway of the project, either due to one of the above reasons, or because of business considerations.
While the above three points look academic and elementary, and one may think that a process-oriented software development or IT Services organization must be able to resolve such issues, in the real world it is easier said than done.
Though in the recent past there have been a plethora of tools, commercial and free, that help you manage Application Life Cycles, few of them have been able to resolve most of these issues. This is because tools can only automate processes and help you in executing them. It cannot take intelligent decisions in cases of requirements capture and Design challenges.
Again, most tools depend on data provided by a project leader or senior IT staff of a company. When mistakes happen there, because of human errors (not clerical errors), very little can be done by some of these bloatware.
This is not to discard efforts made by the ALM vendors. These tools are indeed useful, for most purposes, but they can only automate processes. However, when processes itself are wrong there is nothing that the tools can do!
One of the biggest advantages of traditional Enterprise IT projects is that they are heavily process oriented. It is important for large enterprises to have processes. This is because these organizations have mammoth teams, often multi-location that are even spread across continents and have people working together coming from different work cultures.
Processes help organizations resolve most of the people related issues. However, processes are often a bane, as no process exists that provides a solution for all problems addressed in its domain. One of the issues of a process-oriented approach in a typical IT organization is that it forces you to plan upfront. This often results in coming up with a design for a system too early in the project, which in most cases needs to be altered during the progress of the project. This normally results in chaos unlimited and has often resulted in projects even being scrapped.
I have nothing against designing anything upfront. It is the best-recommended way for any job. However, designing elaborately before you launch an IT project is no more practical as requirements change very often. And as requirements change, your design needs to change.
Another issue with large IT projects is that you often start off a start point with the single goal of reaching a fixed end point. With some chary planning, a good project leader will also include milestones in-between. However, the gap between these milestones is often large. This is again not good in many cases, as project leaders need to depend on feedback from customers (end users) to arrive at solutions.
Many enterprise companies have deployed Agile development methodologies to solve this issue, where they use a process called releases planning and release the product quite often.
Finally, there is the people factor. Not all people factors can be solved by processes. Attrition rates are real and many a time the cost of a professional, trained and experienced individual in a specific proprietary enterprise platform is substantially high. Consider the market rates of an Oracle or SAP professional. Retaining professionals is also a challenge for an organization.
Hence, the real costs of building Enterprise software on proprietary platforms using traditional methods of software development is considerably higher than whatever a project leader or CIO would have estimated on paper. There have been recorded instances of projects being shelved mid-way just because professionals with key skills-sets are just not available.
Open Source to the rescue
Open Source and Free Software (FOSS) is a phenomenon that has revolutionized the computing industry. While currently the benefits are being enjoyed by developer companies, educational institutions, R&D organizations and some SMEs, large enterprises have not quite exploited the benefits of Free and Open Source software.
While deployment of Linux to manage some of the non-critical issues in Enterprise companies is a trend that has been observed for sometime, very few Enterprise companies have used FOSS products, technologies and methods in more critical areas.
There are some obvious benefits of Open Source Software, such as:
1. It costs almost nothing to acquire the software and source code;
2. You are free from licensing concerns; and
3. You can modify and even re-distribute modified versions of the software
Let us now get to know three pitfalls of using FOSS products:
1. Not all FOSS products are stable;
2. There may not be a vendor who can provide support for the product;
3. Finally, most FOSS products do not have a fixed road map and a timeline where releases can be planned. This is because most FOSS products are built during the free time of a developer.
To a casual observer, the pitfalls outweigh potential benefits. One cannot blame this line of thought, because many enterprises subscribe to the same belief.
However, there are enough reasons to argue.
First, let us consider the cost of deployment of an IT solution based on a proprietary system and standards. There is the cost of license, which usually accounts for 25% of the cost of the solution. Then there is the matter of costs in various brackets – deployment, support, training and migration. Now add the cost of maintenance to the aforesaid list.
It is a no-brainer that using an Open Source solution will at least save the costs of licenses. However, it is safe to assume that the costs of deployment, support, training and migration will be the same or less than that of a proprietary solution. Any doubts? Check out the costs of a SAP or Oracle professional, and a Python guru. You will see that the costs are similar or even lesser in case of the Open Source professional.
Then there exists the cost of maintenance, which is variable. Maintenance costs of proprietary solutions include, apart from manpower, the cost of re-licensing. Today, most software companies offer timed licenses, which means to say that these licenses are valid for a specific period. Then a customer is forced to upgrade, which brings the recurring costs to a new high.
In case of Open Source software, you again save the costs of licenses. Since maintenance costs are a function of manpower costs, your costs are again in control, if you are using managed Open Source development.
In the big bad world of business, enterprise software companies often get merged and acquired. Though during the merger both parties involved state that customers will not be affected, history sings a different tune. In reality, many millions of dollars worth of investments in proprietary solutions are written off during some of the mergers or are integrated using multimillion dollar integration toolkits and mammoth implementation teams.
This is where using Open Source solution helps. Even if the original developers disappear, there are other hands that can be hired to manage the development. Many a times the original developer kick starts a project and moves out; it is the enthusiasts who actually pick up the cue and take it forward.
You are essentially securing whatever investments you make in your next project by investing in Open Source.
While the reasoning mentioned in the previous section may sound logical, there are still practical hurdles ahead. You need to evaluate the right product and technology since in the Open Source space you have a plethora of offerings addressed in each domain. And again, not all products and technologies available will suit your needs. You need to customize these software to your liking.
Again, this is true when you invest in proprietary software. The amount of time and effort you need to spend to customize a SAP R/3 installation can easily outdo the amount of money spent in acquiring the product. This is usually estimated at three to five times the cost of acquiring a license.
Chances that you can easily find a product that specifically takes care of a domain problem is certainly high in the Open Source space. On the other hand, a chance of the Open Source product being unstable is equally high. Then how do you ensure stability to open enterprise class software, which is actually a cluster of products built out of Open Source code?
This can be achieved through a few meticulously planned strategies that can either be outsourced or done in-house.
Managed Open Source
In the past few years, we have seen the phenomenon of outsourcing of different services. Managed Open Source development is a phenomenon that the whole world will subscribe to.
What is managed Open Source?
Open Source development is essentially software development done by a community of developers. They generally write software to solve a problem they are facing and contribute their code to the developer community. Other developers usually write patches, updates and improvements to the code base. After this point, the code can be downloaded free of cost.
The process is extremely cost-effective, as almost all of the source code is written during spare time. However, many enthusiastic Open Source developers are out there who could spend extra time in writing code for an Open Source project if some incentive is provided. This can be achieved through a method called ‘Managed Open Source Development’, which is something that my company specializes in. The code thus developed at a fraction of the cost of developing software using closed source models, can be made effective using a group of volunteers who get involved for the sake of participation.
The actual cost of managed Open Source development is extremely low as you are billed just for a small team of experienced developers who get involved in the project full-time. The rest of the developers are all volunteers, who get involved for their own personal reasons. Typically, a managed Open Source development team takes care of the following activities:
1. Develop the software or software component;
2. Popularize the same through blogs, forums and wikis; and
3. Promote it among developers and user communities.
Well, almost the whole of the aforementioned activities are done at no cost. It all works within the framework of programming democracy.
The question of security
Common sense somehow tells us that if the code is available for free, it will not be secure. But the truth is far from that. Since there are several eyes pouring over the code, it is bound to have lesser bugs. Also, remember, there are developers with varied experience checking out the code and this is better than having a number of developers checking the code just for the sake of checking. And as Linus’ law states, “Given enough eyeballs, all bugs are shallow”.
An important idea that many enterprise IT managers miss is the spirit of Open Source. An IT manager who has only seen the proprietary world of software may not be able to appreciate the true sense of Open Source. They often wonder that when something comes in free, it cannot be worth it. The world of Open Source and Free Software is an exceptional case.
When you use Open Source, it does not mean that you necessarily have to distribute the code free. You are always free to make changes and keep using the version. When you distribute the code, you have to honor the original licensee of the software.
There are several Open Source software licenses that you can look at if you are worried about the veracity of the code you create for applications. If you plan to use Open Source for your internal use, you can very well keep the modifications to yourself, provided you abide by the rules.
Again, you can safeguard certain portions of the software that is critical for your operation. Let us consider the very simple example of a portal. You can build a portal using FOSS tools like Python, PHP, Ruby, etc. You can take the help of the large community of developers for specific components of the portal. However, no one expects you to give away the code that is written for your very specific application. In case you have developed something that you feel is critical for your business, you can very well keep it secure. However, as you delve deeper, you will discover that it pays if you are opening up as much of your code base as possible. It saves a lot of work in the future.
For an enterprise, it is how well you deploy and use software that matters. Unless you are in the business of selling software that you build, Open Source is the way to go.
The author can be reached at: satheeshg@o2a.org.