Software is harder than it looks, and integration in particular is complex. Because it’s not about “integration” but “integration at scale”. Jump to the bottom of this post to learn the three human/behavioral things you need to consider about your integration strategy.
Solving any individual integration problem isn’t nearly as hard as it to solve for any possible integration in the future, especially if you consider that you might will want to allow anyone to self-serve their integration needs without compromising security/governance.
In the last week along, we’ve seen a lot of things happen that are fundamentally integration problems:
- Unemployment filing systems around the US have been unable to handle the demand, some even require Internet Explorer or, in its absence, a fax machine (!!).
- Small business loans processing. The Governor of NJ put out a call for Cobol Programmers. Of course, a possible solution is a tool like GT Software for creating APIs out of Cobol systems. However, neither addresses the real challenge. Innovation with software at scale and speed.
- Patient record sharing to understand the virus impacts. It’s one thing to have good data (and smarter people than I can argue whether we have correct data). It’s a whole other thing to be able to securely share, and innovate using, patient record data.

Integration sales people should be calling on governments of all sizes, banks and payments companies, and every company that touches the healthcare supply chain.
It’s not about the problem, but the class of problems
They should however, not be helping you fix your unemployment systems, your loan processing workflows, or patient record sharing.
They should be helping you build an integration capability in your organization that solves for the broad class of integration challenges your organization faces every day. Every day, you need to move faster, manage security and governance, and continuously innovate to capture “consumption opportunities” for the value your organization creates.
This of course, is not only a technical problem. The challenge though is that since integration is complex and technical. Jargon gets in the way, and when people can’t break through the jargon, they don’t realize that technology isn’t the main barrier to success (they might realize, but they don’t internalize; they don’t appreciate the non-technical challenge intimately).
A co-worker shouts to the room full of sales people: “Of course your customers are using APIs, it’s 2020! It’s not about APIs.”
I couldn’t have said it better myself. This is a prime example of technology getting in the way of progress. People yell “APIs” and think their integration challenges are solved.
And yet we still need Internet Explorer to file unemployment claims.
Obviously, there’s something wrong (and yes, I’m conflating a bunch of different types of technology challenges to make my point, don’t hate me).
The fact that anyone think it’s ok to have a system that only works with IE is the same fundamental thinking that leads to the challenges we’re seeing in filing unemployment claims, processing loans, or sharing patient record data.
Three things
So what can be done?
That’s the key question, isn’t it?
Here are a few things to focus on, questions to explore in your organization to see if you’re positioned to survive in the future.
It’s not about the APIs, it’s about the API platform. This isn’t my knowledge-bomb. This comes from Gartner. Of course there’s a lot packed into that — what is an API Platform? The answer which goes well beyond this post and my friend Shawn has written a great deep dive ‘what is an API Platform?’ over at Axway’s API Friends blog.
However for the sake of my thought process, it’s important not to answer that question by going down the technical jargon rathole of DevOps, DevSecOps, API Testing, API Versioning, and so on.
Think about the ability to self-serve integration needs. Think about a place where people can go to find information about how to use your organization’s technical assets. Often companies do this externally by creating an API developer portal… and that’s a good place to start, but you need more. You need to keep all sorts of integration assets in this one place; and by having one place you build the human habits into your development teams so that they work together, share properly, and so that IT can have an end-to-end view of how your assets are applied to the software you create to solve problems.
These are the qualities that ensure that you can solve problems in the future, no matter how technology changes.
Eliminate shadow IT (Integration). I once worked on a project where an API developer, whose service was still in development, had shared his API with a team as a “favor”. Long story short, that team then bundled the API’s credentials into a software SDK and shared it. Some of the teams that ended up using it put it in production… without any idea that the back end was a development machine on someone’s desk.
Another time, a development emailed everyone using a server that a server would be decommissioned about a week later now that the project was over. A week later, when the server disappeared panic ensued as a bunch of production apps failed.
Yet another time, I was locked in a room as my escort rushed to ops to fix a problem I surfaced where a system in a production semiconductor manufacturing facility was using a development server.
I could go on. The point is, that this is the human behavior being integration. Someone needs to get something done, and they know the people that can help. The integration happens in the shadows, and the people who own the process (who are needed when there’s a breach, or a failure, or the need for long term maintenance) have no idea that it’s happening.
This happens because people are doing the best they can to get their jobs done. Because working the process is too hard. Because the process is opaque.
People want to solve their own problems. Let them. Help them. And that’s how you’ll be able to get a better understanding of the value of your digital assets and how they can be used to expose value.
Take security out of the hands of developers. A long time ago, I had a doctor. He had an opportunity to run a radiology lab, so he closed his practice. A year later when he came back, one of the first things he did was get rid of the radiology equipment he had in his office.
I asked him about it. He said, after seeing how the equipment, skills, and processes that a facility which does nothing but radiology operates his patients would be best served by people who did nothing but radiology all day, every day.
The same applies for software security. You can expect your developers to write secure code… but frankly, we know that doesn’t work often enough.
And, I learned when I interviewed at the CIA that it’s not just about the policy, but what can be measured about the policy. Back then, we were trying to monitor Russia’s nuclear stockpile. It wasn’t enough to have a treaty, we had to be able to measure the treaty’s terms or it didn’t matter.
The same applies to software security. It’s not enough to have a “security policy” if you’re not able to monitor it in real time, all the time, for all your software. Especially as software starts to extend past your organizational boundaries to your partners and customers.
Leave software security to the experts. Let them implement best practices and standards by policy in the platform, and let your developers move faster, without sacrificing security or governance.
Summary
Seriously, if you’ve read this far… what’s wrong with you? Hah. Kidding. You’ll probably like my definition of Digital Transformation and should definitely talk to the Axway Catalysts (they’re people, not salespeople, and their individual contact information makes them accessible).
David, Great post. I have been thinking about the challenges of how IT is constructed (who pays for the project) and how IT has moved from building to buying software. Now we have a set of distracted commercial software and we can build new connected, solutions to address the unplanned needs fast enough. Just as in your post, the answer seems to point to integration and the ability to build light weight integrations quickly.
Really enjoyed this post and I read it all.
I see stuff like this everywhere.
I just had to activate a credit card. Major bank (so presumably they’re good at stuff and have a lot of people who can get stuff done).
Took me a week.
The website wasn’t working. But there was no indication that it wasn’t. Eventually, the authorization transaction completed.
Now… why I have to go to a different site URL and manually enter information just to be authorized? Why can’t there simply be a button next to the card in my account that asks for the CVV (to make sure I have the card) and lets me just authorize it? Why can’t they tell me that the sites not working, instead of saying “the data doesn’t match our records” (whatever that means; especially since eventually it did work… so the data did match, it’s just that they weren’t matching it).
I know these banks spend a lot of money marketing these cards.
They spend a lot of effort “winning the partnerships” (my card is a big name-brand points card).
Yes, they F‑up something as simple as making the technology simple.
Reminds me of the time my hospital reconstructed a doctor’s post-visit processing area because EPIC was upgraded, and it was easier to rebuild the room over a weekend, than to adjust the post-visit process flow.