Integration Support Challenges in Production

Posted on by Mark Myers Leave a comment

Now this is an incredibly dull subject, but one that many companies continue to struggle with when it comes to integrations.

All integrations, by their very nature, are quite brittle processes.

They often involve converting data from one format to another, and because they cross multiple systems and ownership boundaries, they can be difficult to pin down when things go wrong.

Many of the endpoint systems that are integrated into have very restrictive support models, and security rules often mean that each team can see only a limited part of the picture.

So, once the project work has been completed and everything is technically “working,” as it should, then the real challenge begins, which is how do you actually support it in the long term?

Of course there will be issues around monitoring, workflow, ownership, and escalation paths, but ultimately it comes down to one thing:

Responsibility.

People rarely want to follow a formal process that leads to them having to pay for it to be fixed. Instead, you’ll hear, “Oh, X is broken, call Y.”

It’s human nature, and integrations tend to encourage this kind of finger-pointing.

“It’s your bit that’s broken, not mine.”

The best tip I’ve found for handling this is to ask a very simple question…

Is this a new piece of code, a new application, or a new machine? If so, who are you paying to look after it?

That’s the crux of the matter. If there’s no budget, then most departments will quite rightly say, “That’s not our responsibility,” unless it’s a simple configuration change or something that clearly falls within their existing remit.

But integrations rarely work like that.

They almost always introduce new code, new objects, or new dependencies.

So, the next time you’re trying to work out who owns a piece of integration work, just follow the money.

Whoever is being paid to maintain it is responsible for it. If no one is, then you haven’t yet found an owner. And if someone is willing to take the funding or resources, then they are, by definition, the right people to make responsible.

It’s a simple question, but it saves a lot of pain.

Baseline Thinking: The real difference between corporations, massive organisations and the rest of us.

Posted on by Mark Myers Leave a comment

This is an insight that struck me recently, though it’s hardly new. In fact, anyone working in marketing or public relations will tell you the same: people, as individuals, are intelligent. People in groups, however, can behave in very odd ways.

So how does this play out in the corporate world? It often comes down to the gap between how small groups of experts expect people to react and how large organisations know people actually react.

Take something as simple as installing software. If you give a set of instructions to technical experts or developers, they’ll follow them making intuitive choices along the way. Rarely will anything need spelling out. The target audience will just handle it.

Now compare that with giving the same instructions to the general public. Suddenly you need to specify every click, every option, every screen. What feels like minutiae to an expert is essential detail to ensure success for the rest of humanity.

Now you have this understanding, you can explain it to your experts as they will often wonder why corporate infrastructure demands such exhaustive, step-by-step detail. To the expert, it feels pedantic, even pernickety and pointless. But for a corporate support team, responsible for thousands of people with widely varying levels of knowledge it is just dealing with a very broad baseline of humanity.

Because in that large, mixed pool of users, someone will get it wrong. Someone will click the wrong thing, misread the obvious, or inadvertently cause chaos. And if support hasn’t built in the safeguards, they’re the ones left cleaning up the mess.

So next time you find yourself rolling your eyes at “silly” questions from corporate support, remember: they’re not being awkward. They’re working to a broader baseline of understanding, one designed to prevent the inevitable finger-pointing blame game from happening

Actually Implementing AI into Existing Systems

Posted on by Mark Myers Leave a comment

Now that we have all got over the initial flurry of being astounded by AI chatbots and their very human way of handling conversations, a lot of clients and companies are moving on to the serious, practical side of implementation. Everyone seems to want to fit AI into everything, and once you reach this stage, the excitement quickly gives way to the realisation that most of the challenges you face in getting it to work are the same old ones we have always faced with integration and software adoption.

To be honest, I personally find chatbots, while amazing, don’t quite beat the real thing. If you have ever worked in a company with helpful colleagues, it is impressive that a computer can do that job, but the function itself is not new. What is amazing is doing it at scale. Instead of asking ‘Janice in Finance’, you ask an AI, and an AI can answer thousands of people at once.

And here is where we hit the same old problem; even ‘Janice in Finance’ isn’t a divine miracle, so how does she do what she does, and how can we get AI to do the same?

The first issue is data. Have we given the AI all the data it needs? Have we given it access to live sources, or are we expecting miracles from a one-time data load? Have we structured the data in a way that makes sense? Just dumping it into a database without context or rules will not work. AI needs to know how information connects in order to make useful deductions. and while there are incredible tools that can help with this, when it comes to making assumptions, particularly financial or legal ones, the wrong connections or lack of context can quickly become very dangerous. This has been a problem since long before AI.

