API Design and Development: Creating and Executing the Roadmap

Author avatar
Neboneid Hamoo 20 August 2022
API Design and Development: Creating and Executing the Roadmap

Spotlight on our Keynote Session with Marco Palermo, Director, Digital Government and Modernization, Technology Services Division and Johan Macedo, Manager, Enterprise Integration, from the City of Toronto

Ensuring that Backend Technology Matches up to Frontend Expectations

It is common knowledge that technology dominates our lives, and that we interact with computers or the technology within them multiple times a day. Computers power our cars, many appliances within our homes, our mobile devices and so many other unseen devices and operations. They are also used heavily within government services, and not just in a visible way. The backend operations of most government agencies are usually busy hives of banks of computers operating all manner of systems and processes. Many of these computers and systems can communicate with each other because of Application Programming Interfaces, or APIs, and many of these are very sophisticated pieces of software.

So it is at the City of Toronto, and Marco Palermo , the Director of Digital Government and Modernization within the Technology Services Division, says that they are a very complex City, with 45 divisions and 15 agencies, boards and commissions across the City. Those are our clients. There are so many because Toronto is the fourth largest municipality in North America, and is both the fastest growing city and fastest growing region. The population of the city is around three million, but the municipality serves close to five million residents across the region that interact with the City in some way. This means that the infrastructure needs to be appropriate, scalable and stable to deliver critical services, yet there are also legacy systems to contend with, and this is where APIs come in. In terms of the technology architecture at the City, there is a new focus.

In fact, someone recently contacted the City through their smart fridge, and this kind of communication, from multiple devices located in a variety of places is likely to continue. So there needs to be channel access, digital platform integration and third party systems that serve specific purposes. Moreover, all of these – through APIs – need to talk to each other to get data from the public to the right backend system and then back to the public in a meaningful way.

Like most municipalities, the core purpose of the City of Toronto is to improve the lives of our residents, businesses and visitors by providing simple, reliable and connected services that anticipate changing customer needs. This means being able to provide services in an equitable way, and in simple terms, that means however someone contacts the City, be it online, by phone or in-person or even through a smart fridge, that frontend experience needs to be routed into the right backend system for the appropriate action. The interaction needs to go through the proper API layers that have the data and the appropriate levels of security and privacy. In essence, it means that the technology architecture needs to have service capabilities with a reusable approach, business processes and standards, and technology standards to enable rapid implementation to ensure scalability, sustainability and stability.

Enabling the APIs to Work in the Best Possible Format

To ensure all this, the City of Toronto embarked on an API journey over a decade ago, but Johan Macedo , the Manager of Enterprise Integration at the City, says that despite this, we are constantly on a journey to mature our practices. The focus, which the City adopted as a working principle around digital enablement, is the concept of digital autonomy. Ultimately this means integrating systems.

To achieve this, they use a canonical model pattern, which allows different data formats to communicate with each other for better data exchange across a diverse system.  This is a very common enterprise integration pattern, with neutrality in the API interfaces and is pretty much best practice. It also survives technology replacement, supplier replacement and upgrades.

One of the reasons why they adopted this model was because previously, there were so many ships that wanted to sail at the same time, but the technology landscape was frozen. In other words, they had many concurrent projects but didn’t have the technology for all of them to run simultaneously. Each time they had to pause all other projects to get one completed, which caused great chaos and commotion, not just in the backend, but sometimes for staff and customers too. This new canonical model has allowed us to step in between multiple moving programs or transformations to stabilize them so that for instance, two programs at once could utilize the same data and move towards a more efficient target state. Moreover, it has allowed the 45 lines of disparate business demands to have consistency and to work towards some standardization.

The City also uses REST (representational state transfer) APIs, which are architectural constraints that allow the data to move around. This data can be delivered in several formats, and the City uses JSON (Javascript Object Notation), which is the most common because it is language-agnostic. This very much fits in with the canonical model and gives us great flexibility as well as the ability to use as little business logic as possible so that things can be directed to where they need to go without interference. But at the same time, like with all technology, security is still a concern, so that is built into the APIs too.

The Different Uses of APIs in the City

With the appropriate technical elements in place, there are APIs used in mobile apps and internal systems, as well as to allow systems to communicate with each other. But for the most part, the City uses three types of APIs:

  • Enterprise APIs – These are the most common ones and they have been around the longest to support various unique business models. We use them for various capabilities, like validating income, processing credit card payments, storing data or even accepting an upload to City computer.
  • Micro-services – These are APIs that are set up for a specific purpose. Often they are set up to deal with legacy systems or to enable something specific at the backend. During the last few years we stood up numerous of them as we worked through the pandemic. It is not uncommon to use enterprise APIs and microservices in tandem.
  • Digital platforms – These are APIs that work with commercial platforms like Salesforce and Ariba. We often use these cloud software platforms and leverage them for our own needs.

Almost all of these APIs are open source based, so we more or less just wrap our services around them to get what we need from them. Marco Palermo finishes by saying that engaging with APIs in this complex way has allowed the City to drastically increase the speed at which we’re able to do things, and to release the digital solutions that our customers expect. In our modern world, this has undoubtedly given the City of Toronto a real advantage of uniquely creating a set of APIs that fit our needs and can be scaled for the betterment of our City.

Presented by:

  • Marco Palermo, Director, Digital Government and Modernization, Technology Services Division, City of Toronto
  • Johan Macedo, Manager, Enterprise Integration, City of Toronto

Want more insights like these? Check out our upcoming IT and Innovation Events here!

Communities
Region
Canada Canada

Published by

Author avatar
Neboneid Hamoo Data Management & Analytics / Corporate & Shared Services Partnership Director, Public Sector Network