When dealing with customers, partners and suppliers, organisations want a complete picture of their interactions. Many organisations take a CRM system as their 1st point of Interaction. To get the ideal single view, the CRM system may need to interact with many backend databases and systems of record.
The problem that is encountered is that to make a change in one of the databases or systems of record, requires a change in many of the other systems. What seemed like a simple integration between 3 or 4 systems can quickly become a change nightmare, trying to track multiple changes in differing repositories. Add to that a customer may be described in one way on one system, another way on a second system and a completely different way on a third, then you start to get an idea of some of the problems of trying to provide a “single view of your customer”. For an agile organisation, wishing to bring new products to market and sell them, then IT becomes a major bottleneck to working with your clients and suppliers. Once IT were seen as the saviours of organisations, now they are seen as the drag on organisations.
In response, we have seen the emergence of Multi-Tiered Application Architectures and Microservices.
Gartner identified that the traditional model of IT which is largely concerned about availability and accuracy does not provide the organisation with the speed and agility to meet the business requirements. There is a two speed dynamic going on, one where speed is of the essence, the other where security and governance is the prime concern. They are diametrically apposed, something Gartner termed Bimodal IT.
A Bimodal approach recognises that an organisations capacity to quickly respond to and drive business goals may require different people, processes, technologies and budgets. This requirement leads to organisations handling smaller units of change. Changes that can be handled by smaller teams, who can see quickly if a solutions is going to work or not and change course quickly, if required. It also leads to an approach that says, bring your own technology, we are set up to handle your preferred solution. However, you might want to search our repository of solutions, to see whether it has been done before, prior to committing resources to inventing a new solution.
An effective solution to this issue comes in the form of an application architecture that uses multiple tiers, in which presentation, application processing, and data management functions are physically separated, thus making it easier to handle different speed-of-change modes.
In the diagram below, the value range in each tier is a typical frequency of change in weeks (see MuleSoft’s paper on API-led Connectivity [1])
By implementing an architecture of loosely coupled services, organisations are able to adopt a Bimodal IT approach.
Bimodal IT is supported through loosely-coupled services that are accessed using APIs, which inter-operate within a tier and across tiers.
An API encapsulates a component or service behind a façade, which defines a contract to provide a well-defined response to a given set of input values. The loosely-coupled nature of APIs is often described as being out of process, meaning that the invoking process has no knowledge as to where the invoked API resides.
The above diagram has added a number of API/Service icons to illustrate this.
The Aggregation and Services tiers are shown as invoking APIs within the same tier and between tiers. For example, one API in the Aggregation tier could be orchestrating the invocation of other APIs in the same tier, and possibly, others in the Services tier.
In the Delivery tier, each API is shown as being one-to-one with a single type of Client. This is to illustrate the fact that each kind of client will have different capabilities and volumes of data per API call.
The term “Microservice Architecture” has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organisation around business capability, automated deployment, intelligence in the endpoints, and decentralised control of languages and data.
A concise description that can be found in (Seven Microservices Anti-patterns [2]), provides a very interesting description using hindsight to describe mistakes made during its author’s time on early Microservices projects. It reminds us that the following points have always been the most common business reasons for any architecture – use of Microservices being no exception:
• Improved Agility: the ability to respond to the business needs in a timely fashion so that the business can grow
• Improved Customer Experience: improve the customer experience so that customer churn is reduced
• Decreased Cost: reduce the cost to add more products, customers or business solutions
1) https://www.mulesoft.com/lp/whitepaper/api/api-led-connectivity
2) https://www.infoq.com/articles/seven-uservices-antipatterns
3) For a full paper see: http://w3partnership.com/Blog/2016/09/09/apis-multi-tiered-application-architecture-and-microservices-an-investigation/
(If you found this article of interest and would like more information on our approach to digital integration then you may like to take a look at http://w3partnership.com/IntegArchReview.html)
