In today’s market, a company’s digital transformation relies on its ability to get connected. Connecting internal enterprise applications, hosted software-as-a-service (SaaS) applications, vendors, suppliers, and customers is key. At CREO, we believe that means taking an “API First” approach for our clients. An API First approach means that for every new technology selection and implementation, you give priority to API capability, knowing that ultimately the data captured in the new system will be consumed by other technologies as well as by humans.
There are several middleware technologies that enable API capabilities in the marketplace, and they are not all the same. Choosing a middleware technology that aligns with your industry will make your digital transformation easier. If you’re in life sciences, choosing a middleware technology that offers API connectors that are HL7 and FHIR compliant will make your integrations easier and your development lifecycle faster. The same applies for those in the Finance Industry. If your business is in a regulated industry, leveraging middleware technologies that specialize in that space will help make those more difficult integrations easier. Choosing a technology that specializes in a specific industry doesn’t mean you’re only limited to connecting to other regulated applications, however. These same technologies offer your organization the capability to connect across your enterprise.
Middleware: Not just about the technology
It’s not just about the technology, though. Effectively evaluating middleware technologies means understanding both your current and future IT landscape. At CREO, we recommend you start with your data.
Knowing which data needs to be shared across your technology landscape and how often will help you better understand how best to accomplish the integrations. In some instances, the data being shared is only needed by one other system, while in other cases, the data is needed by more than one system. HR data, for example, is often needed by more than one system. In Figure 1 below, you can see that HR system is the master of the data (system of record), and that the HR data is needed in other systems. Your Identity & Access Management (IdAM) system needs HR data for single sign-on (SSO), your Learning Management System (LMS) needs HR data for assigning and tracking training, and your payroll system needs HR data to manage payroll.
Doing It Right: It doesn’t have to be complex or difficult
Why is mapping your data so critical to the success of your middleware selection and integrations? If you were to create point-to-point (or system-to-system) integrations using the HR data illustration in Figure 1, you would need to create 3 very specific integrations. When the time comes to replace or upgrade your HR system, you will need to re-create and/or revise those same point-to-point integrations. Now let’s consider a different methodology, a more loosely coupled integration that uses a message broker. Message brokers serve as an intermediary software that manages the messages being sent, ensuring downstream systems are able to receive the data they are expecting. The message broker can handle a couple of different message patterns. For this example, we will talk about message topics.
In Figure 2 above, the HR system acts as a “sender” which publishes an “event,” also known as a message, to the message broker and stops there. The other systems, IdAM and LMS and payroll (receivers) all subscribe to the same message, and each of them only takes the part of the message it needs. In this type of publish and subscribe architecture, when you need to replace or update your HR system, you only need to recreate or update the one integration pattern (in this case, the publisher/sender). This approach – which illustrates the value of starting with the data in mind – also enables you to better manage and prioritize how much data is being shared with whom.
Starting with an inventory of data assets brings value in other places for your organization as well. Data is easier to govern when you understand the system of record, the downstream target systems, and user access. As you build out the data mapping for where, when, and how much data needs to be shared, you can also incorporate creating the data lineage, transformation, and definitions of your data assets. While having a middleware technology to support integrating your data brings a value all its own, incorporating this data lineage component offers further value by reducing manual and duplicative entry, reducing introduction of human error, and increasing speed at which the data is available. Put more simply, when you include the data asset inventory and data lineage, you build the foundation for data governance.
Making the Connections
Now that we have talked about considerations for middleware and how best to get started, let’s talk more about the systems within the architecture and where they reside. Depending on your company’s IT strategy, the business sector your company is in, the age of your company and the IT investments made, you may have a full on-premises architecture; a hybrid with a combination of on-premise and SaaS; or you may have all SaaS. Some of your systems may not have APIs, so how do you incorporate those systems into your middleware and data sharing need?
Middleware platforms frequently offer connectors which provide a way to directly connect to your transactional systems. We already covered why having a direct connection to your transactional system may not be ideal. In those cases, a Data Query Service is a great way for you publish data from those systems that have ‘get’ only webservices. This data service provides a way for a middleware connector to ‘get’ data without directly connecting to your transactional systems.
All of the concepts we’ve discussed here can also be applied to your vendors and customers. Having a way for them to publish data to your message broker or to leverage your Data Query Service puts the information you need directly into your data ecosystem in an automated, controlled, secure and trusted way.
In Summary
As you consider your company’s digital transformation, consider an API First approach. Incorporate your data needs, then lay out a plan for sharing and integrating in way that makes the most of your data and information assets. Starting with an API First Approach means you are giving thought for how best to manage and share data across your ecosystem.
