One of the two pillars of “doing” Enterprise Architecture is the establishment of a set of architecture principles that guide design of systems in the organisation (the other pillar is understanding the system elements or components and their interplay). However, most organisations struggle to establish a coherent set of principles that are practical for interpretation on IT projects. In this and other blog posts I explore such principles; the one for today is the oft loved (and hated) principle of buying before building.
What is the principle?
The principle, in essence, declares the intent that the organisation in question will attempt to buy IT solutions “off the shelf” before starting to build.
Why is it useful?
At the outset this principle appears to be a “no brainer”. Why would anyone want to build an IT system from scratch when one can “plug and play” so to speak, especially considering the horrendous failure rate of custom development projects? While the strategic intent of this view is commendable, the implementation of this guideline is not so straightforward.
Digging deeper
As one starts to look at the application of this principle, several questions start popping up. Should this be applied in all situations? When might build be a better idea than buy? Gartner’s pace-layered application strategy, for example, can be used to answer this question: it makes obvious sense to build the so-called systems of innovation, buy systems of record (with minimal customisation), and customise an off-the-shelf solution for systems of differentiation.
The other angle to this principle is to explore what additional guidance needs to be applied for the kind of buy or build? For example:
Buy
aPaas vs SaaS vs On-Premise
Within aPaas: Multi-tenant vs dedicated instance
Build
Choice of development frameworks / languages / toolsets
Containerised/serverless vs traditional applications
Obviously, the answers for these questions will largely depend on the organisation’s business and IT strategy and the drivers behind these strategies. And it will also depend on other architecture principles such as the appropriate hosting strategy (which cloud?).
A final point to explore in the case of buy-and-customise scenario is how much of customisation to do. For example, if you are customising more than 50% of the product (“bending it out of shape”) then alarm bells should start going off: perhaps the business sponsor had a system of innovation in mind and IT thought they were signing up for a system of record? Or perhaps the choice of SaaS / aPaaS was not a good fit. Also how do you estimate percentage of customisation before the project commences (topic for a future blog post)?
A body, such as the Architecture Review Board – with appropriate representation from business and IT – can deliberate on the specific circumstances of the organisation and arrive at a more practical interpretation of the principle to guide the project or solution in question.
Practice of EA 