In the past I was asked to provide a brief executive overview of the state of integration efforts with a vendor's product. I felt that it was an honest, objective analysis so am sharing it here, with some parts redacted. I only had a few hours to put it together so admittedly it is a little unpolished.
Integration Lessons Learned
-
Overview
[Vendor] grudgingly acknowledges that ACME Corporation (ACME) has, over the course of many years, created an expansive codebase that extends the capabilities of the [Application] product. There is an opportunity cost associated with the primitive design of the integration as it stands at this time. That cost is derived from the friction of attempting to integrate with a system that is not meant to be extended.
-
What's good?
There are a couple of places where [Vendor] gets it right.
- HL7 – there are a few places in [Application] that allow import and export of data in the HL7 data exchange format
- Custom reports – [Application] allows a certain degree of customization of reports, though not all features of the toolset are available
- Overall, the amount of integration done by [ACME] developers and consultants is impressive when you consider the simple fact that [Application] isn’t meant to be extended. Regardless, a key part of our day to day operations are based solely upon the hard work and diligence of those who had to discover how to extract information from [Application].
-
What's bad?
There are profound consequences to the integration choices that were made.
- Our code is intimately connected to [Application] database, which in software development is known as ‘tight coupling’. What this means is that the slightest change [on the part of Application] can break our codebase, requiring inefficient emergency patch releases [on ACME's part] to keep everything running. Even more insidious is a change that we can’t detect because of its subtlety- think of the ‘Butterfly Effect’ here. Either way, our company is at a disadvantage because we are scrambling to resolve support issues rather than creating value.
- Rather than a single source of truth, multiple parties over the years have hooked into the [Application] database. Each group might use and interpret the data differently. This also creates more opportunity cost because of the multiple points of failure. The Master Data Management project is a step in the right direction to unify enterprise data.
-
What's the solution?
Integration code should have as loose a connection as possible to its target. A metaphor to describe this is the electrical cord for a lamp. When you buy a lamp, do you connect it directly to the home wiring? Of course not- what if you want to move the lamp to a new location? We all know that there is a plug that fits a standard sized outlet. So how do we ‘plug in’ code to another party’s application?
An Application Programming Interface (API) is a public access point for integration- the electrical outlet from our earlier lamp metaphor. It’s the way that entities can exchange information without being married to one another. Think of the current titans of the internet: Google, Facebook, Amazon, Netflix, and Twitter to name a few. Surely you have used a website or mobile app that displayed information from one of these companies. This third-party integration doesn’t occur by hooking directly into Facebook’s databases- it happens through their public API’s. (See Examples section below.)
As your set of API’s starts to grow, you start to become concerned with enterprise architecture, which is the practice of reducing complexity and cost while increasing agility by rationally and efficiently connecting systems. There are a number of ways to approach this design, and all are beyond the scope of this document.
-
The Future
As new systems are purchased their vendors should be questioned as to the presence of an API. Keep in mind that an API isn’t a right- it’s a privilege. Some vendors probably don’t want customers to have access to their data because they see the opportunity for profit in costly customizations.
As our ability to internally disseminate data in a more modern fashion evolves, unused features of tools that we use every day become valuable. For example, Microsoft Power Pivot allows Excel users to consume data from a variety of sources and perform high-level business intelligence operations from their desktop.
-
Examples
Facebook API
Google API
Twitter API
Amazon API
-
Reference
Why You Might Need an API
APIs: A Strategy Guide
A Comparison of the Top Four Enterprise-Architecture Methodologies
