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.
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.
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).