The second issue is workflow. Once you have gone past the novelty of “oh, this is a chatbot”, if it does not fit into the user’s normal workflow, they will not use it. Make sure that any new AI features work within existing processes. This not only helps adoption and avoids unsettling users, but failing to do so actually takes away some of AI’s advantages. For example, if you are assessing whether an insurance claim is potentially fraudulent, that used to be done using a set of complex but static rules which produced a percentage likelihood. AI can now perform that calculation far more accurately, but you do not need to change the interface at all. It simply improves what the user already sees, which is exactly how good AI should feel: an invisible improvement that makes the job easier without disrupting needlessly.

The third issue is adoption. Forcing new features onto people drives them mad, even if those features are shiny and fashionable. It makes users nervous, and they start to see change as a threat. There are thousands of books and experts on adoption because it is a very old game. My least favourite part is when senior leaders believe the technology will replace staff and start talking directly to business teams about “efficiency gains”. This immediately puts people on edge. AI already carries an overtone of job replacement, so pushing it from the top without the right tone can do real harm. It needs to feel like an aid, not a threat.

Finally, there is the way we introduce AI. Making a big song and dance about any new technology might be great for publicity, but it rarely impresses the people that do the work day to day. Pitching AI as something that makes people’s lives easier and helps them do their jobs better works far more effectively. It should be seen as a tool that helps teams perform better and, ideally, be rewarded for it. Declaring “AI is here, the world will never be the same” is exactly how you generate resistance and backlash. Features will be viewed as threats rather than improvements, and that helps no one.

In short, make sure any AI you introduce actually adds value rather than simply being “the new hotness”. Even though AI is a fundamentally transformative technology, from your users’ and business teams’ point of view it is still just another software adoption process. Use all the lessons you have learned over the years to make it as seamless as possible.

The Concept of the ‘First Trumpet’ in Corporate Projects

Posted on by Mark Myers Leave a comment

There’s a useful analogy I once heard from musicians about how orchestras really work. Officially, the conductor runs the show. They set the beat, they give the cues, and everyone’s eyes are on them. To the audience, it looks as though the conductor is firmly in control.

But orchestras have their own quiet safety net. If the conductor is incompetent, unreasonable, or simply fails to lead, the orchestra doesn’t fall apart. Instead, it starts following the lead of the “first trumpet” 1. The clever conductors will realise this, and self-aware ones take it as a sign: if the orchestra is following someone else, something has gone wrong in their leadership.

Most of the audience will never notice the shift. They’ll assume the conductor is still in charge. But the musicians know, and so do the more experienced listeners.

I think this is the best analogy I’ve ever come across for corporate projects. If you’re the project lead, the “conductor”, and you find that people are no longer coming to you with problems, or that you’re having to chase rather than being sought out for help, chances are you’ve already been quietly replaced by a “first trumpet”.

This isn’t a role that anyone really wants. It’s an extra burden on the person who has stepped up, often reluctantly, because the team still needs direction. The only real solutions are for the formal lead to:

  1. Step aside.
  2. Fix what’s going wrong,
  3. Replace the “first trumpet”

If you suspect this has happened to you, the best thing you can do is find out who your team is actually following and ask them genuinely where you’ve gone wrong. They’ll usually tell you, because they don’t want your job; they’d much rather you were doing it properly.

Projects, like orchestras, need a conductor. The trick is to remain the one the team chooses to follow.

Update

I got some feedback on this from an old friend and it looks like the origin instrument suffered a little bit from Chinese whispers, and rather than “First Trumpet”, it should really be “Lead Violin”

“As a trumpeter, I would love to say this was true, but it’s really the Principal 1st Violin, who also has the title “Leader” for this very reason. Three reasons for that choice:1) the violinist is at the front where everyone can see them 2) it’s easier to follow their bow movements than it would be to follow any movements made with a trumpet 3) they are playing most of the time (unlike the trumpets) so there’s something to follow”

“I’ve certainly played in concerts where this happened… if you go back a few hundred years, conductors weren’t a thing, and orchestras were usually led by someone playing – often the harpsichord. Most jazz bands still run this way. I guess you don’t need to go back that far to find a dev team without a scrum master of whatever they’re called…”

 

  1. that is the head trumpeter in an orchestra[↩]