Opportunity Everywhere

Soft­ware is hard­er than it looks, and inte­gra­tion in par­tic­u­lar is com­plex. Because it’s not about “inte­gra­tion” but “inte­gra­tion at scale”. Jump to the bot­tom of this post to learn the three human/behavioral things you need to con­sid­er about your inte­gra­tion strat­e­gy.

Solv­ing any indi­vid­ual inte­gra­tion prob­lem isn’t near­ly as hard as it to solve for any pos­si­ble inte­gra­tion in the future, espe­cial­ly if you con­sid­er that you might will want to allow any­one to self-serve their inte­gra­tion needs with­out com­pro­mis­ing security/governance.

In the last week along, we’ve seen a lot of things hap­pen that are fun­da­men­tal­ly inte­gra­tion prob­lems:

1. Unem­ploy­ment fil­ing sys­tems around the US have been unable to han­dle the demand, some even require Inter­net Explor­er or, in its absence, a fax machine (!!).
2. Small busi­ness loans pro­cess­ing. The Gov­er­nor of NJ put out a call for Cobol Pro­gram­mers. Of course, a pos­si­ble solu­tion is a tool like GT Soft­ware for cre­at­ing APIs out of Cobol sys­tems. How­ev­er, nei­ther address­es the real chal­lenge. Inno­va­tion with soft­ware at scale and speed.
3. Patient record shar­ing to under­stand the virus impacts. It’s one thing to have good data (and smarter peo­ple than I can argue whether we have cor­rect data). It’s a whole oth­er thing to be able to secure­ly share, and inno­vate using, patient record data.

Inte­gra­tion sales peo­ple should be call­ing on gov­ern­ments of all sizes, banks and pay­ments com­pa­nies, and every com­pa­ny that touch­es the health­care sup­ply chain.

It’s not about the problem, but the class of problems

They should how­ev­er, not be help­ing you fix your unem­ploy­ment sys­tems, your loan pro­cess­ing work­flows, or patient record shar­ing.

They should be help­ing you build an inte­gra­tion capa­bil­i­ty in your orga­ni­za­tion that solves for the broad class of inte­gra­tion chal­lenges your orga­ni­za­tion faces every day. Every day, you need to move faster, man­age secu­ri­ty and gov­er­nance, and con­tin­u­ous­ly inno­vate to cap­ture “con­sump­tion oppor­tu­ni­ties” for the val­ue your orga­ni­za­tion cre­ates.

This of course, is not only a tech­ni­cal prob­lem. The chal­lenge though is that since inte­gra­tion is com­plex and tech­ni­cal. Jar­gon gets in the way, and when peo­ple can’t break through the jar­gon, they don’t real­ize that tech­nol­o­gy isn’t the main bar­ri­er to suc­cess (they might real­ize, but they don’t inter­nal­ize; they don’t appre­ci­ate the non-tech­ni­cal chal­lenge inti­mate­ly).

A co-work­er shouts to the room full of sales peo­ple: “Of course your cus­tomers are using APIs, it’s 2020! It’s not about APIs.”

I could­n’t have said it bet­ter myself. This is a prime exam­ple of tech­nol­o­gy get­ting in the way of progress. Peo­ple yell “APIs” and think their inte­gra­tion chal­lenges are solved.

And yet we still need Inter­net Explor­er to file unem­ploy­ment claims.

Obvi­ous­ly, there’s some­thing wrong (and yes, I’m con­flat­ing a bunch of dif­fer­ent types of tech­nol­o­gy chal­lenges to make my point, don’t hate me).

The fact that any­one think it’s ok to have a sys­tem that only works with IE is the same fun­da­men­tal think­ing that leads to the chal­lenges we’re see­ing in fil­ing unem­ploy­ment claims, pro­cess­ing loans, or shar­ing patient record data.

Three things

So what can be done?

That’s the key ques­tion, isn’t it?

Here are a few things to focus on, ques­tions to explore in your orga­ni­za­tion to see if you’re posi­tioned to sur­vive in the future.

It’s not about the APIs, it’s about the API plat­form. This isn’t my knowl­edge-bomb. This comes from Gart­ner. Of course there’s a lot packed into that — what is an API Plat­form? The answer which goes well beyond this post and my friend Shawn has writ­ten a great deep dive ‘what is an API Plat­form?’ over at Axway’s API Friends blog.

How­ev­er for the sake of my thought process, it’s impor­tant not to answer that ques­tion by going down the tech­ni­cal jar­gon rathole of DevOps, DevSec­Ops, API Test­ing, API Ver­sion­ing, and so on.

