Are cloud vendors the true entities under threat from AI?

Let’s start by being specific. I’m talking about cloud software vendors, not software vendors in general. So this has nothing to do with the recent recoding and release of the entire Adobe suite. That’s a different conversation.

Most cloud software vendors offer a function that is already available within the major cloud services but which is awkward or difficult to configure, non-obvious, or has various pitfalls. Essentially, they provide a framework for your cloud, usually for a specific function.

As we all know, frameworks are designed to offer simplicity and ease of use, but to do that, they often have to roll up or hide a lot of the features you might actually want or display them in a slightly different way.

This is one of the core reasons why frameworks often start out seeming like a brilliant idea but end up a burden. Say a problem seems really hard to solve, and a company comes along and says, “Yes, we’ll do this for you. It’ll make it easier.”

However, as a system matures,   you add features and gain complexity, and the overlayed framework or cloud vendor’s system can actually become harder to update, maintain and pay for, than if you’d simply done it directly using the original cloud services.

And I think this is where generative AI coding tools are starting to change things.

AI can now remove a lot of this particular problem. It can provide the initial ease of implementation that frameworks and cloud vendors offer, without necessarily being any harder to edit after implementation.

So you could start off with Azure or AWS, sit down with Claude or whatever AI tool you prefer, and get it to write you a function or feature. It will go off and do that, producing nicely documented code that does what you want.

However, one of the core things people don’t like about AI written code is that, once it had been produced, very rarely would humans go through and work out exactly how it had been done. This made it potentially harder to maintain.

But that’s not really any different from using a vendor’s product or a big framework. You put it in, it does a very fast job initially, but going back and changing anything can be an absolute devil.

However, AI has not only provided that first fast implementation that a vendor or framework would offer, but it also writes a lot of its own documentation. Anyone who’s read one of those monstrous README files that AI code generation tools produce will know what I mean.

More importantly, AI is actually quite good at going back, reviewing what was done previously and making amendments without screwing everything up. And it’s getting better and better at it.

It’s that speed of updating, but also the fact that doing so costs comparatively little compared to paying for a framework, dealing with the risk of nobody maintaining it, or continuing to pay a vendor’s licence costs, that makes AI a genuine advantage for the customer.

So you end up, three or five years down the line, with a system written directly using basic cloud services, which is well documented and which you can change whenever you need to.

If a vendor goes out of business, changes direction or suddenly changes its pricing, you’re suddenly under threat.

There’s also the question of rewriting.

People who have given AI an existing codebase and asked it to recreate it in something else, notably Rust at the moment, will know just how good AI is becoming at doing that.

Compare this with the sheer monumental difficulty of migrating from one framework or vendor to another.

I say this as someone who’s been doing migrations for 30 years.

This is one of the genuine jobs for AI, and I think it’s why, when you’re talking to almost any cloud software vendor, they themselves go on and on about what their own AI functionality gives you.

Because I suspect they’re the ones, more than almost anybody else, facing a genuine threat from AI taking away their particular market.

The Dynamics of an Acquisition-Led Business

This is an observation post primarily to do with the insurance industry, because large parts of it have grown by acquisition. Many large insurance corporations grow by acquiring companies that have a stake in the line of business they are interested in or are potential competitors.

Obviously, this happens in other industries as well, but it is particularly common in insurance.

One of the key differences is that insurance and finance companies often acquire businesses that are already doing well. So, if you are doing really well and making good money, there is a good chance that a larger corporation will go, “Oh, they have the market sorted. They have an excellent product”, and will purchase you.

This leads to an odd dynamic inside any given corporation.

When something comes down from the group or parent company, there is often a great deal of pushback from former subsidiaries. The key reason for this, which I think is often missed, is that each of these subsidiaries were and are quite capable of standing on their own two feet.

They might not have been big, but they were holding their own, and they were growing.

They didn’t ask to be acquired.

They were taken over, and a lot of the personalities inside those smaller companies were the ones driving that growth. They were taking bold, leading decisions, and now they’re being given orders where they don’t think they need them.

They are effectively big boys and big girls who have moved out and are running their own lives. But, for some reason, their parents have forced them back into the family home and are now telling them what to do.

And they don’t see why they should listen.

In fact, a large proportion of them will look at the larger corporate environment and think, “Well, our way is better. I’m going to fight back and try to make the way I see things going forward the future of this corporation.”

And that is one of the core reasons we get such fierce political conflicts inside corporations that have grown through acquisition rather than organic growth.

So, next time you are working with, or trying to get your point of view across to, a sub-brand or subsidiary within a corporation, realise that for a lot of the time, the people you are talking to are successful in their own right and did not ask to join the same company as you.

They’ve been doing quite well for themselves, and the corporation can come out stronger by taking all the views of the different parts and merging them into a unified whole.

Vendor laptops are better set-up than internal ones.

This, on the surface of it, seems like a really fringe issue. But I’ve seen it four times in the last year.

If a client is extensively using cloud services, and it makes no difference which ones, because this problem applies to them all. Then nearly all cloud services require access to third-party utilities or additional tools to work efficiently.

It can be anything from trying to use Python with Azure, to trying to do anything with Salesforce without a Chrome or Edge extension. Whatever the platform, no cloud service works perfectly straight out of the box with just its built-in tools. If it did, you wouldn’t see so many third-party vendors and tools at conferences.

