In any sizable organization, it’s hard to feel like you can make a difference with just your tech skills. There’s no surprise that software engineer Flavia Sequeira felt exactly that when she joined ING — the multinational banking firm with over 50,000 employees — in 2013.

See, building an impactful IT product can take a lot of time and effort, and it’s hard for management to get excited about that when it doesn’t offer an immediate value proposition. Who needs an API when we can be fixing server downtime, or getting the user interface all dressed up for next month’s holiday?

That was the case with APIs when Flavia joined ING. The business folks were aware they wanted a more open approach to technology, one that could potentially change the face of 21st century banking, but it wasn’t obvious where to start.

Quite surprisingly, building an API wasn’t an obvious solution to that, all the less so when the IT team had already built a web service.

It’s been Flavia’s journey over the last four years to educate her coworkers on the benefits of an API thinking, as opposed to just an API doing, mentality, and it all starts with a case of semantics.

APIs versus Web Services: What’s the Difference?

Flavia tells of an early API community session at ING, where an overwhelming negativity towards APIs filled the room. The experienced developers simply couldn’t see what APIs had to offer that their web service didn’t.

The common consensus is that web services offer a more limited range of functionality than APIs, delivering particular data in a standardized format. This is opposed to offering a comprehensive development suite for building onto an existing IT product. Flavia had (and still has) her own take on the matter:

“APIs are built ”outside-in”, she announced in the meeting, followed by a long silence.

When asked to expand on what she meant, Flavia explained that APIs are to be built from the customer’s perspective, to the customer’s needs, while web services are built from the organization’s perspective, offering what they perceive as important.

This means that, whereas web services might offer just a single service or set of services for customers to make use of, public-facing APIs allow for much more interactivity with your product, such as tracking customer journeys.

API Doing vs API Thinking

The above anecdote makes it clear that Flavia joined ING with a completely different mentality towards APIs. She wasn’t as much interested in API doing as she was API thinking, and that was an entirely novel approach.

She didn’t ask herself:

•  What data and functionality do we think is useful for users?
• How can we provide them with that data and functionality? (In other words, how we do we build this API?)

Instead, she asked herself:

• How do our users want to engage with our services and what do they want to build?
• How can we make it as easy as possible for them to do so?
• How will that better help us understand and serve the needs of our customers?

Of course, that first set of questions — the API doing questions — are just as important as the second set of questions. In fact, they’re the more practical questions for a developer to be to asking.

However, it’s the second set of questions — the API thinking questions — that really justify an organization to be building an API. What’s more, they solve that initial dilemma of convincing management what APIs have to offer.

APIs and Customer Journeys

Flavia’s anecdote continues, in parallel with what we’ve just said above. She recalls how a senior employee then asked her to expand on her thoughts on customer journeys, presumably wondering why a software engineer would be tracking a customer’s experience with ING from start to finish.

The truth is that well-designed IT products are tightly linked to an awareness of customer behaviors, requirements, and desires. Not only does the latter help to build products that the user will love, but products that the user loves will themselves help to flesh out customer behaviors, requirements, and desires. This occurs by encouraging open thinking in developmental stages and providing empirical data in operational stages.

This is why customer journeys from the business department at ING help to build better APIs, and why better APIs help the business department to create fuller, more effective customer journeys.

APIs share that same symbiotic relationship with other business tools, like service blueprints, and business practices, like design thinking. These pave the way for a more functional, complete API, while the API helps to visualize and facilitate new opportunity.

What’s more, APIs can be a solution to decoupling front and back ends — allowing the end product to link up closely with its inner workings, without making the two entirely reliant on each other.

This is API thinking. It’s understanding what APIs can do for the organization, from a holistic perspective, and not just meaninglessly building APIs because they are trendy.

Why API Doing is Equally Important

When you’re tracking this kind of high-end thinking, it’s easy to forget about the true value that APIs can provide in modern-day banking — and that’s very much in the doing.

See, unlike the business tools mentioned above, APIs offer just as much to the user as they do to the bank itself. API usage in banking, which is part of a greater movement called open banking, allows FinTech services to draw from the huge information base and varied functionality that banks already have.

Think about it — there are thousands (if not millions) of third and first-party apps built into our mobile phones, social media platforms, and even houses. Yet there’s hardly an equivalent for today’s banking services.

Imagine having an app store for your bank account. You could choose from thousands of services, built with the collective thinking power of third-party developers — big and small — that would solve a multitude of problems and change banking for good.

The possibilities for this are endless: collect all your accounts in one place, send cash over social media, manage your spending patterns, verify past transactions, and so on and so forth.

With the way things are today, it’s not that it can’t be done, but more that it’s impractical. Of course, any financial services — banks included — need to be well-secured, with information locked away in internal systems. This is why the existing (and highly limited) model of giving FinTech services direct access to your account (known as screen scraping) simply can’t go on. The finance management service Mint performs screen scraping regularly — gaining direct access to your bank accounts — but it feels safe enough knowing their parent company, Intuit, already holds millions of social security numbers.

However, requiring user login information is a significant barrier-to-entry for smaller FinTech developers. These applications may only need a limited scope of data to operate, such as your spending dates, or locations your credit card has been used at.

APIs are an obvious solution to this, allowing third-party services to interact with banks, drawing only the necessary information and performing only the necessary services. With standardized authentication and delegation protocols widely established for APIs, not only would it be more secure — it would be more effective.

Changes in regulation, like with PSD2 in the European Union, are already pushing for and preparing for this change. Ultimately, though, it’s up to banks to open themselves up to the world in a way that is usable.

From API Doing to API Thinking

When Flavia joined ING, they weren’t just lacking in API execution, or “API doing”, but they were also lacking in API understanding, or “API thinking.” This was making it hard to execute a definite platform strategy.

She’s solved this by encouraging others to look at APIs holistically — to understand what they bring to an organization and its clients or partners, and to employ that same information to then build better IT products.

Along Flavia’s journey, her career description has changed from “software engineer” to “API thinker”. She doesn’t just build IT products at ING; instead, she educates fellow developers on how those products, especially APIs, can be designed true to both ING’s values and its customers’ experiences, and how that in turn will allow them to create a better overall customer experience.

Ultimately, APIs aren’t made from doing or thinking alone — it should be a mix of the two. Despite Flavia being an API thinker, there has to be a number of API doers at ING, too.