April, 2018 | digitalML
The Adaptable Canonical Model Reading Time: 5 minutes

This post is for anyone who designs, models, produces, or consumes services (APIs, events, messages, etc.) at a large enterprise.

A Canonical Data Model and canonical schema is designed to define business entities in a standard manner, including the structure, attributes and data format. As a result, the models tend to be very large and often complex”-Canonical Data Models & Microservices, Deloitte Digital

 

Today we’re going to talk about the oasis that occurs somewhere between two extremes; the first being Canonical Canyon. This is a place where developers and engineers get so bogged down by rigid canonical models that there’s hardly room for iteration (much less, innovation); the second — the Wild, Wild West; where there are no rules, code runs wild, and duplication is out of control.

If you’ll humor us as we run with the extended metaphor, we’ll explore the two polaric states of information models before touching on that most-wanted middleground — where domain-driven design can be applied to canonical for the global enterprise, for any user, from software engineer to citizen developer.

 

The Wild, Wild, West: No Canonical, Ignored Canonical, or Too Many Canonicals

Adaptable Canonical Model
Let’s start with “The Wild, Wild, West”. This is the state you could declare in an IT department with little or no standard naming conventions, and if there are guidelines, they’re often ignored or locked away in silos far from their users.

Even organizations that keep a tight ship can lack development standards across business domains, but the smallest changes made can turn into an enormous bramble of unchecked code as the years go by.

This operational state is increasingly less favorable for security reasons, yet it is often simply the product of mergers and acquisitions, changes in technology/methodology, and too many departmental walls blocking the view. In the Wild West state, everyone gets tied up trying to meet deadlines, and those who do get assigned to monitor don’t even have the data lineage to even begin tackling the issue.

The side effects of this behavior, which can go on for decades, range in structure. They can look like one large mass of code so huge the application is slow and data is hard for users to access, or on the other hand, it could take the shape of 12 models, all doing the exact same thing — sometimes you end up with duplicate APIs and services that don’t even look like duplicates, since they’re not using consistent models.

It’s easy to see how the state becomes a big mess, with people working in silos and using whatever they have access to, without any governance in place. At a smaller company, this wouldn’t be such an issue. But for the global companies who have different teams building in different languages, it’s a nightmare.

So, how can you ensure the right models are being used for API development or consumption if everyone has access to all of these different flavors or versions of the models? Keep reading; we’ll get there.

 

Canonical Canyon: One Canonical, Low Flexibility

Canonical CanyonIn this state, there is a source of truth. But it’s more brick than elastic, if you know what we mean. This is the state where a company’s canonical model is so rigid and lacking of flexibility that internal developer consumers can barely use it — not to mention the difficulties of onboarding an external consumer.

The problem with a rigid canonical model is it has no granularity, no user-friendliness, and gets as much use as a pretty postcard. It’s nice… to look at.

Canonical Canyon

Thanks to the SOA days, many companies have beautiful canonical models, built upon company-wide efforts to document a service-oriented architecture that failed them in scale. Those models are often collecting dust in storage. But those are some of our most organized customers.

Let’s face it, developing a service takes enough understanding in its own right. When your guide to building that service, your canonical model, is so big that you need a data modeler to explain it to you — end even then, if you’re needing to know the language of a data modeler in order to even read the model, something isn’t working.

If there’s no way to discover and find the models you’re looking for yourself, you’re going to hit a bottleneck where you’ll have to go back to a data modeler to find everything. And guess what? They’re booked up, because everyone in your organization is in the same canonical canyon. Hope you brought picnic supplies.

It’s time for organizations to think, if we are going to adopt a canonical model for scale (and we should), how do we make it easy for everyone to understand?

 

The Oasis: Adaptable Canonical Model

Adaptable Canonical Model OasisThe goal is to have flexibility — you want to make sure the model isn’t constraining you. But not too much — there has to be a middlegroud! It needs to be able to reflect what you’re doing in the real world.

What we’ve built into our platform keeps the largest organizations in that middleground. ignite helps you put the governance around and make decisions around how model(s) should be created, or decoupled, depending on what shape they’re in and what the future use is, whether you’re trying to build events, messages, services, etc.

