Why Select a Platform Over a Best-of-Breed Technology Stack?

Nov 09, 2021 • Features • White Paper • Digital Transformation • Exel Computer Systems • Data Management

In the second feature from a recent white paper we published in partnership with Exel, we outline how an API works and why service organisations should invest in a series of best-of-breed solutions and combine them all in a technology stack.

This feature is just one short excerpt from a recent white paper we published in partnership with Exel Computer Systems.

www.fieldservicenews.com subscribers can read the full white paper now by hitting the button below.

If you are yet to subscribe you can do so for free by hitting the button and registering for our complimentary subscription tier FSN Standard on a dedicated page that provides you instant access to this white paper PLUS you will also be able to access our monthly selection of premium resources as soo as you are registered.

Data usage note: By accessing this content you consent to the contact details submitted when you registered as a subscriber to fieldservicenews.com to be shared with the listed sponsor of this premium content Exel Computer Systems who may contact you for legitimate business reasons to discuss the content of this white paper, as per the terms and conditions of your subscription agreement which you opted into in line with GDPR regulations and is an ongoing condition of subscription.

In the previous feature from this white paper, we looked at how the easy flow of data across various modules within a platform can improve both the efficiency of your service delivery and ensure you are meeting your customers’ expectations. However, in a world of APIs where everything is expected to work wonderfully and connect via plug and play, why shouldn’t a service organisation invest in a series of best-of-breed solutions and combine them all in a technology stack?

As a starting point, let us first take a moment to better understand what an API (Application Programming Interface) actually is. Indeed, API is an acronym often thrown into a conversation but perhaps not so well understood for those of us who are not software experts.

To outline how an API works, let us take a more straightforward example.

Imagine you’re a diner in a restaurant with a menu of choices to select from. The kitchen is the part of the ‘system’ that will prepare your meal. However, you cannot just go to the kitchen and place your order directly; this would slow the Chef down and delay service for you and everyone else in the restaurant.

The critical link required for you to communicate your order to the Chef and deliver your food to your table is a waiter.

At a very rudimentary level, the waiter is an API. They are the messenger that takes your request and informs the Chef of what is needed. Then when the Chef completes the task, the waiter returns to deliver the response (in this case, your meal) back to you.

So far, so good.

However, now let’s expand the analogy to fit better the many moving parts of a mission-critical activity, such as field service. In a best-of-breed technology stack, we are no longer dealing with one waiter; we are dealing with a waiter for each aspect of the meal. One Waiter to take our order for our appertisers, another for our entrée. We have a Concierge to ensure we are sat at an adequate table, a Sommelier to take our wine order, a Dessert Waiter and so forth.

Then each of these additional waiters will be linking back to a different part of the restaurant.

The Commis Chef will be responsible for delivering one part of the meal, the Sous Chef another, Chef de Partie another. The Bartender is responsible for providing drinks expertly recommended by the Sommelier, and working in an entirely different part of the building.

Anyone who has been to a high-end restaurant will know that such complexity can be managed and delivered effectively to drive a standard of service that is exceptional.

However, anyone who has worked in such a restaurant will tell you that it takes a phenomenal amount of work to keep the lines of communication and the flow of productivity moving across the shift. Indeed, this is why good restaurant managers that can keep all of these connections, these ‘human APIs’, working in unison, are worth their weight in gold.

"With a platform approach, the links between modules are within the architecture of the solution itself, updates would have been fully tested system- wide prior to deployment. Should an issue occur, you have one point of contact to seek swift resolution..."

However, for the field service organisation, whose function is to serve their customers, not manage a complex web of systems and technology, is this an optimum approach?

In a best-of-breed technology stack, a company becomes exposed to various elements, reliant on multiple APIs being aligned across numerous updates.

As with the restaurant example, managing this takes a lot of work. Any one of the elements the stack is comprised of could become a broken link the chain, having a knock-on effect across the stack. It has to be questioned whether such a complex solution is worth the risk.

For example, if the integration between two integral systems within your technology stack fails, to which of the two providers should you turn to resolve the issue?

With a platform approach, the links between modules are within the architecture of the solution itself, updates would have been fully tested system- wide prior to deployment. Should an issue occur, you have one point of contact to seek swift resolution. With a platform approach, a lot of the responsibility shifts onto your solution provider to make things work. Of course, this also means less heavy lifting required from your internal IT team.

With the technology stack, your IT team can spend all of their time making the multiple solutions talk to each other, bouncing from one solution provider to the next in an endless cycle of updates and new integrations.

This can be a drain on resources, both financially and in terms of man-hours, both of which could be better spent focusing on growing your business and keeping your customers happy.

As we saw in the previous section, the seamless flow of data across an organisation can be the difference between service failure or service excellence.

Do you really want to be exposed to multiple potential weak links in the chain, especially when the one platform approach overcomes this?

This feature is just one short excerpt from a recent white paper we published in partnership with Exel Computer Systems..

www.fieldservicenews.com subscribers can read the full white paper now by hitting the button below.

If you are yet to subscribe you can do so for free by hitting the button and registering for our complimentary subscription tier FSN Standard on a dedicated page that provides you instant access to this white paper PLUS you will also be able to access our monthly selection of premium resources as soo as you are registered.