[Towns and Cities, Case Study, Data Management, Projects, aviation, Application Integration, News, CRM, Data Governance, Data Quality, Real Properties, ARINC 424, Cityworks, Flow, airmarket, data]

Is a Managed Integration Service (MSP) the Right Approach for Me?

Great team leaders know when to take charge and when to ask for help; so could your team benefit from a managed service provider helping run your system? Or would you be better off with your own experts? We break down when might be the right time (or not) to use a MSP.

'Application Integration- the term that means, essentially, data should be able to flow freely from application to application, letting them work together - is often an afterthought.  It is often seen as just another line item on the long list of requirements for system acquisition. 

Notionally, this seems right.  After all, how hard can it be to connect two systems and have them share and exchange data? But, if your integration breaks or fails in any way, who do you call? Maybe your I.T. department.  But, if you are IT, how do you fix it?  By then, those who implemented the system and knows the inner workings of it may be long gone (at least contractually).

This is where a Managed Integration Service may be a business-saving option. 

In this article, we'll cover off the following:

  • What is a Managed Integration Service?
  • When is a Managed Integration Service not a good fit?
  • What are the internal options to consider?
  • What to consider in a first meeting with a potential provider

 

What is a Managed Integration Service?

There are three main ways that you can procure services to manage technology implementations and ongoing operations:

  1. Project-Based Service: A fixed price and managed implementation of technology. It's typically procured based on a set of requirements, a scope of service, and a fixed timeframe. Many technology vendors leverage system implementers to install, configure, deploy, and manage the project and change processes through the implementation.  Technology licenses may be bundled as a project deliverable or negotiated separately.

  2. Hourly Consultant: is typically brought in where there is uncertainty in requirements and scope or for break-fix scenarios.  Hours may be prepurchased at a discount, and there may be several hourly rates to secure the range of services available from a provider. An important consideration is that purchased hours may expire if they are not used within a set timeframe.  Prepurchased hours are represented as a liability on a consultant's balance sheet and revenue is only recognized once hours are used.

  3. Managed Service: responsibility for the uptime, upgrade, and performance to a level of quality is ceded from your organization to a third-party provider for a subscription term (typically renewed annually or negotiated for longer periods).  The third-party provider negotiates a service-level agreement with you that identifies the performance standard, along with response times by issue criticality.  Third-party providers have incentive to proactively monitor and update the system to ensure performance, often through automation to reduce their internal costs. Automation directly benefits the customer by anticipating level-of-service performance issues before they affect the customer.

Managed Integration Services focus specifically on your integration platform - the middleware that manages the message or data exchange between your applications, your sensor networks (traffic, SCADA, building automation and occupancy, etc.), and your analytics and data visualization tools.  From an integration platform perspective, you should expect your third-party provider to:

  • Update the integration platform annually;
  • Ensure that optimum message-handling load is achieved;
  • Support the escalation and resolution of dropped or undeliverable messages;
  • Provide the metrics and reporting; and,
  • Advise on plans to integrate additional systems or add more capacity.

Ideally, your team should also have access to use the integration platform to build and operate unmanaged integration workflows (the level-of-service agreement does not apply in this case).  And (bonus), a visual development environment for integrations allows for less technical staff to build data and application integration workflows.

When is a Managed Integration Service not a good fit?

If your organization has strategically selected a One Platform strategy, then a Managed Integration Service is not right for you.  What does this mean?  And, why not?

A One Platform technology strategy attempts to procure all required capabilities that an organization needs from one platform - typically software or software-as-a-service.  Think Salesforce.com, SAP, Oracle or Microsoft's D365.  This allows you to focus your training resources on one technology stack and in-source the people needed to support the platform.  A One Platform technology stack typically has integration services built in; it's just an application or service type that enables the data exchange, or more likely the workflow automation between the various vendor- and partner-developed modules.

Remember, a One Platform strategy is meant to address all of the business needs of an organization within a single technology stack.  This approach works well in private industry, but the public sector is not typically able to do this due to procurement rules and regulations.

Are There Internal Issues that I Need to Consider?

When you engage with a third-party managed integration service provider, you are inviting a partner into your organization.

There is a clear delineation of roles and responsibilities regarding integration and therefore clear accountabilities - just like one of your internal departments.  Communication and setting clear communications channels and a cadence of regular contact is the key to a successful relationship.

There are some specific issues to keep in mind around the network and environment access, as well as coordination of updates to the integration platform and supporting services.  A Shared Responsibility model helps to clarify the overlap areas for maintenance of the technical environment.  Specifically:

  • If your integration platform is deployed in your environment, then you are responsible for maintaining the core operating system and provision of virtual machines (or virtualized application containers) to deploy the integration environment.  Just like other business applications, updates to the core operating system or virtual environment need to be reviewed and approved prior to any updates.  You will also need to provide network access to the machine to enable monitoring and reporting of performance and uptime for the integration platform.

  • Your third-party provider is responsible for managing the integration platform application, including setting up your users if desired or available, as well as break-fix and escalation for dropped or undeliverable messages that they cannot resolve.

  • If your staff are deploying integration workflows on the integration platform, these are usually considered unmanaged.  You are therefore responsible for error escalation for dropped or undeliverable messages.

  • This is not an exhaustive list, but your level-of-service agreement should enable you to add responsibilities as any issues are resolved.  Note that your pricing may be affected if changes cause the extra expenditure of internal resources on an ongoing basis.  Or, there may be a one-time fee to implement modifications to automation to support new responsibilities.

What to consider in a first meeting with a potential provider

In a word - alignment. 

This is your first date, and first impressions are important.  What you are looking to do is to build trust, and to ensure that your potential partner is aligned with your values and the way you do business.  If your third-party vendor prospect is focused on closing the business, you'll know right away that you're a number.

It is important that they are competent, understand the challenges that you are going through, and demonstrate that they are transparent in their approach to their business, any numbers presented, and any other important aspects of your business.  At the same time, you should feel like there is a process that they go through to select customers (that's right - the fit is both ways) and onboard through a sales process where they are setting clear expectations for next steps while providing you an opportunity to learn and ask questions.  

You'll know if you are not aligned.  If you don't see alignment, do yourself -- and your prospective third-party vendor -- a favor and just state that you'll be going in a different direction.  Or, at the end of your first meeting, you should know what to do next, and what you'll need to learn to proceed.