Driving Growth In UK SMEs With Digital Transformation: Part 2 - Integrate

Driving Growth In UK SMEs With Digital Transformation: Part 2 - Integrate

This is the second article in a 4-part mini series written to help UK SMEs drive growth and create enterprise value by following a simple 4 step framework:

  1. Consolidate
  2. Integrate
  3. Automate
  4. Innovate

You can find the full framework complete with support on the Full Stack Consulting website.

In Part 1 we explored the Consolidate step, which is designed to:

  • Deliver a clean digital foundation
  • Eliminate wasted spend that can be redirected to create value
  • Save time by managing infrastructure, systems and outsourced vendors more effectively.

Part 2 will focus on the Integrate step.

The Integrate step is all about connecting your IT estate, sharing data between your various systems and eliminating data silos.

It sounds simple but there are nearly always complexities due to a mix of the following:

  • Some systems might have been commissioned literally decades before others
  • Computing paradigms change over time, eg mainframe systems -> PCs -> Internet -> Cloud
  • Different systems store data in different formats
  • Different systems expose data using different protocols
  • Some systems can handle high throughput, others can't
  • Some systems validate data well, some don't validate data at all
  • Some systems assume a certain type of data must be unique, others allow it to repeat
  • Etc, etc

Over time, as companies grow they add systems to their IT estate. Usually this is to provide new capabilities, but sometimes, especially when growing through acquisition, new systems are acquired that duplicate, or at least overlap with existing systems.

Not only does the IT estate grow larger and more complex over time, but data volumes grow. Unless there is a particular focus on data quality it is, unfortunately, common to see IT systems fill with low quality data. This might be due to absent validation and enrichment, for example absence of a postal address lookup, or it might be because people don't have the time, or inclination, to keep CRM records adequately and accurately updated.

Regardless of the cause, low quality data is a barrier to successful integration between systems and you MUST know what data issues need solving/mitigating before building integrations.

Assuming we mapped out our IT estate and tidied up our data as per Part 1- Consolidate, how do we go about integrating our systems?

The first task is to understand what type of integration you need.

Do you need to process millions of micro transactions per day in real time?

Do you need to be able to add/remove systems to/from your IT estate frequently?

Do you have an internal technical team who can manage your integrations or do you rely on outsourced IT partners?

Do you want to empower citizen integrators across the business or just the IT team?

Depending on your objectives you should choose a different set of tools. You can read more about the detail of systems integration in my article from 2020.

Some are developer-led, eg event streaming and message brokers, some are targeted at less technical business users and some are hybrid, bundling code, low code and no-code into a single solution.

The last time I scanned the market I compiled a list of approximately 100 IPaaS, data integration? and event streaming/message brokering tools. IPaaS, or Integration Platform as a Service, is a cloud based tool that you purchase on a subscription model and that gives you reusable building blocks that most integrations are built with in order to speed up your integration efforts. Today IPaaS is the fastest growing tool used for system integrations.

Picking the right solution from all of that choice can be tricky, but it matters. It matters both in terms of the suitability for the use case you are solving for as well as commercially.?

From the perspective of usability you will find that some tools aligns better with your target users than others, some will be designed for speed of integration while others may focus on robustness, some might focus on real time capability and others on large data volumes.

From a commercial perspective, some integration tools are charged on throughput, some on per user licences, some on number of integrations while others have open source licences that your dev team can use.

The decisions don't stop once you have chosen the tool.

Next up is implementation patterns. The last thing you want is an integrated estate where every integration is handled differently with no respect for a common set of integration principles with each integration owned by a different team member. Very quickly this will become an unmanageable mess.

Instead, start by agreeing the integration patterns that best serve the objectives you outlined previously. For example, in a fairly small estate where a handful of systems only integrate with one or two other systems it might be optimal to integrate systems directly. But on a larger estate where multiple systems must be connected with several other systems then it can be optimal for your integrations to build in abstractions and reusable flows.

And finally before, before integrating two systems, be sure that it makes sense. Do the numbers stack up? Ask questions such as:

  • How long will each of these systems exist in our IT estate?
  • How difficult/risky is the integration?
  • How much effort will this integration take and how much will it cost?
  • What is the value of integrating these two systems? (Remember that time saved due avoidance of errors due to manual input is often a large source of value)
  • How much time will be required to manage this integration once it is operationalised?

Now you're ready for Part 3 - Automate, coming on Thursday.

要查看或添加评论,请登录

Graham Roberts的更多文章

社区洞察

其他会员也浏览了