To Buy or not To Buy - Part 2

Part 2 - Asking a different question: Product Management

Enterprises continue to evolve with the changing market and customer scenario.  Technology, which is the strategic enabler of the business, also has to evolve simultaneously to stay relevant to the business.  

As an entrepreneur running a startup or a product owner building a new product in a large enterprise the question then changes from “whether to build or buy” to “what do I need right now to enable the business based on how matured my business idea is ?”. 

As an Enterprise architect or a technology officer the question then changes to “How do I ensure there is minimal disruption to my overall architecture based on what decision the product team lands on?”

Let me expand on this a bit more.

If the business problem that the product is supposed to solve is still at a nascent stage of validation, by that I mean the larger value proposition of the product, the market fit and all the basic aspects of product is being determined, then, the overall roadmap of the product at this stage of the business is still very evolving.  The priority has to be to be able to  goto market at the earliest to validate the idea takes a higher priority. At this stage, looking at the larger building blocks of the product and looking for a solution that can be used readily to enable a feature within the product will equip product managers to launch the features quickly and test the validity of the feature. Faster iteration and quick feedback will help product managers to prioritize features that add value to the customers and remove features that are not consequential to the users.

Let us say that you are building a multi seller ecommerce platform to enable artisans to sell their products on your platform.  The feature diagram shows a list of high level features that the business needs for validation of the idea.

Ecommerce marketplace for buying and selling art

The decision to buy or build can be taken at a feature level to facilitate faster go to market. 

I use the following line of thought to classify each feature as build or buy

Build  

• This feature will serve as a differentiation for the platform and will continue to have frequent iterations or changes that are necessary to keep the platform unique

• The feature contains specific requirements that are not readily available

• It is important to have total control of all the technology layers within the organization

Buy

• The features are not very different from the competition and the processes look very similar

• Very standard workflows and the tools in the market are very mature and readily available

• Provided as standard offering from the underlying platform providers (Cloud, Paas etc)

Buy now build later

• These processes are similar but are very core to the operations of the business.

• The costs might be viable in the short term but might not be viable in the long term due to the scale of the business and pricing models of the underlying software

Integrate

• These are partner services that are needed to run the business and provide complementary or supplementary services to our core business

The categorization of the features might change with the evolving landscape of the business. The agility of the platform is defined by how frequently the platform can be changed without disrupting or causing instability in other parts of the system.  Taking an intentional approach to create an architecture with considering maintainability, scalability, security, performance, availability and observability as design constraints becomes a critical success factor in creating a technology solution that is agile, resilient and nimble. We will deliberate on the technical architecture in the next part of this series.