Photo Cred: Human Stories Photography

An API is an Enterprise's expression of the conversation they want to have with the outside (digital) world

API's are growing in their relevance to Enterprise strategy as the Digital Economy grows.  With this growth, it becomes the most effective mechanism to participate in the global marketplace.  With that opportunity comes the need to design and develop these services effectively.

Using our experiences from developing functional integration interfaces and contracts and exposing them through ESB platforms over the last 20 years, API becomes a natural extension of our skillset.  

The challenge in API is not technical, it is ensuring that they can meet the market, measurably and with maintenance in mind.

greymatterdigital seeks to work with Companies and Enterprises wanting to get it right once and create revenue channels using technology.

Integrating at an interface contract is not new, indeed it has been happening for nearly 30 years.  Certainly with the advent of the ESB and Enterprise Application Integration (EAI), organisations have been connecting their internal systems and outwards for a long time.  Service Oriented Architecture asked us to first lift our eyes out of the technology and to what would serve our Enterprise Architecture the best - and although it became a cliche the concepts were sound.

WSDL and SOAP and collecting operations together in an interface contract have been (and still are) viable and complete ways of working in an API sense (even if they can be a little over-described, complicated and difficult to change).

So that brings us to API.  What is it about API that is moving the needle, well it probably comes down to 3 things:

1. We have matured enough through SOA and ESB Integration to now talk openly about the right types of contracts, who can consume them and why?
2. Businesses are mandating more and more movement toward digital initiatives (digital transformation, application economy and digital marketing) and for that they need agility, an ability to move quickly to new initiatives and a need to do it without the complex contracts and slower go to market of iterations past.
3. Technology has evolved to the point where it can not only house the interfaces (and their abstraction to the systems underneath) but also demand that they are executed quickly to service the throughput required now and into the future.  And because we now can do what we need, we are rushing to do it!

Caution!

Given our many years of experience which has seen us move through B2B, B2C, EAI, ESB and now API we are keen to see some of the sins of the past not repeated.

These are typically shown to be any one or more of the following:

1. Coding APIs early in the project - because functionally they are not difficult to deliver which means they proliferate quickly.  However they are typically not designed with scalability, extensibility and just as importantly maintainability in mind!
2. Building APIs based on project need, not business need.  e.g. Our project needs to receive Sales Orders so let's build a Sales Order service - often this is not aligned to what a Sales Order needs to be for the enterprise, but more about what data is being received and the quickest way to ingest it.
3. Allocating a large amount of project time to testing rather than design.  More expensive to fix later in the cycle and typically it means that not enough discussion / design / elaboration was done early enough in the project so as to minimise the amount of required testing.

The intrinsic mindset of well developed APIs

To be successful at API development is to accept one thing - typically APIs are built on the bedrock of a well established ESB or at least a well understood Data Model - these components rarely change and if they do, it is rarely a complete shift of focus.  A well-built API takes the business needs in mind and works to domains and concepts - the individual services probably change often or at least the front facing ones do.  

A well-developed API needs to move with Agility but utilise the Stablity of the ESB / data layer below it and allow the business to explore how to expose and receive that data and then innovate the way they represent that to their consumers!

If you would like to have a further conversation with us about API development, management and governance or even to discuss the above, please contact us at info@greymatterdigital.com.au.