But more importantly, we work with you to make use of what you have (SOA, etc.). We bring everything in, data, services, mappings, to analyze and make those decisions based on your set up. From there, we decouple the monolithic — so your services are getting federated and your model is getting simpler and simpler; and easier to use; self-serviceable. The better for when you’re rolling those models out to the enterprise.

In this state, governance doesn’t cause bottlenecks, it removes them. When developers and API producers take OpenAPI and hack it, they’re the only people who know about their changes. Yet when you have visibility on what’s happening within the underlying model; you know how you got from the model to where you are, you have lineage. You understand the impact analysis of every iteration. That’s what ignite offers, a way to first learn what you have so you always know exactly where to start and how to build.

 

Read Part 2: Applying DDD to Canonical Models for a deeper dive on how customers use ignite to achieve a Canonical oasis between the extreme states we covered today.

Developing with Business Capability APIs: Pros & Cons Reading Time: 5 minutes

Today we discuss the pros and cons of developing with business capability APIs, or internal APIs, with IT expert Andy Medlicott. 

Pro: No More Drowning in Details

Perhaps the most significant pro is the ability to get ahead of the details. Developers know the detail is too much. Details are where bugs creep in. Take what we saw in the electronics industry about 65 years ago; you found it was possible to build so many things with transistors, putting them and other electronic components together on boards, and everything worked fine… but it didn’t scale. Then came integrated circuits (IC) which conveniently packaged common designs into a single units. Rather than having to know how everything worked in detail, you played with these components instead… and things were built quicker, were more reliable and were cheaper!

Unsurprisingly electronics and software are similar… software boils down to machine instructions and opcodes – over the years we introduced assemblers, operating systems, compilers for higher-level languages and shared libraries and modules, all in the aim of reducing the detail a developer needs to know to make something work!

Same with the shift toward microservices and containers — people appreciate having the ability to build more complex systems. Before, you might have had a library you’d build and compile, but now you have a container, so your system as a whole has many more components, yet it’s actually simpler to understand. To some extent, it’s the same with microservices — developers have more flexibility and room to build higher-quality APIs from these canonical building blocks.

 

Pro: Simplifying Unnecessary Complexities for Speed

Software engineers use components to develop software to put things in packages so you can reuse them; by not getting bogged down with all of the detail you’re moving faster. The same thing applies with business capability APIs. Life is a lot easier when your capability APIs already align to the business, they’re already encapsulated so you don’t have to become an expert in every area in order to fit into the overall plan.

Take an example Delivery API — its job is to say, “This is the address where X needs to go to. This is the content of the order that’s being made.” The API will return all of the details. Whether it’s a case of next day delivery, or etc… as a developer all you have to do is call the API, see the result, make a choice .. So you’ve immediately offloaded the need to understand the subtleties. You don’t need to know about the complexities of a delivery schedule in Hawaii (which can get pretty complicated, when you’re adding islands and air travel into the mix).

It’s much better to build from well-maintained capability APIs. Laws change in every state! Not only are people using your APIs now, but when the rules do change, you can change the version and update it in all of the systems downstream. This delivery bit is especially important to retail.

 

Con: More Generation = Loss of Control.

Not having the ability to tweak around takes some getting used to. But in truth, with this new lifecycle, tweaking is rarely necessary. If you lose the ability to tweak, what do you gain? In actual fact, you’re going to get far more accurate results. Which will be great, professionally. Because the quality of your designs are so much better.

 

 Con: But it’s Not as Efficient! 

True. But what is the price of efficiency? What is the real cost? If you’ve ever used an IC then you’ll know it’s rare to use all the pins or features of an IC – yet you still use it. Why? Because it’s far more expensive to make it custom. You might be able to use a lower-spec IC to get it a little more efficient – but efficiency can become an ideology or rather than engineering an appropriate solution.

 


Pro: Lighter Load for DevOps

Because API developers are more likely to produce better APIs, it makes the DevOps role a lot easier. The capacity for human error is significantly reduced, because so much is automated — the correct security is baked in, the right access is assigned, even the mappings can be automated, so you’re always calling from the exact right domains.

Many companies don’t give their Business Capability APIs the attention they deserve. But for those who do, they’re seeing the benefits of having that immediate access to versioning and lineage.

 

Pro: Greater Alignment

Business Capability APIs are also helpful in that they are designed to always support the business goals; and in a great API design, that definition should always be included within the API metadata so it’s always clear what the API is achieving.

