CSOS: A Business Case for APIs and Microservices

To the detriment of those around me, I often point out technology failures. Quite often, those failures relate to the inability to easily “break down the application silo.” This means the whole app from the front end to the complicated stuff on the back end is considered as a “solution to a problem.”

Once an application silo is created, it’s hard to change

Why might it change? Well, let’s say business conditions change. Or the target audience changes. Think about corporate travel booking. There was an interface used by travel agents. These travel agents had special training. You’ll realize what kind of training the first time you book a flight to Portland and end up in Oregon instead of Maine. And, the world evolved.

Employees started making their own flight reservations but were still using the interface designed for skilled travel agents. To change that interface would require changing the whole stack.

For example, a rule checking to see which Portland you wanted to visit would be put on the back end, and then expressed somewhere in the UI on the front end. (Of course, the rule could be implemented at the front end… But do you really want to embed business logic into your UI? Not really… But I digress.)

Also, the information doesn’t easily move between application silos. With APIs, it’s easier to unlock these silos and share information, but it still doesn’t happen often enough (this is largely also a people and process problem and not just a technical problem).

When thinking about the business case of a problem you have, you go buy a solution to the problem. So, if you want to order management, you might go buy an order management solution. You don’t think to build an order management solution.

Nor should you.

However, no matter how good your silo (your order management solution in my example) is, it’s going to eventually fall short.

It’s going to need some data from your organization

It’s going to need to hook into your enterprise authentication infrastructure (especially if it has APIs of its own for others to get data).

It’s going to have changing requirements over time. Often, requirements that are unforeseen at the time of implementation. (By the way, I have a whole vent about why we buy the enterprise software wrong — because we buy as if we’re playing a finite game, but we’re actually playing an infinite game; an infinite game demands a different decision-making process.)

In summary, business software challenges Axway helps with are guaranteed to arise after a purchase decision is made, yet… These many pretend that the challenges don’t exist. Or, that they can somehow deal with them later. They are:

1. Requirements evolve, specifically around customer and user experience.
2. Data sharing is a first-order problem, not a side-effect.
3. Real-world integrating into the enterprise, whether it’s to get critical data or participate in the infrastructure like for authentication, is complicated.

Many companies deal with this one-off, rather than using something like Axway AMPLIFY™ to create a platform for repetitively solving for these known, but often-ignored real-world challenges.

I started writing this because I came across a great business justification for Axway AMPLIFY and wanted to share it to help people understand how Axway helps our customers.

CSOS – DEA’s Controlled Substance Ordering System

This is actually a situation where we have a solution, not just things that make a solution better. But, I’d like to share the DEA’s CSOS requirements because they present an interesting point of view on how systems change in ways that make it difficult for incumbents to adapt.

For starters, this is a governance and compliance “thing.” Which means failures = penalties. In one case, a failure to comply required that a whole business be shut down for two years.

That’s the motivation to get this right, but not quite the business driver.

During the pandemic, supply chains are squeezed, and care providers need to be able to submit orders more frequently and with more granularity. Without sacrificing compliance.

Let’s see the business case the DEA put together for the Controlled Substance Ordering System (that replaces the paper/fax ordering process):

1. Ordering Freedom: Older systems had a limit on the number of items that could be in any order. They wanted the ability to place one order yet have the flexibility to order whatever they needed.
2. Faster Transactions: Online certificate processing would enable faster validation and approval, meaning those ordering drugs could rely more on just-in-time ordering, lowering their operational cost, as well as reducing the risk of drug loss or over-ordering.
3. Accurate Orders: A modern online ordering system will do validation checks, etc. In the Axway solution demo, we use AI to not only validate the order, but see if the order “makes sense” considering historical ordering patterns and other information, to not only make sure orders are accurate but to avoid costly compliance risks.
4. Decreased Cost: The alternative is literally faxing around paper forms and manually copying data (which leads to errors, delays, etc., which all costs money). Additionally, a good system can help its users be successful, meaning that less training is required in the process (when compared to filling out paper forms).

I highly recommend learning more about Axway’s CSOS offering on Axway’s Developer Blog.

The important point here – there’s no talk about microservices, AI, moving to the cloud, or APIs. Just faster and more flexible orders, that are more accurate and employee-friendly, which help companies lower their costs and their compliance risks.

So, whether you’re ordering drugs (like Cardinal Health) or ordering parts and managing a supply chain (like Pöppelmann) or creating an open banking platform (like PermataBank), do you want to be faster and more flexible, easier to use while improving accuracy, and all while lowering your costs and managing compliance?