The “build or buy” tradeoff has been described as having “Shakespearean proportions”. It is typically the starting point for solutions to business problems that can be solved with technology. Due to the increased rate of change and global competition, this question is even more relevant.
To save you research time, we will relay the short and simple answer to this classic question: To buy or rent when you seek the solution to a commodity business process and to build when your solution touches the core differentiators of your organisation.
If only it was that simple. The tradeoffs have become more complex. The proliferation of vendors that saturate the market with general purpose systems makes the choice a complex affair. Add to this the recent addition of Cloud and SaaS service providers that offer a plethora of modules and a new risk/reward model that removes hardware and hosting issues but adds data ownership, security and an dependance on the Internet to the considerations. Then the decision matrix for a “build or buy” choice becomes an operations research decisioning problem: never mind the normal softer issues like internal politics and ego’s.
The solution is to formally add a third option to the “build or buy” set, namely that of “assemble”. We then have the following options, namely to buy/rent, to build and to assemble. SOA provides the technical framework to do this, but does not give us an agile and efficient way to assemble these components into a coherent whole to produce business value. By formally adding the third option, most people will argue that this is not new and has always been there implicitly – the combination of a buy plus a build to extend what is purchased or rented. However, the introduction of a formal “assemble” option adds a new dimension, rather than just a combination of the two.
Traditionally for COTS systems, a buy-build would be required to extend the functionality for the 30% they do not provide. The ERP wars of the 90’s showed that this type of hacking resulted in terrible delivery cycles that went over budget, under-delivered and caused huge maintenance nightmares. The lesson: Do not extend off-the-shelf packages where possible, upgrades become a nightmare and the buy value proposition is quickly invalidated. This generally applies to COTS and open source components and systems.
Back to Basics
Before delving into the ”assemble” option as a formal construct, we have to emphasise that it relies on having the “basics” in place, namely:
- Proper business ownership and a formalised product owner team if more than one person has the product owner role (not ideal).
- Have a solid Agile development framework and software development life cycle process management in place.
- Knowledgable people that understand the business and like what they do.
- Have the proper investment focus by investing where you gain incremental revenue or the competitive advantage.
- Analyse your legacy systems and clearly identify what still has business value.
- Business processes have to defined the right way and must focus on the customer rather than inward-focussed business processes.
Infrastructure and tools are normally a simple buy choice, as is using open source components like databases, development, operations and programming languages.
The build-buy-assemble choice still has the same basic decision points, namely cost, time to market, politics, architecture, skill sets, and strategic value, with the old rule of thumb to buy to the maximum extent possible to cut costs and free up resources for what REALLY delivers the unique edge.
Finally, the industry is changing and we believe the following facts give more scope for a formalised Assemble option:
- Vendors are saturating the market with general-purpose systems.
- SaaS will put legacy systems under pressure by offering software with shorter time to market, lower maintenance costs and lower costs as SaaS typically lets customers pick and pay for functionality in modular fashion.
- The major enterprise software vendors like Oracle and SAP are moving toward component-based models.
- Traditional large scale development with .NET and Java is as risky today as it was a few years ago.
The third option
So far we have established the basic criteria and fact sets and can now introduce the third option of system assembly as the better option. Buy components where possible and create a dynamic layer that binds these components into a coherent business delivery model by using model driven technologies. Modern model driven development offers quick time to market and excels at consuming integration points and then adding unique business logic, entities, validators and excellent performance, security, re-usability and maintenance.
SOA provides the technical framework for easily integrating systems. As long as legacy and component based systems provide the correct granularity of services, we can quickly assemble new product delivery systems that leverage and extend them without hacking source systems by using model driven assembly technologies. The important factor here is to choose the correct model driven framework that offers checked and validated logic and can easily consume services and expose its extension points as services.
Modern model driven development specialises in producing reusable components with extension points through what is called a domain specific language (DSL). We can then augment, extend and aggregate systems to produce business value quickly by using the DSL. There are currently two categories supported by commercial model driven development vendors that provide the raw material to assemble solutions that are agile, quick and efficient.
The model-driven market is developing quickly and vendors like Mendix, Talend, FICO and Microsoft (to name a few) are delivering new platforms and development tools that makes the ”assemble” option an excellent formal choice. This is supported with training, certification and support options to offer a sustainable development and delivery model in addition to the traditional development environments like .NET and Java.
The first category of model-driven development platforms focuses on creating new functionality from scratch and offers a compelling alternative to .NET and Java. In this space Mendix is one of the leading vendors.
The second category is more specialised in verticals. For instance the various BPM vendors like Bonita offer excellent BPM process management tools. Another example of a model driven vertical is FICO’s Blaze that provides model-based decisioning tools, or Talend’s ETL and ESB tool sets.
To conclude, the “build or buy” choice typically included the buy-extend or the build-from-scratch options. The assemble option replaces the buy-extend with buy-assemble. Here the emphasis is on adding the missing functionality of the purchased systems by using the most efficient technology to add the business value quickly and in a platform designed to handle change. Model driven platforms are designed with change in mind, and offers checks to validate dependent systems’ service consistency with the business process, business entities and state.
The build option can also be replaced with assemble as we could use the model driven platform to create the solution from scratch that ONLY implements the function points and business processes required to offer tailor made business value. We will detail the requirements to look for in a good model driven framework in following articles.