For example, sometimes the business reasons are different from the tactical — Say you know you want to get to x and you decide your own route. The tactical reasoning might tell you to turn left and turn right for the quickest route. But you might lose sight of the business reasoning — if that route is taken by a travel company, who wants to take a scenic route for customers to see the greatest sights. Or for a company like UPS, who wants their drivers to only take right turns to save money.

By enabling people to concentrate on a business goal, you’re more likely to get it right. This pattern is just where software engineering is going. It’s only recently that that’s become viable. That’s a change ignite’s supporting. It’s not so much about the APIs — they’re just a means to an end. The API itself is not the end goal. It’s the advantage of always taking a business focus, rather than taking the very technical implementation.

 

Con: Yet Another Change

Adapting to change is never fun. We get that. But, with the industry changing as quickly as it is, how can we not change as well? These days the SDLC looks different every year… it seems every few months a new enterprise architecture pattern is recommended, and these paradigms are changing quicker than the organizations are able to onboard them. The good news is, if you’re coding from design, you can adapt quickly to the next coding language, or new technology — you’re still able always use what you’ve done before.

 




Pro: You’re Faster and Better at Your Job, With Better Lineage to Report it

The design-driven development lifecycle might be a change to the way you do things as a developer — though it’s the way it you always felt you should write software, it was just always too time-consuming! The fact is, you can now do your job much more effectively and more complete. You can focus on delivering a really great experience rather getting bogged down in the details. And if you’re really set up right, you’ll have the lineage to report it.

Because APIs support so many digital touchpoints, you’ll be able to track direct value from the things you’ve built. Our ignite platform also tracks the amount of time it takes to get from proposed idea to runtime, integrating with Jira to report back the sprints, so developers are equipped with accurate estimates of how long it will take to build a new API or experience.

Want to know more? Have something to share? We’re always glad to start a conversation. Let’s talk.

5 Top Banks Open Up Re: API Channels Reading Time: 6 minutes

Earlier this week, we published an article called “What is an API Channel?”. This is a follow-up with a view on the banking industry.

Leading API Channels in Banking

Over the last five years, many of the largest banks in the world have been silently building out API channels. Whether spurred by regulation like the EU’s Open Banking Standard (PSD2), an audit-ready state of operational efficiency, or simply answering to the pressure of competition, the evidence says that the runners are in place and the heat is on.

Today we’ve gathered a few quotes and movements from those key players to zoom in on the banking API channel. With it, these digital leaders are making impressive waves — and likely have many more to come.

 

JPMorgan Chase

$105,486 revenue in millions, 2017 (Fortune.com)

Just launching their API store over the last 6 months, JPMorgan has joined its competitors aboard the open API gateway train. The 2-part store consists of JPMorgan Developer, for the investment arm, and for the retail banking arm, Chase Developer. (Business Insider)

James Dimon, CEO of J.P. Morgan Chase announced the API store just recently in his annual Letter to Shareholders, but the part that caught our interest is when the letter mentions that each business and merchant has “its own software” and “wants easy, integrated access to products and services” — sounds like APIs, to us.

Our shared technology infrastructure – our networks, data centers, and the public and private cloud – decreases costs, enhances efficiency and makes all our businesses more productive. In addition, this allows us to embrace the fact that every business and merchant has its own software and also wants easy, integrated access to our products and services. We are delivering on that through the creation of a common JPMorgan Chase API (application programming interface) store that allows customers to add simple, secure payments to their software.Jamie Dimon, CEO JPMorgan

Source: JPMorgan Chase 2017 Annual Shareholder’s Letter

APIs give us an opportunity to break down our large programs into reusable components… That also allows us to think differently about how we want to connect with our customers… If you think about J.P. Morgan Markets, that’s a great asset we have. If a company wants to connect with us, it requires technology resources on our side and technology resources on their side to make it work. If they want to get information from us and be able to integrate that into their workflows, it’s difficult. That’s why an API strategy for us is important to simplify the way we interact with our clients.Lori Beer, Chief Information Officer for JPMorgan Chase

Source: Business Insider

 

Wells Fargo

$94,176 revenue in millions, 2017 (Fortune.com)

