The decision to build or buy an application has significant implications for an organization. It may be one of the most important business decisions an organization makes. Early stage companies frequently do not take the time to evaluate all of the repercussions of the decision resulting in unexpected long term consequences. The buy versus build decision is hard to reverse once it is made and should be well thought out before a final decision is made.
The best way to avoid a bad or irreversible decision is to clearly state the short and long term goals of the company and see how they match-up a with a build or buy strategy. Build versus buy impacts many aspects of a business including budgeting, strategic business relationships, control, customization, time to market and company culture. Each one of this should be evaluated before the build versus buy decision is made.
The following is a list of recommended items that should be debated before a final buy versus build decision is made.
Control - How important is it for your organization to be in control of its destiny? We all want to think that we are in control of our business. The decision to build versus buy has a big impact on the extent of that control.
If you decide to license an application control of your business begins to shift to the vendor. The vendor decides when releases will be made, the quality of the applications, the features and the core technology.
If you build an application internally your organization increases its control over its own destiny. Features, releases schedules, customization, interfaces, technology and are all dictated by your organization.
Differentiation - It is difficult to differentiate your company's product in the marketplace if you license mission critical parts of your product. A software vendor can only customize your product to a certain degree and still service its other customers. If you license a piece of software your company will have to find other ways to differentiate itself.
Customization - A software vendor will customize your software but it will cost you extra and may not be exactly what you are looking for. The vendor has to maintain continuity with the core application that is licensed to other companies restricting the degree of flexibility it can exercise. It can also be expense to customize an application. If your change request is significantly off track from the vendors road map the majority of the costs will have to be paid by your company.
Time To Market - Licensing a piece of software will allow your company to enter the marketplace faster. If you develop your own application the company will have to build a development staff, purchase additional hardware and actually build the application. This takes time, money and resources that could potentially be used for other projects.
Budget - In most cases a software licensing arrangement should cost you less compared to an in-house developed application. The licensing company will be leveraging their development costs over a number of companies thus decreasing the cost for your company. Building an application internally is expensive even if significant portions of the development are outsourced.
Managing - Managing a vendor and managing an internal development organizations are two very different processes. If a company is developing a product it will have to create a development process to manage the development. If a product is licensed the company will be managing the vendor who in turn will have its own internal development process. The degree of sophistication and professionalism of the vendor will dictate the extent and difficulty of managing the vendor.
Managing an internal development group provides more visibility into product development allowing for faster changes and the acceleration and deceleration of products releases. Managing internal development teams can pose its own unique challenges requiring multidisciplinary coordination. The developers and associated support require special attention including training and technical management.
Staff - If you are developing your own product a development staff has to be created. This means hiring, firing, outsourcing, motivation, reward, direction, scheduling and communication. Some form of HR support should be instituted to oversee the organization and make sure management is addressing personnel, motivation and salary issues.
Replacement Cost -What will it cost to switch gears and go from an outsourced piece of software to an in-house development plan. The reverse should also be modeled. It is not uncommon for an early stage company to change its product and development strategy as it matures. Creating a budget and organizational structure for both the build and buy scenarios is a good early stage exercise. If you do need to change your strategy you will be prepared for the impact on the bottom line and the required organizational changes.
Hosting - If you are licencing software from a SaaS vendor your hardware and hosting costs should be low. If you are licencing software to be hosted by your organization do some research on the cost of the hardware and the associated hosting costs. If you are developing the application yourself the hosting and hardware are entirely your responsibility. This has staffing implications requiring you to add IT personnel to provide 24/7 hardware, systems and telecommunications support.
Culture - How you approach product development has a big impact on your companies culture. A company with a fully loaded development staff has a very different culture then a company that is licensing most of its software and infrastructure. Be cognizant of the cultural impact of these decisions. Are you a marketing company, development company, sales company or a mixture of all or some of these categories. Your culture will have a big impact on your ability to hire and attract the talent you are looking for.
Each one of the items I have mentioned is a subject in and of itself and deserves a much deeper consideration then I have provided in this article. If you are pondering a buy versus do some more research on each one of these areas to make sure you make the right decision.
If you have a specific question about build versus buy please contact me at kflood6@gmail.com.
The best way to avoid a bad or irreversible decision is to clearly state the short and long term goals of the company and see how they match-up a with a build or buy strategy. Build versus buy impacts many aspects of a business including budgeting, strategic business relationships, control, customization, time to market and company culture. Each one of this should be evaluated before the build versus buy decision is made.
The following is a list of recommended items that should be debated before a final buy versus build decision is made.
Control - How important is it for your organization to be in control of its destiny? We all want to think that we are in control of our business. The decision to build versus buy has a big impact on the extent of that control.
If you decide to license an application control of your business begins to shift to the vendor. The vendor decides when releases will be made, the quality of the applications, the features and the core technology.
If you build an application internally your organization increases its control over its own destiny. Features, releases schedules, customization, interfaces, technology and are all dictated by your organization.
Differentiation - It is difficult to differentiate your company's product in the marketplace if you license mission critical parts of your product. A software vendor can only customize your product to a certain degree and still service its other customers. If you license a piece of software your company will have to find other ways to differentiate itself.
Customization - A software vendor will customize your software but it will cost you extra and may not be exactly what you are looking for. The vendor has to maintain continuity with the core application that is licensed to other companies restricting the degree of flexibility it can exercise. It can also be expense to customize an application. If your change request is significantly off track from the vendors road map the majority of the costs will have to be paid by your company.
Time To Market - Licensing a piece of software will allow your company to enter the marketplace faster. If you develop your own application the company will have to build a development staff, purchase additional hardware and actually build the application. This takes time, money and resources that could potentially be used for other projects.
Budget - In most cases a software licensing arrangement should cost you less compared to an in-house developed application. The licensing company will be leveraging their development costs over a number of companies thus decreasing the cost for your company. Building an application internally is expensive even if significant portions of the development are outsourced.
Managing - Managing a vendor and managing an internal development organizations are two very different processes. If a company is developing a product it will have to create a development process to manage the development. If a product is licensed the company will be managing the vendor who in turn will have its own internal development process. The degree of sophistication and professionalism of the vendor will dictate the extent and difficulty of managing the vendor.
Managing an internal development group provides more visibility into product development allowing for faster changes and the acceleration and deceleration of products releases. Managing internal development teams can pose its own unique challenges requiring multidisciplinary coordination. The developers and associated support require special attention including training and technical management.
Staff - If you are developing your own product a development staff has to be created. This means hiring, firing, outsourcing, motivation, reward, direction, scheduling and communication. Some form of HR support should be instituted to oversee the organization and make sure management is addressing personnel, motivation and salary issues.
Replacement Cost -What will it cost to switch gears and go from an outsourced piece of software to an in-house development plan. The reverse should also be modeled. It is not uncommon for an early stage company to change its product and development strategy as it matures. Creating a budget and organizational structure for both the build and buy scenarios is a good early stage exercise. If you do need to change your strategy you will be prepared for the impact on the bottom line and the required organizational changes.
Hosting - If you are licencing software from a SaaS vendor your hardware and hosting costs should be low. If you are licencing software to be hosted by your organization do some research on the cost of the hardware and the associated hosting costs. If you are developing the application yourself the hosting and hardware are entirely your responsibility. This has staffing implications requiring you to add IT personnel to provide 24/7 hardware, systems and telecommunications support.
Culture - How you approach product development has a big impact on your companies culture. A company with a fully loaded development staff has a very different culture then a company that is licensing most of its software and infrastructure. Be cognizant of the cultural impact of these decisions. Are you a marketing company, development company, sales company or a mixture of all or some of these categories. Your culture will have a big impact on your ability to hire and attract the talent you are looking for.
Each one of the items I have mentioned is a subject in and of itself and deserves a much deeper consideration then I have provided in this article. If you are pondering a buy versus do some more research on each one of these areas to make sure you make the right decision.
If you have a specific question about build versus buy please contact me at kflood6@gmail.com.
2 comments:
I would like to propose a different strategy: License a software engineering meta-tool and build your own applications at a higher development level.
What do I mean by a meta-tool? It's a tool that can automate the creation, analysis, re-engineering, and translation of code in/to/from basically any computer language, and provides great leverage on effort expended. It's an expert system with a rules language. You may be familiar with expert systems for finding oil or diagnosing medical conditions. A software meta-tool is similar, but its domain of expertise is software (which, of course, it is itself).
A meta-tool approach is similar to using a 4GL or Domain Specific Language, but more powerful because a meta-tool is less specialized for a given problem domain.
Let's take a look at the implications in terms of Kevin's major points.
Control -- Control over a COTS app depends on its customizability. As Kevin pointed out, that's expensive and makes you dependent on the vendor. If you build traditional apps, you theoretically have full control, but you're paying a high price. With a meta-tool, the app creation process is at a much higher level, meaning less time and expense, but it provides even better control than traditionally-built apps, because the code is more transparent and easier to maintain.
The same meta-tool can be used to automate the analysis of its own rules as needed, as well as any re-engineering of those rules needed to repurpose them. So it can effectively automate itself.
Differentiation -- As with traditional app, a meta-tool based app provides full differentiation, but at a lower cost. And the developers can concentrate more on the app's competitive advantages and less on the details of implementation.
Customization -- The meta-tool based app provides full customization, but with less effort than a traditional app. And unlike COTS customization, you can make the app do exactly what you need.
Time to market -- Big win for the meta-tool approach, compared to traditional app creation. Its higher level reduces implementation time. Of course, COTS has a time advantage too, but only if you can get it to do what you want.
Budget -- The meta-tool approach, at a higher level, is less expensive than traditional development. And the only license fees you need to pay are for the meta-tool. This should be much cheaper than licensing a full-blown COTS app system. The high development level also means much lower maintenance costs.
Managing -- With a meta-tool approach, you can manage much as for traditional app development, but at a higher level, giving more transparency into the app system from outside the IT department.
Staff -- Since a meta-tool automates much of the software development, you need fewer developers, although at a higher level. Overall, it should substantially lower personnel cost.
Replacement cost -- Shouldn't be an issue, unless your meta-tool vendor goes South. But even then, you can continue use the meta-tool. Because of the development leverage, the loss of support would be less traumatic than the loss of either a COTS vendor or a traditional development environment vendor.
Culture -- Since meta-tool based development is at a higher level of expertise, your IT shop will be leaner and meaner. Studies have shown that results are best with a small team of very capable people; that's exactly the profile of a meta-tool based IT shop. It's the antithesis of the "1,000 3GL programmers" approach to IT.
One more point: Dependence on a vendor. The loss of a COTS vendor ranges from traumatic to fatal. And for home-grown, you face the possible loss of the obsolence of the platform. With a meta-tool approach, you're developing at a level well above hardware dependencies, and you're self-sufficient -- even more so than with traditional development, with its typically high turnover rate and poorly documented 3GL code.
I am the author of a meta-tool as described above. IMHO it represents a potential revolution in software development.
The meta tool concept is a good one and represents a class of application development between internal development and licensing.
Post a Comment