Theoretically, build versus buy decisions are based on three factors:  Time to market, features and functions, and total cost of ownership.

In practice, however, IT effectiveness consultants—and years of historical data—condense your decision into one simple maxim:  Buy to standardize, build to compete.

This paper is discusses the points you need to consider as part of your own build versus buy decision.

Three Factors for Your Business Case

Let us consider in turn each of the three factors listed above.

I.  Time to Market

In a build situation, time-to-market pressures will dictate the functionality that you can include in your solution.  Do you have enough time to match the stability and maturity of commercial software products that have improved over numerous versions via feedback from the market?

In a buy situation, you have the opportunity to evaluate multiple solutions—quickly, immediately, and without risk.  And depending on the vendor, you might also be able to request custom features enhancements.

II.  Features and Functions

This is where you need to apply the maxim we mentioned in the introduction:  Is this solution related to a commodity business process?  Or is it part of a core process that differentiates my company?

If the latter, then a build decision will very likely yield a competitive advantage.  If the former, a buy decision makes more sense economically and strategically.  And it will free your developers to focus on projects that are critical to the success of your company.

Do not let politics lead you into a build decision for a product that meets the criteria for a buy, or vice versa.  You must make an objective analysis of the strategic value of the solution and then proceed to build or buy on that basis.

III.  Total Cost of Ownership

Whether you build or buy, the solution must be supported, maintained, and evolved as your business requirements and the underlying technologies (operating systems, server platforms, etc) dictate.  In a build situation, these costs are unknown—as is the initial development cost itself.

If your core competency is not software development, you can be unpleasantly surprised by the total costs of the typical seven– to eight-year software lifecycle.  In fact, 70% of software costs occur AFTER the initial implementation.  A rigorous lifecycle analysis that realistically estimates ongoing maintenance by in-house developers (including knowledge transfer requirements resulting from employee turnover) often tips the balance in favor of buying.

A commercial software developer, conversely, is able to spread those costs across many customers; therefore, it is much less onerous to build support for 64-bit hardware or the latest version of Windows.

Build-or-Buy Case Study:  OCS Archive Viewing

Microsoft Office Communications Server natively logs IM conversations to a SQL database, but it does not provide end users or administrators with an easy way to search, retrieve, or view past conversations.  We frequently see customers struggle with build-or-buy decisions around OCS archive viewing, so let’s use Instant Archive Viewer to illustrate the decision process.

I.  Time to Market

With regards to OCS archive viewing specifically, regulatory requirements, FRCP regulations, and internal usage policies all add significant pressure to timelines—your financial and legal risks increase the longer you live without a solution (or live with an inadequate solution).  Are you content to hope that you will not be hit with a legal discovery order, or can you be certain your employees are not misusing the system, while you wait for IT to build an archive viewer?

II.  Features and Functions

The complexities of complying with regulatory requirements, meeting discovery orders, and enforcing internal policies give rise to a host of technically challenging feature requirements.  Whether it’s built or bought, your solution needs to address these (and many more) issues:

1.  Security and Confidentiality

  • Granular role-based access control
  • Windows pass-through client authentication
  • Integration of AD and SQL
  • Server-based authentication with Active Directory and/or SQL
  • Cross-server Kerberos authentication and delegation

2.  UI Design

  • Role-based archive viewing (end user, manager, administrator)
  • Integration with, and deployment to, the OCS client
  • Integrated view to resolve SIP URI with user display names
  • AJAX enablement

3.  Multi-party Chat Support

  • Multi-party support is complex and difficult—even some software vendors struggle with it!
  • Search, discovery, and export of multi-party chats are equally challenging

4.  Role-based Archive Search and Discovery

  • Different roles (end users, managers, administrators) require different search capabilities
  • Multiple search parameters (by date, by person, by keyword, complex Boolean searches) may be required
  • Ongoing discovery requirements may necessitate the ability to save queries into discovery projects

5.  Data Export Options

  • HTML, local file, email, PDF…?

Buy to Standardize or Build to Compete?

Communications media (email, IM, fax, voice) and their various add-on components (anti-virus, anti-spam, VoIP, voicemail, etc) are commodities on which nearly every company in the world has standardized.  Would an in-house anti-virus solution give you an edge over your competitors?  Unless you are in the business of selling anti-virus software, the answer is almost certainly no.

Similarly, an in-house solution to view your OCS archives is unlikely to yield any competitive advantages.  The conclusion in this case, therefore, is ‘buy to standardize’ because your business has nothing to gain from reinventing the proverbial wheel.