Integrability

Table of Contents


INTEGRABILITY

TTM ROI Sellability Agility Reputation
The ease with which other areas of your business (or external parties) can integrate and consume your services.

I’ve talked almost exclusively about either the qualities that affect a business internally, or the ones that affect users, but I’ve not yet discussed any qualities that directly affect other consumers of your service. Something I’ll remedy now.

Most integrator customers don't (and shouldn’t) appreciate every nuance of your business/domain/product, so decluttering and simplifying (where appropriate) are useful tools. And just like your users, the people who choose to integrate into your services deserve a simple, coherent experience. The act of making your software services integrable is a good step towards building a quality product that will entice custom.

Firstly though, we should recognise that the terms customer and user are not always synonymous. Some businesses sell directly to their own users, whilst others sell their solutions to other businesses, who in turn may have their own users. A customer then, can also be a business entity, who uses your solution in order to fulfil a business obligation/operation for their customers. We sometimes distinguish them as clients to prevent confusion.

INTEGRATION MODELS

The two common sales (integration) models are:

  • Business-to-Consumer (B2C). The business sells its services directly to the consumer. In this model the consumer (user) solution integrates directly with the business services.
  • Business-to-Business (B2B). In this model two businesses integrate their solutions together. Consumers integrate directly with one, and indirectly with the other business.

Integrability is relevant in both scenarios.

CLOUD EXAMPLE

The SAAS-based solutions in the Cloud offer up a good example. Not only did the cloud vendors build reusable services for their own users, but they also saw an opportunity to sell those same services to other businesses who could use them for their own users. It's also a good example of how businesses evolve. A feature may begin life by solving an internal problem, before you discover its wider potential - you should be prepared for such an eventuality.

It’s a case of Eat Your Own Dog Food. The internal solution must be good enough to be exposed to people with zero knowledge of your business.

Without good integrability it’s likely these services would have experienced less uptake. In fact, if you look closely at the major cloud vendors, it’s clear they’re putting enormous effort both into simplifying the experience, but also ensuring that their services are highly integrable and integrated (with other services). This is to their advantage - customers can be far more productive (TTM) by focusing on their business problems, and they also get increased customer stickiness (retention).

A major part of a successful integration depends heavily upon the integration’s quality. There are several ways to achieve this. One is to provide good, clear documentation. This will help, but it’s only as good as the solution being offered. Another option is to look at all of the Assumptions your solution makes. Do they make sense to someone outside of your organisation? Another option - and potentially the most obvious one - is to place yourself in your consumers' shoes.

CONSUMER-DRIVEN APIS

Following the practices outlined in Consumer-Driven APIs enables us to build solutions with a focus on our customer integrators, rather than from a bottom-up, service-owner mindset. This ensures we:
  • Add responsibilities in the right place.
  • Use sensible naming conventions that make sense to our integrators.
  • Only expose necessary fields.
  • Structure the input/output based on consumer need, not on service owner desires or internal complexities.
  • Arrange the API end-to-end flow in favour of the consumer.
  • Have well documented APIs.
  • Secure them in the way best suited to our consumers (whilst still meeting our own security policies).
  • Employ modern/common API and data transfer technologies (currently REST & JSON).
  • Create consistency. A personal preference, but if I had to choose between consistency or great APIs, I’d opt for consistency. Of course I’d rather have both.

IMPLEMENTATION & INTEGRABILITY

One to watch out for is if the underlying implementation technology pollutes integrability. It shouldn't.

I remember our team investigating a new persistence technology that seemed good on paper. It met many of our qualities, but as we delved deeper we found it lacking an out-of-the-box paging solution - a key requirement for us.

Had we continued down that path, we’d either have created integrability issues for our consumers, or we’d have been forced to build our own solution to the problem and then encapsulate it from them. Neither option was good, so we discarded the technology in favour of something more forgiving. The underlying technology choice should not dictate the integration experience...

PILLARS AFFECTED

TTM

Poor Integrability may affect TTM in two ways:

ROI

Poor integration practices can lead to additional support work (Unplanned Work), and thus costs. Why? If the integration effort is significantly larger or more complex (thus longer) than anticipated, then it’s quite likely that you’ll need to lend support (i.e. money). This places undue (and unexpected) strain upon your business, shifting (potentially expensive, or bottleneck) staff away from other important work items.

SELLABILITY

Most customers undertake some form of technical due diligence during the sales process and prior to signing a contract. This is their opportunity to test out not only the technical feasibility, but also the integration experience. Simply providing an acceptable level of functionality is not (and never should be) a sufficient end game. Those features should also be accessible in a (convenient and consistent) manner to support sales. Solutions displaying poor Integrability will therefore score lower and are less appealing to prospective customers.

AGILITY

Highly integrable solutions tend to make fewer Assumptions and are thus more reusable. This gives the business more options, and thus increases their Agility.

REPUTATION

In an API-driven marketplace, poor Integrability can affect branding, and prevent uptake. A good (if old) example was the battle for supremacy between two major players in the console market. One system had a set of extremely powerful APIs/libraries that could do (at the time) things of great wonder, but they were (comparatively) difficult to work with. The other provided a set of APIs/libraries that were built for ease of use, thus finding general favour with developers, so greater uptake.

I've witnessed similar things. If Integrability is hard, then Change Friction may come into the equation.

SUMMARY

Integrability represents the ease with which other parties can consume your services. Its main focus is on the service consumer, not the user.

A poor integration experience can put potential custom off and can slow down your business (as you support integrations); a good integration experience can entice them to make further integrations. You can have a strong product (at least in terms of features), but a poor integration experience. This is concerning in a world where many things are becoming “as-a-service”, and integration is a first-class citizen.

The best way to achieve good integrability is (quite simply) to put your integrators first. Understand their motivations and needs, and distinguish them from your (internal) business needs. Introduce what your integrators need, and now return to what you need, finding ways to incorporate both (ideally) without polluting the experience.

FURTHER CONSIDERATIONS