13 Jul 2016
Should you Build or Buy a software integration solution?
Integration is becoming a new hot topic in software development as the solution landscape evolves with the growth of cloud and mobile applications. With that growth has come a plethora of systems, many on new platforms, that generate more and more data. The people in organizations tasked with handling all of this are developers. Furthermore, developers are expected to deal with the demand for greater agility and flexibility of applications, then of course there is the shadow of disruptive change and how it might bring unexpected changes. Since developers have the responsibility to implement integrations between internal (and increasingly external) systems, they also have to address the question – build or buy a software integration solution?
Integration solution components
A software integration solution is not a simple system to build, it requires tools that can:
- connect systems and applications,
- gather and move data,
- support agile development,
- work as components,
- connect to on-premise and cloud platforms,
- provide backend support for mobile applications,
- handle volumes and scale,
- empower ordinary users to do some of the operational work,
- ensure data security and integrity,
- work over poor communication infrastructure (eg, dropped mobile connections).
In the last 15-20 years, businesses have been through a period where the preferred systems were tightly integrated solutions, such as ERP. This was a response to the previous period when systems were isolated and siloed. The problem with the current crop of integrated systems is that businesses are finding them too inflexible, and when it comes to getting a solution with unique requirements the answer has been to hand code a solution.
It’s not that difficult to understand why hand coding is preferred by so many developers.
- Developers believe by hand coding a solution they have more control
- They like the creative process of building their own solution
- They believe they can do a better job of developing a solution
- From a cost perspective they believe it will be cheaper
While the ‘build’ argument has been much the same for several years, the argument for ‘buy’ has changed as new technologies and approaches have been adopted.
Instead of implementing a monolithic enterprise system, it’s now becoming more common to take specific solutions from different vendors and tie them together loosely, giving business a more differentiated system. A Gartner report on the future of digital business found that organizations will ‘build’ by combining bought application components that are differentiated, innovative, but not customized software, and will source solutions from startups, disrupters or specialized local providers.
A classic example of this is Uber which uses separate components for:
- text messages,
- sending receipts.
How to decide
As both the Gartner research and Uber example show, the key to differentiation, agility, and customer service in the new world of business is to integrate the best solutions to create a distinct overall system. Software integration is going to be one of the keys to digital business. Therefore, how should a developer decide whether they should build or buy an integration solution?
You should consider build for the following reasons.
- If you can build it it faster and can provide a more complete solution than a bought one
- You can provide a better experience that a bought solution
- There are no available services that do the same thing
The arguments for buy focus on the solution.
- It needs it to be reliable, efficient and scalable
- It’s important to provide the best customer experience
- How will ongoing maintenance and support be provided?
- Is developing our own solution a productive use of your time?
- As new systems come along, how will you quickly provide a connection to integrate the new apps with existing systems?
- Will developing your own integration create unique advantages?
Geoffrey Moore, the Silicon Valley advisor, proposed the the core-context model, which uses two dimensions to identify solution priorities:
- mission critical / non-mission critical
- core / context
|Mission critical||Differentiators||Tables stakes|
Mission critical core is your differentiator that wins customers against others. Mission critical context, the table stakes, are not differentiating. However, this is typically a large part of the solution, and are the capabilities that any solution is expected to provide.
The backend capabilities provided by an integration solution are unlikely to be core. It’s more likely that a customer-facing or supply chain component of your solution will be mission critical core. The recommendation is that you outsource your context to free time up for core; and make sure you don’t waste time on too much context.
One of our customers had the decision of build vs. buy for integrating their online customer portal with their ERP system. When it came to delivering an integration solution, using the Flowgear integration platform they were able to go from initial concept to production in four months, which included testing out different integration patterns along the way.
What developers should consider
Developers need to identify how they can provide real value to the digital business initiatives that their organizations are conducting. This may mean that developers need to challenge their self-perceptions of how capable they are, and how long and complex developing their own integration solution will be.
By buying an integration solution rather than building, you as the developer enable greater interoperability between legacy systems and new digital technologies, and enable the organization to implement component-oriented solutions rather than monolithic ones. The business IT landscape is changing and becoming more distributed, so you need to have an integration solution that is adaptable; hand coded systems usually are written for a limited scope of work and don’t lend themselves to quick reliable changes. By investing in an integration solution you are driving business value by providing opportunities for the business to change more quickly.
For one company, the core-context model reveals an interesting situation. At the Domino’s Pizza chain, making pizza is actually a context activity. What differentiates them, and is core to the business, is their ability to deliver a hot pizza within 30 minutes.
In the case of our customer, it is the power and flexibility of their online portal that enables a better customer service, and is therefore core. The integration of the systems enables the process to work faster without errors, which is essentially table stakes these days.
By using the Flowgear integration platform, businesses can focus on the systems that are critical for customer success, and leave all the standard integration issues to Flowgear.
You can download the Flowgear technical overview to get more information.