Build over Buy: True stories
I was recently reading an in-depth analysis of the Buy versus Build decision process. In this article, I look back on 3 short real-world stories from my experience when the decision to build a technology was favored for the wrong reasons.
I shed light on the key context for each story, the buy vs. build decision trigger, the outcome of the decision, and the key takeaways from those lessons.
Story# 1: You need a Middleware, We have built one!
Context: A large integration project for a client working with several partners in different domains, Microsoft technology stack was used for the core components in the client’s IT landscape. One of the client partners was responsible for the HRM platform, their team had built a custom-built integration solution to support mediating HRM platform integrations with external systems and applications.
Decision Trigger: The client was looking for an organization-wide integration platform and the HRM partner proposed their custom-built integration solution as a potential option.
Outcome: The HRM technical team conducted several POCs to show their integration solution prowess and extensibility, however, this was a quick and easy decision for the client; they opted for Microsoft BizTalk Server given that they are a Microsoft shop.
Key Takeaways: Building a middleware platform is far from a trivial matter, and even in this particular case where the HRM partner had heavily invested in it, yet it couldn’t be compared to the investment level, maturity, or proven track record of a robust middleware platform such as BizTalk Server.
This story also shows how technical teams can sometimes get so immersed in their own solutions that it becomes their only reality while they slowly lose sight of the other technologies, innovations, and trends developing in the market.
Story# 2: In-house workflow engine to cut license costs, right?
Context: A company with core competency in building business applications for organizations in the public sector. The company had a technical team of highly skilled members playing the role of the design authority.
Decision Trigger: Management noticed a large demand in clients’ RFPs for human workflow engines, at that time, COTS workflow engines such as K2 and SharePoint workflows dominated the market with premium license costs.
Management decided that building an equivalent workflow engine would provide a competitive edge from the financial aspect in the bidding process for these requests. The technical team was commissioned to build and maintain the workflow engine.
Outcome: As more delivery teams started to rely on the in-house workflow engine in their projects, functional and non-functional issues arose and its maintenance became a nightmare for the technical team, who were busy with other responsibilities.
Within a couple of years, the in-house workflow engine became notorious for its stability issues; teams embarking on new projects steered clear of it, while teams already leveraging it scrambled to find workarounds to mitigate these issues.
Key Takeaways: The company moved away from its core competency to build and maintain what should have been a robust workflow engine. While management was mainly focused on the financial aspect for winning bids, the engine-related issues have caused delays and quality issues which incurred additional costs in delivery for the projects relying on it.
Story# 3: To SAML or not to SAML, an SSO question
Context: A technical team of novice software developers working on a low priority back-office solution consisting of multiple custom applications. Single sign-on (SSO) across the applications was a key requirement of the solution. At that time, SAML 2.0 was the standard for SSO.
Decision Trigger: The novice team in haste to build the applications didn’t take time to understand the existing frameworks and techniques used to employ SSO. After briefly assessing SAML, the senior team member quickly dismissed it as being too complex and decided that they could build this functionality themselves to re-authenticate users across the different custom applications.
Outcome: The team encountered numerous edge cases during the test phase. Ironically, their proprietary SSO implementation had a steep learning curve for new members who joined the team to develop and maintain the solution.
Key Takeaways: Novice teams can sometimes become intimidated by an unfamiliar or a new technology, and given the choice, they could revert to their comfort zone of writing code and building a pale imitation of a technology or a framework to get a false sense of control.
In this particular case, SAML was a complex protocol to learn, especially for a team of novice software developers. Leveraging an industry standard protocol with the support of an identity provider will go a long way in abstracting the implementation complexities of the protocol and it will contribute towards a more reliable and a more secure authentication solution.