A longtime leader in banking innovation, Wells Fargo is the world’s 2nd largest bank, according to market capital. In 2014 they launched their first FinTech Innovation Lab, and soon after came their customer-centric focused Innovation Group. In 2016 we saw the launch of their open developer gateway, where they currently offer 13 public API Products, 6 for payments and 7 under the data services category.

Last year Wells Fargo announced data-sharing deals with financial aggregator Finicity, accounting software provider Xero, and Intuit. Supporting this set of diverse and varied external digital accomplishments is the API channel.

I am seeing a drive to accommodate traditional banking services in new ways through API channels. One example is our push to card API, which allows a company to send a payment using the debit card rails to their consumer’s account in near real time. For example, an insurance company can pay out a claim directly to their customer’s debit card, which happens very quickly, and in doing so, score high on customer experience.Secil Watson, head of Digital Solutions for Business at Wells Fargo

Source: Wells Fargo

“We view new technology like APIs as the next step in distribution… It’s really about getting financial services products into any digital experience so you no longer have to come to a bank site to leverage a particular functionality or complete a particular transaction.”Imran Haider, the head of Wells Fargo’s API Gateway Channel

Source: “Banking’s Open Future”, PYMNTS.com

From the same interview, another note on channels supported by the API channel: “(Haider) noted that the company is currently offering an API channel built to support many different services offered by Wells Fargo, including retail banking, wholesale businesses, home mortgages and treasury management.” PYMNTS.com

 

Bank of America

$93,662 revenue in millions, 2017 (Fortune.com)

Bank of America boasts one of the best mobile experiences in retail banking, and their digital strategy is showing huge returns in customer engagement, with 89% growth since 2016. In the short 5-year period when the number of banking deposits made onsite were cut in half, Bank of America’s mobile users went from 6 million to 22 million (Financial Brand), and already they’re up to 23 million this year.

Last year, their innovative strategy included “digitized branches” with contactless ATMs, an enhanced, customizable mobile dashboard, and a partnership with Better Money Habits to offer a Goal-Setting Tool, and early this year they launched their API gateway (American Banker).

But the API channel runs far deeper than the digital achievements we can observe externally. Led by CTO (Now CIO) David Reilly in 2014, Bank of America went all in on the move to the “software-defined infrastructure” they sit on today, where “compute, storage (and eventually network) resources are provisioned via APIs.”

 

The goal is to one day have a system built entirely on commodity servers that are uber-flexible: They could act as compute servers one day, a network switch another and be part of a pool of storage resources if needed. Containerized, micro services-designed applications automatically provision infrastructure resources they need without requiring any human hands in the process.David Reilly, CIO Bank of America

Source: Network World

“We want to embrace the innovation opportunities presented by APIs and work with industry providers to give our clients an expanded, secure experience that helps them grow and prosper… As the pace of technological change accelerates, expectations accelerate in tandem. Clearing systems, regulatory mandates and banking channels are evolving to support real-time interactions with unbundled banking services. Our clients will expect to integrate these directly into their business processes and applications. The experience will be easy, more secure and seamless to end users.”Faiz Ahmad, head of Global Transaction Services (GTS) at BofA Merrill

Source: Bank of America Newsroom

 

Citigroup

$82,386 revenue in millions, 2017 (Fortune.com)

Citi, a digitalML customer, opened an API Portal for their developers in 2016, and has already produced some exciting results (see Citi Mobile Challenge). Beyond that, they have an entire branch called Citi Fintech that is using APIs externally and internally. Since Citi FinTech’s launch, their APIs have led to partnerships with 1800Flowers, Best Buy, honestbee, Lazada, Mastercard, Qantas, Virgin Money, Wonder, and more.

A few years ago, under pressure to match the customer-centric offerings of nontraditional banks and FinTech players, Citi began “restructuring its operating model and empowering developer ecosystems to innovate as quickly as a startup, while maintaining its core business.” (Tech Crunch)

Let’s take a look at what Citi has said about how they’re using their API Channel, both internally and externally:

“There’s a lot of pressure from clients on banks to quickly adapt to the demand for improved digital experiences or be at risk of becoming irrelevant. Our CitiConnect API solution provides a strong foundation for our clients looking to embrace e-commerce initiatives… Across every industry, APIs are proving to have significant business impact. At Citi we believe it can help our clients quickly build modern, cross-functional banking applications.”Derek Rego, Global Head of Electronic Banking Channels, Citi TTS Technology

