In our latest MuleSoft London meetup we discussed MuleSoft’s strategy for API Led Connectivity and it’s application in a real HR scenario – comparing it to other API layering frameworks.
Based on Gartner’s pace layering concept, and advocating breaking down challenges into self-containable building blocks – an API layering approach can provide the technology enabler for supporting a decentralised operational model. For more info on the fundamentals of pace layering check out our insights page from last year.
MuleSoft’s definition of API-led connectivity is:
An approach that defines methods for connecting and exposing your business assets.
Like Garnter’s pace layering approach it promotes assets and services that are scalable across geographic, technical and line of business boundaries.
The idea of the decomposition of business assets into self-contained objects is aligned to microservice archtiecture principles which looks to loosely couple services to enable scalability, reuse and speed of innovation. The API Led connectivity approach looks to apply a framework to these services that enable them to be connected as the business demand requires, building out what MuleSoft refer to as your application network. Overall though the model serves an architectural purpose in supporting a composable microservice enterprise.
In our discussion we challenged some of the over simplifications of the model, and discussed real-life scenarios where it has been applied successfully. Beyond the three layers of system, process and experience that form the API led layering model we proposed an extension of the layering analogy to cover security, caching and API contracts which are critical layers applicable at an API platform level.
Moving away from a traditional point-to-point (spaghetti) integration approach can be a difficult discussion under project pressures, but by starting small by solving a real challenge for the business, you can quickly show the value of APIs by measuring tangible outcomes.