Pringo Articles
Buy vs. Build in a Web 2.0 Environment
Date: 1/2009
The information age old question of Build vs. Buy of enterprise software also applies to online communities, social networks, and Web 2.0 platforms in general. As organizations and enterprises start to learn the importance of Web 2.0 features and omni-directional portals, discussion of buy vs. build extends to this class of software as well.
What is a Web 2.0 Environment?
Wikipedia defines Web 2.0 as a term describing changing trends in the use of World Wide Web technology and web design that aims to enhance creativity, secure information sharing, collaboration and functionality of the web. Web 2.0 concepts have led to the development and evolution of web-based communities and social-networking sites, video sharing sites, wikis, blogs, and folkonomies. As a matter of fact, Wikipedia itself is an excellent example of Web 2.0 platform where masses collaborate to provide information to virtually any question in any language.
How Could Organizations Take Advantage of Web 2.0 Functionality?
Transformation of internal and external portals from mono-directional information delivery sites to omni-directional collaborative sites will allow organizations to unleash the knowledge power of their employees, customers, vendors, and partners in creating better project teams, producing better products, sharing more comprehensive information, and providing faster answers to organizational questions.
In addition, the first group of The Internet generation (kids who were born after the massive use of internet started) is about to graduate high school in 2009. In 4-6 years, this group will graduate from universities and colleges and find themselves in the job market. This generation is used to utilizing online communities, text messages, instant chats, micro blogs, and shorter modes of communications. They will expect organizations to provide such tools as part of the standard set of tools in the organization.
Buy vs. Build
There are arguments on both sides of the Buy vs. Build issue and there is no right or wrong answer. Each organization would need to evaluate their internal strengths and preferences and make an educated decision accordingly. In this paper, we have attempted to deliver an objective view of the differences between the two approaches and provide a tool for such evaluation.
Advantages of Buying a Product:
- Faster Time to Market: The ability to purchase a package obviously will increase the speed at which the system will be delivered.
- Organizational Expertise: Not every organization could afford to shift a number of its programmers and database administrators from their day-to-day activities to work on a new project. As such, organizations would need to evaluate the internal expertise as well as the availability of those experts as they decide to take on an internal delivery project.
- Future Maintenance: In purchasing the package, the organization will directly receive the support of a large number of programmers whose single purpose is to improve and enhance the functionalities provided in the package. In addition, the organization will indirectly take advantage of expertise and needs of package’s other clients who have proposed their own set of requirements and enhancement for the product.
- Total Cost of Ownership (TCO): Inevitably, and in contrary to popular belief, the total cost of the ownership for a typical Custom Off The Shelf (COTS) package is less than building the same package internally. Depending on the complexity and the number of desired set of components, it will take much more time and internal energy to create specifications, develop the tool, test the tool, and continue with its maintenance than it would take to buy a package.
Disadvantages of Buying a Product:
- The 80-20 Rule: In a typical purchase of a COTS software, close to 80% of the features will function as needed by the organization. However, the problem is typically with the other 20%. Either such functionality is missing from the software and/or is not working based on the needs of the organization.
- Initial Cash Outlay: a COTS package will cost money initially for a license fee and in the future for maintenance and support. Especially in economical downturns, budgeting will become a problem for some organizations.
- “Not Built Here” Syndrome: In a number of organizations, IT teams are only interested in running, managing, and utilizing products that are developed internally. Such organizations often ignore, and do not utilize products that are developed externally.
Advantages of Building a Product:
- Full Customization: When the product is developed internally, the system will fit exactly as required by the organization. All the functionalities needed by the organization are available and functioning exactly as required by the organization.
- First & Only Priority: Since the organization has the ownership of the product, and is its only client, any modification requirements by the business will be addressed directly by the IT team.
- Lack of Domain Functional Availability: Some organizations choose the ‘build’ option because as part of their research they cannot find products that fit their particular domains and industries. In such cases, these organizations have been forced to build their own functions.
- Competitive Advantage: In the past, I have encountered organizations that have chosen the custom development path simply because they didn’t want their competitors to be able to utilize the same package as theirs.
Disadvantages of Building a Product:
- Domain Expertise: Developers might not have the knowledge of building and developing Web 2.0 applications. It will take time to analyze and identify the best way to develop features of a Web 2.0 application.
- Continuous Maintenance: Organizations will continuously have to maintain and support the product and add new functionalities as they are added on the COTS platforms. This will become imperative in a fast moving industry such as Web 2.0 as the technology is being enhanced and new features are being added all the time.
- Shifting of Focus: In order to develop particular software, programmers will have to shift their focus from other projects into these projects. This will obviously have a negative affect on delivery of other projects.
Buy and Customize Option
As mentioned before, depending on the organizational preferences, there are choices to be made as to whether buy or build a Web 2.0 product. However, there is a 3rd option which is a hybrid of both Buy and Build: Buy and Customize.
This option will recommend purchase of a customizable Web 2.0 platform which contains not only all the necessary features as part of its base platform, but also the tools for customization of the every functionality, so that it could be customized to the exact requirements of the organization.
This option will take embrace all advantages of both build and buy option while minimizing the disadvantages of each.
Conclusion
The discussion between pro and con camps of ‘build’ vs. ‘buy’ in software will continue for years to come. However, as many organizations have successfully implemented the ‘buy-and- customize’ option (ERP, CRM, Database, and Content Management technologies as an example), they will categorize Web 2.0 technologies as an essential enterprise software tool that could be utilized in the same method.
In this regard, Web 2.0 software companies such as Pringo would be able to support organization in such deployment while keeping the ROI high and TCO low.