Source: BusinessWire

“[The Developer Hub] actually covers 85 percent of the core services a customer performs. We wanted to expose many of our APIs to a much larger community, to be exposed to the services they’re working on and give them the opportunity to come to Citi to uncover and unveil where those hidden gems are, those additional opportunities. Instead of just focusing on ideas that target all things Citi and talking to our customers, we now have a whole new partner base of developers and tech organizations looking to integrate with us and can now use our APIs.”Yolande Piazza, CEO Citi FinTech

Source: Tearsheet

“At Citi, we are focused on making banking easier for our customers by leveraging digitization, mobile technology and innovation. Our open architecture approach is supported by the launch of APIs as a key enabler for the rapid and dynamic deployment of services and capabilities that will allow us to be increasingly relevant to our customers and target markets across Asia-Pacific.”Francisco Aristeguieta, CEO of Citi Asia-Pacific

Source: Citigroup

 

Goldman Sachs

$37,712 revenue in millions, 2017 (Fortune.com)

On the investment banking side, Goldman Sachs seems to place enormous value in their API channel, as they have often mentioned their aim to be the Google of Wall Street. Their digital transformation has been in the works for years, according to an excellent interview with McKinsey detailing Goldman Sachs’ journey to the cloud.

This past year, an MBA class taught at Harvard even used Goldman Sachs as a case study example of the gains and challenges of an incumbent company moving to become a tech platform, citing SIMON, the structured notes platform. Their cloud-based API strategy seems to be paying off well for them.

Their API Channel might be the most mature of them all:

“Historically, the API has been human beings talking to other human beings over the telephone, and all the tools, the content, the analytics is on the internal platform only. We are shifting this radically and shifting this fast, and we’re packaging everything we do… we’re redesigning the whole company, around APIs.”Martin Chavez, Executive VP and Chief Financial Officer of The Goldman Sachs Group, Inc.

Source: Business Insider

“We’re now taking that a step forward to think about data: How do we build a very large, scalable way of managing business intelligence? That’s a big initiative for us. Our cloud architecture enables our developers to think about data as an asset to be shared separately from the applications themselves—with appropriate controls, how can the firm’s data be integrated and stored in places where it can be accessed by more people? Being able to bring different types of data sets together, forming new data sets, and being able to learn from that information—that creates business intelligence for us. I don’t think we could’ve delivered or built a large data leg if we did not have the underlying cloud capabilities we have today.”Don Duet, Global Head of the Technology Division at Goldman Sachs

Source: McKinsey

 

Are you looking to build out your API Channel? Book a consultation to speak with one of our experts today.

What is an API Channel? Reading Time: 5 minutes

There’s A New Channel in Town

It’s called the API channel — and it’s quickly gaining footing with the others (mobile, web, branch, ATM).


The API channel is special, in that it not only sits next to the other channels, but it also supports them — APIs increase the speed, quality, and functionality behind every digital touchpoint where digital business occurs. So it’s a big one to get right.

You might be thinking, “Whoa, that’s a lot of touchpoints!” In which case, you’re spot-on. The program will be vast, and it will need to be scalable — a true API strategy goes far beyond managing just a handful of APIs and hackathons.

Before we dive in, let’s cover a few key terms and why they’re relevant to digital business. (You can skip over this next section if you’re already familiar with the bold letters, and you really fancy yourself a know-it-all. No judgments here.)

 

Digital Business: A Few Key Terms

Every digital banking trend hinges on APIs (Application Programming Interfaces), because they offer fast and secure functionality, or integration, between endpoints. These endpoints allow APIs and services to access data from a range of interfaces – your laptop, my bank; your phone, the Lyft app, your bank account, you get it. Typically every API carries out one or more capabilities, or business functions.

One way to think of APIs is to picture background mini-apps, delivering services behind the scenes (and sometimes not just behind! See: GoogleMaps API). Another metaphor we’ve been throwing around the digitalML HQ of late is the circulatory system. The data is like blood that gets distributed around the body (the company), and the heart is the API/service catalog — as the heart gets stronger (more portfolio coverage), so does the heartbeat. More on that in a future post.

