I often felt a step behind my team at the start of new projects implementing system integration. Such projects are very technical and could be overwhelming for a Project Manager like me. I was drowning in tech details and scary-sounding abbreviations.
I didn't give up! I kept learning and reading and gradually gained confidence and experience to tackle integration projects successfully. Now I understand technology and solutions well, and more importantly, I appreciate the value we deliver to our customers. In this blog, I will explain how integration solutions can affect project management, risks, adaptability to future growth, and the real value they deliver.
Integrating systems
Let's start with basic concepts. Systems like people cannot exist in isolation; they need to exchange information. There are multiple ways and techniques to connect applications and devices. However, the two most common approaches are direct (or point-to-point) connection and API-based integration.
When implementing a new integration solution using the traditional IT operating model, the main focus is encapsulating all system integration requirements. Basically, we have a clear project scope, and we have to deliver it. The API-led connectivity approach's goals are more extensive and go beyond the needs of the current piece of work or even one department. At the end of a project, the customer gets the requested solution. Moreover, everyone in the organisation gains reusable APIs to accelerate and improve the quality of future project delivery.
API-led connectivity
APIs are the core building blocks of the API-led connectivity approach. The API you build today could later be consumed by other developers within your organisation or even external suppliers and partners. Therefore, every API must satisfy the following requirements:
- be discoverable and accessible,
- be produced and designed for easy consumption,
- be manageable for security scalability and performance.
The API-led connectivity approach groups APIs into layers by their purpose:
- System APIs offer access to core systems or data sources. These APIs provide an insulation layer between users and the complexity of the underlying systems. Once built, anyone can reuse these APIs to access required information without learning these platforms.
- Process APIs process data retrieved by Systems APIs from multiple systems. They are independent of the data sources and don't know the target channels through which that data is served.
- Experience APIs are used to reconfigure and format data consumed by its intended audience. An Experience API is usually created with API-first design principles. The API is designed with the specific user experience in mind.
What take to replace parking wardens' handheld devices?
Let's now look at how the API-led connectivity approach works in practice. Our Borough Council ABC offers residents self-services to apply and pay for parking permits online. Parking wardens receive handheld devices to verify the parking permits and issue tickets.
The deceptively simple parking services require the participation of multiple systems:
- An online portal where all the residents buy the permits.
- A Customer Relationship Management platform (CRM) that contains information about residents.
- An Enterprise resource planning (ERP) system where vehicles and parking permits are recorded against the customers.
- Portable devices used by the parking warden to verify the parking permits.
Imagine that our council has decided to upgrade or replace the existing parking devices. The infrastructure department sets up an internal project, identifying its scope, time, costs and risks. They immediately identify and carefully evaluate two significant risks:
- Out-of-date - technology is evolving so fast that even the new device could soon become outdated, inefficient or hard to maintain.
- Increased complexity over time - if the council decides to add more options to the parking services, the solution might become very complex and unmanageable.
In the traditional IT operating approach, the development team will receive the task of implementing a point-to-point (P2P) integration between all participants. Our four devices should exchange information through direct communication, as shown in the image below:
Direct connections between systems.
Although the P2P solution satisfies the main requirements, any future enhancements or expansions could significantly increase its complexity. Over time, the straightforward point-to-point integration might become a bulky and unmanageable mess of connections. As a result, the costs and risks associated with every change to this type of architecture are very high.
The architecture of the project based on the API-led connectivity approach will look very different:
API-based system integration.
The direct connections are replaced by six reusable, easy to consume and manage APIs:
- Two System APIs unlock data and make data sources accessible.
- Process APIs, managed by the line of business, process the retrieved information and apply business rules if required. In particular:
- Customer 360 Process API is responsible for extracting resident data from the CRM.
- Parking Permits process API manages the resident vehicle and parking permits and makes them available for further consumption.
- Experience APIs format the data for consumption by the supported device.
The new approach dramatically reduces previously identified risks:
- By eliminating the direct connections between the systems, we achieved high flexibility to replace any existing tool without affecting the rest of the architecture.
- Changes to the original solution will not require redesign or lead to greater complexity. Create a new API to support new requirements and features, as simple as that.
In a nutshell, the API-based integration approach breaks down the point-to-point connections flows into layers. Thus, future changes or upgrades will only affect specific APIs. This architecture gives our ABC Council agility for future development and growth.
What future holds
More importantly, any future changes to the architecture or its parts will unlikely impact the rest of the flow. Let's think of a few potential scenarios:
- Suppose Central IT needs to upgrade or replace the existing ERP system. In that case, they can independently update the related System APIs.
- What if the council decides to extend the parking service? Residents will be notified when their parking orders are received. In this case, the changes will be encapsulated in the Parking Permits Process API only.
- Finally, if advanced parking warden devices become available, the IT team has to develop a new Experience API.
The image below shows the updated API-led architecture of the future:
The benefit of the API-led integration approach is that the initial solution's growth or future enhancements won't affect its complexity. As a result, the risks and costs associated with changes are greatly reduced. The created API network is the foundation for continuous improvements based on new requirements and the organisation's growth.
If you find this page interesting and want to know more, recently, we compared the value generated by point-to-point integration and API-led connectivity.
