Making in-house and 3rd parties co-exist

How often have you worked in an organisation that uses either 3rd parties or in-house development exclusively or a company that has tried (and often failed) to embrace the best of both worlds only to become unstuck as an us vs them mentality sets in? How often have you heard;

  • Out sourcing this piece of work is cheaper than building it in-house
  • Out sourcing will reduce the quality of my platform
  • In-house is risky because it isn’t a fixed cost
  • Out sourcing means we don’t own the code base
  • If we out source we are tied into that provider
  • Delivery in-house or our selected partner is slow
  • If we out source, and attempt to bring it back in-house there is lots of costly refactoring

After much thought about this very problem, I have a solution which leverages the best of both and could be applied in any company.

The solution

The company has an in-house capability which builds and owns the ‘Core’ platform and the build framework. The ‘Core’ is functionally very basic, it has the basic journeys built but no enhancements; the platform is the actual product.
The build framework is the 3rd parties interface to deliver their pieces of work. The framework is automated to support feedback loops so that the 3rd parties knows it has built software that adheres to the company standards (pass / fail CD loop and statical code analysis). The in-house team ensures the platform is stable, and optimises the ‘Core’ so that it is scalable and extensible. Over time they may even refactor code checked-in by the 3rd parties and / or bake in 3rd party features into the ‘Core’ of the platform.

The 3rd parties build rich-functionality features, which have to pass through the build framework created by the in-house development team. 3rd parties would use BDD’s so that the company has a way to trace and document requirements delivered as well as creating testable packages of work.

Business value

You may be asking, ‘Ok Carl, but where is the business value?’. The value is;

  • High quality. The business manages the quality of the end product by dictating the build framework.
  • Benefits from having a Continuous Delivery pipeline (including Continuous Integration). See Continuous Delivery – Return on investment and release frequency post for benefits
  • It allows multiple features to be delivered simultaneously across any number of 3rd party suppliers, therefore giving the company a way to reduce timescales of delivery in large programmes of change to an existing platform.
  • Reduces the price of the 3rd party build costs as they’re is little / no need for the 3rd parties to have QA involvement.
  • Not tied into one 3rd party supplier
  • Removes ambiguity of 3rd party deliverable’s
  • Code based remains property of the company
  • Embracing the certainty of fixed price (though this is more management myth than a true statement) within a quality driven environment. Corners cannot be cut..

Think of an e-commerce website.

The company builds the very basic end to end site and the build framework which includes all testing types (acceptance, performance, penetration, etc…).

The company wants to build a new checkout process, they put this out to tender with 3 different agencies. Agency 1 is the best fit based on timelines and cost. They agree to a fixed price and start the development of the checkout.

As the agency builds the solution, they check-in their code into SVN which is the companies source control management solution.

At the same time as Agency 1 is building the new checkout, the company realises it needs a new analytical solution. The company goes out to tender the work, and Agency 2 is the market leader of analytical implementations. Agency 2 begins work on the analytical solution at the same time as Agency 1 builds the checkout.

The new e-commerce platform is delivered in the cheapest possible way (by being able to put out to tender the work to the widest possible 3rd parties) and within the quickest timelines through parallelisation, without jeopardising the quality of the product. The amount of concurrent work can be infinite without jeopardising the quality of your platform and still being able to release quickly.

Back to Top
Have a chat with us info@acue.io
We use cookies in order to give you the best possible experience on our website. By continuing to use this site, you agree to our use of cookies.
Accept