Think about the abil­i­ty to self-serve inte­gra­tion needs. Think about a place where peo­ple can go to find infor­ma­tion about how to use your orga­ni­za­tion’s tech­ni­cal assets. Often com­pa­nies do this exter­nal­ly by cre­at­ing an API devel­op­er por­tal… and that’s a good place to start, but you need more. You need to keep all sorts of inte­gra­tion assets in this one place; and by hav­ing one place you build the human habits into your devel­op­ment teams so that they work togeth­er, share prop­er­ly, and so that IT can have an end-to-end view of how your assets are applied to the soft­ware you cre­ate to solve prob­lems.

These are the qual­i­ties that ensure that you can solve prob­lems in the future, no mat­ter how tech­nol­o­gy changes.

Elim­i­nate shad­ow IT (Inte­gra­tion). I once worked on a project where an API devel­op­er, whose ser­vice was still in devel­op­ment, had shared his API with a team as a “favor”. Long sto­ry short, that team then bun­dled the API’s cre­den­tials into a soft­ware SDK and shared it. Some of the teams that end­ed up using it put it in pro­duc­tion… with­out any idea that the back end was a devel­op­ment machine on some­one’s desk.

Anoth­er time, a devel­op­ment emailed every­one using a serv­er that a serv­er would be decom­mis­sioned about a week lat­er now that the project was over. A week lat­er, when the serv­er dis­ap­peared pan­ic ensued as a bunch of pro­duc­tion apps failed.

Yet anoth­er time, I was locked in a room as my escort rushed to ops to fix a prob­lem I sur­faced where a sys­tem in a pro­duc­tion semi­con­duc­tor man­u­fac­tur­ing facil­i­ty was using a devel­op­ment serv­er.

I could go on. The point is, that this is the human behav­ior being inte­gra­tion. Some­one needs to get some­thing done, and they know the peo­ple that can help. The inte­gra­tion hap­pens in the shad­ows, and the peo­ple who own the process (who are need­ed when there’s a breach, or a fail­ure, or the need for long term main­te­nance) have no idea that it’s hap­pen­ing.

This hap­pens because peo­ple are doing the best they can to get their jobs done. Because work­ing the process is too hard. Because the process is opaque.

Peo­ple want to solve their own prob­lems. Let them. Help them. And that’s how you’ll be able to get a bet­ter under­stand­ing of the val­ue of your dig­i­tal assets and how they can be used to expose val­ue.

Take secu­ri­ty out of the hands of devel­op­ers. A long time ago, I had a doc­tor. He had an oppor­tu­ni­ty to run a radi­ol­o­gy lab, so he closed his prac­tice. A year lat­er when he came back, one of the first things he did was get rid of the radi­ol­o­gy equip­ment he had in his office.

I asked him about it. He said, after see­ing how the equip­ment, skills, and process­es that a facil­i­ty which does noth­ing but radi­ol­o­gy oper­ates his patients would be best served by peo­ple who did noth­ing but radi­ol­o­gy all day, every day.

The same applies for soft­ware secu­ri­ty. You can expect your devel­op­ers to write secure code… but frankly, we know that does­n’t work often enough.

And, I learned when I inter­viewed at the CIA that it’s not just about the pol­i­cy, but what can be mea­sured about the pol­i­cy. Back then, we were try­ing to mon­i­tor Rus­si­a’s nuclear stock­pile. It was­n’t enough to have a treaty, we had to be able to mea­sure the treaty’s terms or it did­n’t mat­ter.

The same applies to soft­ware secu­ri­ty. It’s not enough to have a “secu­ri­ty pol­i­cy” if you’re not able to mon­i­tor it in real time, all the time, for all your soft­ware. Espe­cial­ly as soft­ware starts to extend past your orga­ni­za­tion­al bound­aries to your part­ners and cus­tomers.

Leave soft­ware secu­ri­ty to the experts. Let them imple­ment best prac­tices and stan­dards by pol­i­cy in the plat­form, and let your devel­op­ers move faster, with­out sac­ri­fic­ing secu­ri­ty or gov­er­nance.

Summary

Seri­ous­ly, if you’ve read this far… what’s wrong with you? Hah. Kid­ding. You’ll prob­a­bly like my def­i­n­i­tion of Dig­i­tal Trans­for­ma­tion and should def­i­nite­ly talk to the Axway Cat­a­lysts (they’re peo­ple, not sales­peo­ple, and their indi­vid­ual con­tact infor­ma­tion makes them acces­si­ble).