“Traditionally service architecture has been about building closed systems, and any business-related changes have been carried out within those systems. API-led architecture tries to build an operating model that is based on the accessibility of system-internal data and functions from both inside and outside the system through established interfaces,” says Kimmo Lankila, Solution Architect at Bonsky Digital

In support of business-based activities

The more widely we adopt the layered API-based service solution model, the easier it will become to transition from one system to another.
“Before we’ve had to contact the supplier to make any changes to the solutions inside our systems, which has often proven slow, arduous and expensive. In addition, we’ve used various integration tools to connect one system to the next on a case-by-case basis, which has resulted in a highly complex network of systems,” Lankila says.

API-led architecture is based on layering and detaching components from one another. It would actually be more fitting to talk about API-led microservice architecture.
“A microservice architecture aims at creating smaller entities that are easier to develop and manage independently. This leads to being able to separately digitalize various parts of the business,” Lankila says. Jukka Rintaluoma, Program Developer at Vincit, continues; “This conveniently enables the Agile use of new third-party services as well. Cloud services, for example, offer continuously developing features and services that can provide systems with new properties and make development more effective”.

A genuine API-led layered service architecture promotes cost-effectiveness and reusability. It also removes the need for one-off solutions for transferring data in the future.

“We want to help the customer escape the limitations of one all-powerful system. The processes and systems that surround data processing should always adapt to the needs of business, not vice versa,” Rintaluoma says. 

How to distinguish a truly independent API-led service architecture from a seemingly independent one?

If you believe the hype, nearly all platforms seem to represent API-led service architecture at its best. So how can you distinguish a genuine, API-led and independent service architecture from a solution that appears to lead to a vendor lock?
“In theory, platforms such as Salesforce and SAP are API-capable, but at the same time that capability is tightly bound to the platform and its properties. If you want to develop these systems, you need to have in-depth knowledge of the platform and its related tools. Committing to such a platform means that you lose the flexibility to look for and make use of solutions that fit a certain need. Furthermore, you end up in a situation where, once again, the capability of a single system starts to govern the development opportunities of business,” Lankila explains.

An API-led service architecture is designed to tear down system silos and to enable first-rate multichannel user experience through a layered and modular execution.
“This gives business the opportunity to develop capabilities that fit individual needs,” Rintaluoma says. Lankia agrees and adds: “It also allows you to free yourself from the restrictions of single systems and their suppliers.”

Service architecture needs to adapt to business

AThe biggest advantage an API-led service architecture can offer is that it lets the organization to scale in accordance with changing business needs, and makes business data available to all. In practice, the biggest competitive advantage is gained through the development of data management capabilities over the long haul. Information and functionalities are made available so that they can be used for several purposes without any special arrangements.
 “When an internal development team realizes its projects in an API-led way, the capabilities soon become available to other areas of business as well. From there, it’s easy to start offering the same capabilities to partners and customers, too. In other words, the same structures can be used to produce value, both internally and externally,” Lankila explains. 

An API capability can be built using Agile methods – swiftly and efficiently.
“The building of an API capability can start with a single need, say, the need to provide product availability data. If the management of product availability data is API-led, it’s easy to make this capability available to partners and customers via an interface. It’s also possible to open up pathways that companies can use through an interface to provide product data for internal product data enrichment processes. There’s also no reason why this same API couldn’t be used by a third-party web store. In retail, APIs can be used to deliver retailer prices directly into the retailer’s system. If we continue along this path, we’ll soon make the old ways of transferring data between parties obsolete,” Lankila affirms.

API-led architecture also needs maintenance and development. 
“Since APIs deliver data to various internal and possibly external actors, you’re also responsible for their proper functioning. It’s not enough that you set them up – they also need to be maintained and developed. Any interface descriptions need to be kept up-to-date, and planned alterations need to be carried out in such a way that they don’t suddenly require any immediate action from all the parties. You could say that interface development and DevOps culture are like obligations that lead to a better and better customer experience,” Rintaluoma and Lankila point out.

Do systems govern your business?

No matter which service architecture model you employ, the most important thing is that the design of your solutions is based on your business, not on technology or your systems. 
“Businesses often have a lot of great ideas, but sometimes they’re impossible to realize, because the available systems haven’t been designed to support them. IT often gets the blame for standing in the way of progress, but its unwillingness to carry out the plans is understandable. Those who work in IT are the ones responsible for realizing all the ideas, and the needed solutions can make their work unnecessarily complicated,” Lankila says.

Lankila proposes an operating model where the IT would take responsibility for the systems and infrastructure while simultaneously helping the business side to understand the current state of the architecture and the available capabilities. IT and business would also work together to assess how the new solutions could be added to the overall architecture.
– Samalla palveluarkkitehtuurin ylläpitämiseen pitää panostaa. DevOps-“Some investments also need to be made in the maintenance of the service architecture. DevOps culture plays a highly important role here. In development, all the functionalities and installations need to be automated from the get-go and as far as possible, and some thought needs go into fault handling, too,” Rintaluoma emphasizes.

“As the business-led and API culture-based architecture increases the competitiveness of an organization, the business side needs to be increasingly responsible for the development of new solutions. The greatest benefit can be achieved by defining IT’s responsibilities more clearly and by allowing business to understand which impacts the planned solutions will have on a wider scale,” Lankila summarizes. 

How can companies get started with employing an API-led service architecture?

Here’s how you can get started if you want to ensure the competitive edge of your organization and build a proactive business in an ever-changing environment:

  1. Identify the kind of digital service you want to produce. Try to understand the needs of the business. Find out how the data is connected – which capabilities your organization has in terms of integrations, for instance, and to what extent an API-led solution can be realized in your current ecosystem.
  2. Start simple. Think of a situation where a company’s field workers need a mobile application for receiving job assignments. The mobile app communicates with an interface provided by the backend business system. Creating a separate interface (system API) above the business system will bring the organization one step closer to achieving an architecture that’s not system-dependent (see image).
  3. Implement DevOps culture from the start. Automate all functions you can.
  4. Take things further little by little and become increasingly independent from any systems that are working in the background. For example, when you start adding functionalities to the mobile application introduced in stage 2, don’t carry out only the possible changes to the system API layer, but also add a new layer – a process API – which assumes responsibility for business functionalities and data management. 
  5. In the next phase, you can start implementing experience level functionalities on top of the business-based process API layer. The purpose is to combine process-level functionalities and to create a particular user experience around them. This way it’s possible to enable, for instance, push notifications and a “public” interface, which can be aimed at external actors working in the field, for example. Both functionalities can make use of the same capabilities.
  6. Don’t lose sight of the big picture, and keep in mind how you want to develop the architecture. The development needs to be business-based, not system-led. Through iterations and by refining small and manageable entities, you will achieve the capability to adapt to the needs of the business.

Vincit and Bonsky have joined forces to help industrial companies face the future with confidence and gusto. Vincit focuses on the transformation of business and digitalization and seeks to control changes through strategic choices, new business models and thought leaderships. Bonsky Digital develops digital business and architecture with Agile design methods that engage the customers.


Kimmo Lankila, Solution Architect, Bonsky Digital Oy
In the constantly changing world of technology, there’s always something new behind the corner that can be used to refine familiar solution models.

Jukka Rintaluoma, Program Developer, Vincit Oyj
Less code, fewer mistakes

Do you have any questions? 

Tatu Könönen, Bonsky Digital Oy, tel. +358 40 520 8477, tatu.kononen@bonsky.com

Petri Suhonen, Vincit Oyj, tel. + 358 44 758 2313, petri.suhonen@vincit.fi

Author: Minna Haapsaari, Bonsky Digital Oy