So, to do the best job, you install a bunch of plugins. That might be loads of extensions to get VS Code working properly, or Chrome and Azure extensions to get Salesforce working, or whatever your particular platform requires.

That’s fine and everything, but increasingly there is a problem.

When you have cloud services set up or development done by a vendor, they use their own company’s laptops. They connect to the cloud, install all the tools they know they need, and develop perfectly happily.

But if they’re using a company laptop, it can be very hard to get those same tools made available because they all expose a certain amount of security risk. Most corporate laptop builds are set up for the average manager or office user using a very minimal set of tools.

You therefore end up with vendors having a significantly better development configuration on their company machines than the internal staff members.

And because the vendors continue to do the work successfully, it is never really exposed to the security teams that there is a wider need for all these exemptions. So few internal people need them that the problem stays small. The majority of the development is being done by vendors, while the few internal people doing the same work end up fighting security for extended periods because there are only one or two of them asking for these rights.

Sounds like a small issue. Everything’s working. You’re delivering everything. There’s only a couple of people being inconvenienced. What’s the problem?

The problem is that you’re saving a bit of a bomb for the future.

You’ve now got a situation where your vendor can do things your internal people can’t. There is no proper exit plan for vendors, or for swapping vendors, because they’re using a whole set of tools and third-party items that your internal people not only don’t know about, but couldn’t use even if they wanted to.

And if you try to enforce on the vendors the same limited tools that are allowed internally, delivery plummets. Things don’t get deployed. Code doesn’t get written. So everyone backs out of that idea very quietly but very quickly, whether formally or not.

It means that if you have to change vendor, there will be a period of time where you are completely hamstrung when it comes to actual delivery and continuation of the work.

So, what’s the fix?

It’s well known and obvious…

You have a developer profile for company laptops.

Unfortunately this tends to involve quite a lot of effort to get set up and working, and, as already said, only a few people will initially be using it. Therefore, in this world of tough budgets, it gets put to the back of the queue and never really gets done.

So I advise either work out a standard set of tools that everyone adheres to and talk with your security teams about enabling them generally, or build a proper developer profile.

If you don’t, it will bite you sooner or later.

Corporate term: “Hero Scale”

Definition

If someone is hero scale, it means they are genuinely above and beyond the average. But it has extra connotations…

Explanation

There is a subset of people who will always, in a given situation, do better than average. You see it in all environments: sports, work, everything. But for many people, the reason they do better is because of built-in advantages. They got a high-paying job because they knew somebody. They were brilliant at singing because they had singing lessons as a child. All those kinds of things. And to their credit they don’t realise they have these advantages. But if you call someone “hero scale”, that means they genuinely are better. They are better than other people regardless of any advantage or disadvantage they might have started with. So, someone who is in a field dominated by one gender, but still rises to the top, is hero scale because they have done it despite the disadvantages. They are themselves worthy of being a hero. These are people to watch out for and work with because they genuinely know how to try, and they are good people to be with and learn from.
 
End note The phrase “hero scale” comes from tabletop wargaming. A six-foot-tall individual represented as a scale model in tabletop wargaming might be around 28 millimetres high, but for the sake of making important characters stand out when you’re playing, heroes tend to be closer to 32 millimetres high. They are hero scale.  
 
Disclaimer: As always these posts are not aimed at anyone client or employer and are just my personal observations over a lifetime of dealing with both management and frontline associates.

Doubled-up finance terms

One of those little things that you hear all the time, particularly if you work anywhere near contracts, finance or lawyers, are phrases such as:

  • “Null and void.”
  • “Will and testament.”
  • “Goods and chattels.”
  • “Breaking and entering.”
  • “Fit and proper.”

I see them all the time because of all the finance datamapping I do in insurance, but where do they actually come from?

Well, as with quite a lot of weird things in Britain, you can blame 1066.

After the Norman Conquest, England ended up with a slightly odd language problem. Most ordinary people continued to speak English, while the new ruling classes spoke Norman French, and a lot of official and legal writing was done in Latin. English law therefore spent centuries operating with English, French and Latin rubbing shoulders with each other.

One solution was wonderfully practical: use both words.

So rather than risk somebody not understanding the technical French or Latin term, lawyers would pair it with an English equivalent, or with another commonly understood term.

For example, “goods and chattels” combines the English “goods” with the French-derived “chattels”. “Will and testament” combines the Old English “will” with the Latin-derived “testament”.

“Null and void” is slightly different, and is a nice example of why the history is more complicated than simply English word + French word. “Null” comes from Latin, while “void” came through French. So it is still a product of that multilingual legal world, just not quite the neat example I originally thought it was.

These are known as legal doublets, and occasionally you even get triplets: three words piled together to make absolutely, definitely, completely sure that nobody can complain they misunderstood you.

Nowadays the original language problem has mainly disappeared, but the phrases stayed.

In fact, legal reformers have pointed out that many of them are now basically redundant. Everybody understands what “chattels” means in the relevant legal context, so we no longer need “goods” sitting next to it as a translation. But lawyers are understandably reluctant to remove wording that has survived hundreds of years of court cases and is universally understood.

Which is why, nearly a thousand years after William the Conqueror turned up, I’m still looking at a modern-day insurance contract completed on the web and seeing “Null and void” as a status option.