Buy a commercial software or build it yourself? This is a question that frequently comes up in IT departments. The classic answer distinguishes core and context, and invites you to build your core business tools (implied: those which are business differentiators) and buy what makes the context. But does this binary approach stand up to the test of experience?
A brief history of commercial software
The software market has seen a significant pendulum swing in 20 years.
At the beginning were ERPs and their promise to unify all company activity (production management, accounting, customer file, etc.) in one piece of software. These solutions consumed most manpower of IT departments and enabled the emergence of very large companies. But their strength also constitutes their great limitation: just as coloring is easy as long as you don’t get to the edges, ERP becomes hard when you want to address all the specificities of each business unit, their recompositions, etc.
Between 2005 and 2015, the slogan was “there’s an app for that!”. Each of us has specialized applications on our phone (those that were successful were successful because they responded very efficiently to one need, and one need only) and, quickly, each micro-function of the company (even those who only hadExcel for a long time) were able to benefit from tailormade tools.
The pendulum is swinging back. For the last 5 to 8 years, each application publisher has been trying to conquer new markets and to do so tried to widen their functional scope, to the point of becoming new ERPs.
CIOs often find themselves having to juggle between:
Multiple CRM tools (a general CRM, the segmentation tool, the marketing automation tool, the emailing tool which now claims they’re a CRM, the ad retargeting tool, the more or less omnichannel contact center, the ticketing etc.) or even more if the BUs have made autonomous choices,
several ERPs (but why is it the solution specialized in inventory management and production batch scheduling that manages quotes and customer orders for a particular BU?)
N HR software (the solution chosen to manage training was in fact a complete HRIS, in fact the one to manage payroll too, but it is also an ERP), etc.
Add to this the mergers and acquisitions among software editors, the reboots leaving the flagship solution that you bought 5 years ago and whose integration you have just completed at a high price, and you understand the daily life of many IT departments and their infernal cycle of ERP replacements every 5 years (understand, given the above, that they only change 20% of the IS, since they have 5 of them, and therefore the oldest ERP which is still running your home is probably 25 years old and is cursed by every new employee).
Under these conditions, it is difficult to consider software as a sustainable asset of the company. And when it is sustainable, it is not by its own merits but by the considerable energy necessary to make it evolve.
The difficulty of distinguishing core from context?
How to distinguish core from context without cutting one’s arm, or conversely reinventing the wheel? Arbitration is not always easy.
Some may limit their focus to the company’s product alone… but in certain cases, this is very restrictive when we know today that the choice of a brand depends essentially on the B2C side of the customer experience, where the relationship -customer plays a role at least as important as the product.
In addition to this “customer visibility” aspect, a second axis comes into play when we talk about software: the notion of technological maturity.
Simon Wardley proposed an interesting approach consisting of mapping solutions on a “customer visibility x technological maturity” matrix. This approach allows us to move away from the dualism between make and buy.
The third way: assemble!
On this path to technological maturity, a certain number of solutions have become “commoditized”. For example, today you can do text-to-speech without any knowledge of machine learning, via a simple API call.
But how does the “assemble” approach differ from “buy then integrate”?
The company that buys solutions and integrates them ultimately has N applications, each having its own database, each relying on its own representation of the business process, each depending on the roadmap (and life cycle) of its publisher, where it is often impossible to hide unnecessary screens with adequate app roles (not to mention user identity management, which is often part of the super expensive premium pack). To these, we must add some middleware and end up with system resembling spaghetti. In such an ecosystem, the IT department is full of people who have no focus on the company’s business.
The “assemble” approach is actually radically different. **In this approach, we no longer buy packaged publisher products, but rather bricks to assemble to make a single (and unified) product controlled internally. These bricks have a **much more stable life cycle than publisher solutions, because their design follows the logic of specialization which was the aforementioned “second age of software” ; they do not rely on a data silo; we only mobilize those services that are necessary and often pay for them based on actual usage.
The move to an assembly model requires a high level of dialogue between the IT department and the business lines.
On the business side, this requires giving up choosing your own solutions (often on the basis of pretty dashboards that no one will ever use once the solution is in production) and stop giving in to harassment from software salespeople, and rather express needs/requiremens to your IT department;
On the IT side, this means adopting a *customer-oriented *builder mentality, moving away from over-specialization (a front dev can no longer define himself just by his web-design expertise and must think in terms of User Experience) with the development of an essential skill, that of solutions architecture (which must be distributed among the teams and not just the prerogative of an above-ground architecture cell).
Need help building this customer-oriented builder’s culture? With TerraCloud, I help you develop this solutions architecture mentality in your teams and mobilize the cloud toolbox to build the solutions that will allow you to support your business of tomorrow (and the day after tomorrow!)
Top comments (0)