Now, what do we mean by API channel? According to Investopedia, a channel is a “chain of businesses or intermediaries through which a good or service passes until it reaches the end consumer.”

In this case, the same holds true. This difference being that each touchpoint (point of contact) along the “chain” can feed data directly to the API channel — which makes for great end-to-end (E2E) digital reporting, by the way. End-to-end being the entire digital story, start to finish, core function to end-user.

An obvious example of E2E supply chain reporting in action is the suite of shipping and tracking APIs offered by UPS, which revolutionized delivery service, giving an edge to the retailers who could quickly jump on board to offer the API-based service for realtime status.

 

What the API Channel Supports

In reference to the above Investopedia quote, the term end consumer broadens a bit for the API channel — for example, a typical retail channel might assume the end consumer to be a traditional retail customer. Yet that same retailer’s API channel will have end consumers that are not only retail customers (see non-API usersbelow), but also Open API developers (see self-selected users & enterprise-selected users below), various B2B partners (see enterprise-selected users below), and internal consumers (see products, enterprise, product integration use below), as well.

The following graphic is a great view of the many channels supported and enhanced by your API channel. In this instance, the orange boxes represent the collective API channel, the green boxes represent endpoint channels, the blue boxes represent end users, and the gray box represents your core enterprise applications.

Diagram showing the API channel

You can see how there’s orange backing nearly every green — that’s the API channel supporting every other channel.

Channel Dive: 4 Use Cases

To fully grasp this graphic, let’s take a deep dive into four ways an API channel supports your flow of services, experiences and products for end users.

 

 

1. Internal APIs Support Mobile and Web

We’ll start with the first flow above, from your core capabilities to a non-technical end user. For a retail bank, this user might be your typical retail banking customer.

Think of internal APIs as pre-packaged core capabilities — ready-made building blocks, so your company is quickly able to whip together great new experiences. Here, your “Account” and “Customer” internal APIs might contribute to a great digital experience by feeding real-time data to the web and mobile channels your retail customers use (Non-API users).

the API channel enhances mobile and web

 

2. Open APIs Bring Your Business to 3rd-Party Channels

Say you offer a handful of open web APIs, available in a developer portal. That portal could be considered an end-user channel in its own right, if you’re charging for usage.

Let’s say you offer an open web API called “Spend Alert API” — it alerts retail customers when they’ve spent more than their budgeted goal. Self-selected users (API consumers) may use this API to bring your functionality to a product they’re building.

Or perhaps it’s being used by an appointed API consumer (internal or external) to build a great digital experience for one of your own private, partner, or public channels. Or, in yet another option, it could wrapped into a white-labelled experience and sold by a partner.

As you can imagine, the open web node of the API channel hosts many opportunities for digital business, extending your brand to countless further channels.

The API Channel Supports Your Open Web Portal, and in turn, opens many opportunities along 3rd party channels

 

3. B2B APIs Enhance B2B Channels

Say your bank partnered with TransUnion to build a “Check Credit Score” B2B API together (this is not considered an Open Web API simply because it is used solely between B2B parties).

This API brings integration between your companies by combining your customer data with TransUnion’s credit-checking functionality. This might enhance your partner channel, or the API might extend your combined business to a public third-party channel — Mint, or Zelle, perhaps.

The API Channel Enhances B2B APIs for B2B Channels

 

4. Product APIs Smooth Product-to-Product Interaction for All Channels

Product APIs, not to be confused with API Products, integrate between products only.

In a fourth use case (we’re sure there are more!), perhaps you built a “Low ATM Balance” product API that integrates between your ATMs and one of your cash supplier services to build a faster, smoother supply chain for your own ATM channel.

The API channel enhances your products, as well as product-to-product interactions, in turn enhancing digital experiences and products along your private, partner and/or public channels

In these simplified examples of your distribution channels, we hope we’ve provided a better understanding of the many benefits of an API channel, and why the API strategy that governs that channel is so important.

It’s worth noting that internal APIs, also called (capability APIs), support every flow we’ve covered today, and while further from the monetizeable endpoints, your internal APIs bring arguably the greatest value to your digital business dealings, as they offer the most reuse and interoperability.

If you have any questions or would to discuss your API strategy, let’s talk.

To hear what some of the big banks have to say about building their API channels, check out: “5 Top Banks Open Up Re: API Channels“.