360 Solutions – when to build and when to buy

In Short : With so many off the shelf products, how do you decide when to create a custom 360 solution rather than buy one? Noel Ady, gravity9 Founding Partner & Lead Consultant discusses the challenges and possible solutions.
Joe Bloggs

Joe Bloggs

Managing Director

Noel Ady

Noel Ady

Founding Partner & Lead Consultant

With so many off the shelf products, how do you decide when to create a custom 360 solution rather than buy one? Noel Ady, gravity9 Founding Partner & Lead Consultant discusses the challenges and possible solutions. Whether to build vs buy digital products has divided opinion over the past 10 years especially, now that, more recently, we have so many more options available to us, via cloud platforms. The trend we are seeing, at present, is that organisations are preferring smaller, more specific, products and services to fulfil a variety of business needs; rather than buying one big product to provide a blanket solution. Noel Ady, Founding Partner and Lead Consultant at gravity9 solutions discusses the five key challenges when buying a digital platform and, why, for a 360 solution you should always opt for a custom build. At gravity9, we help organisations build strategic digital platforms and it’s what I’ve been doing for over twenty years. Quite often, these are built in the form of digital service layers with the customer 360 view platforms on top to help unify and serve multiple businesses, and departments enabling them to read and interact with data that may exist across multiple systems. A common approach to building a 360 view often manifests as an implementation within (Customer Relationship Management) CRM product. Naturally, this feels like a logical a solution, as the sales pipeline is close to the customer journey and leads into additional services and functionality. Organisations often feel more comfortable with the CRM product solution as it means no ‘custom development’, and early implementation, often, returns a number of key advantages such as out the box, reports, charts and simple editing screens. The Challenges If this is the case, why are we seeing so many organisations looking to replace CRM solutions with a custom solution?  Let’s break down some of the key challenges with a CRM product, in order to support a 360 implementation.
  1. As previously mentioned, the early days with a new CRM system provide the things you need quickly and effectively. However, the problems arise later on. After months, maybe years, the business places additional demands on the platform and as a result, custom development can creep into a nice clean CRM system.
  1. A CRM solution is more often than not entity focused. This means you define some of custom entities in order to support your business needs. For example, if you are selling vehicles, you will likely have an entity configured to represent a vehicle or a sales agreement or a potentially a vehicle option entity. Some of these entities are well suited to a CRM process and some are just additional data. What’s the problem with this?  I believe designing a system to the data is a fundamental flaw in engineering and will impact your long-term business needs. When you have entities designed, you effectively externalize the logic you apply to that data; you push the logic out to the side (plugins for example in a CRM solution). Over time this external code becomes replicated, convoluted and difficult to manage, ultimately, because the behaviour is a bi-product (or afterthought) to the data structure.
  1. The other observation we have seen in CRM solutions in place for some time is the more the CRM is customised, the less you get out the box (reports and screens) and the harder it is to upgrade. Heavily customized CRM implementation quite often requires a huge amount of effort to upgrade to the latest version, which is costly and time consuming.
  1. An area, often overlooked is the cost of custom development within a CRM product. CRM developers are usually in high demand and it’s a niche skillset, as many developers prefer writing software rather than restricted to the confines of an off the shelf product.
  1. As a result of the previous challenge, finding skilled architects in to work on the product can be very expensive. Simply sourcing architects to support and maintain what is already in place can be difficult, let alone build new features. When thinking financially you must remember; your CRM will have license costs as well. So, you pay for the software, you pay for the development and then you often pay for upgrade efforts due to customisation.
  1. When you build a 360 solution you often need your data to be pulled and organised in a way that enables you to showcase information on a single screen or set of screens. CRM solutions are good at holding entity information, but a 360 view requires a high volume of data from multiple sources. This increases the product’s data complexity and reduces performance. Centralising your customer / product or service data in a CRM means investing in heavy integration into the product. But, is this really the best place to hold all that data together?  Surely, there more efficient and reusable ways to do this?
The Benefits of Bespoke When we consider custom development today, we should recognise that many frameworks exist to accelerate the development time. Frameworks such as MVC or client script frameworks as well as backend data libraries allow us to build quickly against various data stores such as MongoDB and of course SQL server. In addition, cloud providers offer a plethora of out-the-box services such as rules engines, AI, image processing and workflow to name a few. When combined, these services can create powerful capabilities able to improve the customer experience, increase competitive advantage and flex to fit business changes. Custom, is Custom; Make it Work for You With a custom build the solution is in your hands. Building custom gives you the ability to apply best practice engineering to your new platform. Utilising practices such as domain driven design helps design for behavior and treat data as a bi-product. This is far more organised, flexible and manageable than being data driven and allows us to centralise logic in specific reusable services and build custom data views on the data generated as we build out behavior. From my experience, this approach is far more capable of supporting change and unknown requirements, allowing for a more agile and flexible platform to support your business strategies. Building for the future not just for the present is a major part of a successful 360 solution. Initial architecture is important and requires the correct skills. Once you have a defined and built platform, your solution will be based on standard technologies rather than product. This opens up your options for support and enhancement work. A capable dotnet developer is generally less expensive and more available than a CRM developer.  In addition to the resource cost, remember, the only license fees are based on the running components (cloud services). You don’t have the ever-growing seat license problem, meaning you don’t have to restrict access to your 360 solution. A major advantage, given while premise of a 360 platform is to provide broad audiences with broad data and behaviour. When well architected, a 360 platform should be appropriately separated and made up of many smaller components (microservices for example). This segmentation means upgrading tech stacks and moving hosting providers should be possible with minimum effort. And we overcome the tight vendor lock in issue found with a CRM product implementations. Data is of course a big part of the 360 solution. Segmenting and separating data under specific services and data stores allow us to pick and choose which data technologies best fit the various data use cases. Rather than pushing all data into a custom CRM’s database, we can make our data more organised and available via specific services. Providing not only cleaning transaction boundaries but also reusable data and behaviour around the data. Here we can integrate once and use everywhere. When we build a platform made of smaller services and components and even separate out our UI (micro frontends) we get few dependencies and can have parts of system effected by feature changes, rather than all of the system, in the case of a monolithic product approach. Always go Custom for 360 What I’ve outlined provides a high-level opinion on building a custom 360 platform where a bespoke build is considered to be far more effective approach due to the broad range of data and behaviour needed for such a platform. It’s not to say a CRM does not have its place in an organisation, but for a 360, we’d always recommend a build approach, and, of course, always recommend you speak to gravity9! ‍

STAY IN TOUCH

Subscribe to our insights

We are a friendly bunch and always happy to discuss ideas for helping organisations use
technology realise their vision and improve experiences.

Your next read

Gravity logo