The pendulum swings again

I remember working for a large government organisation where the procurement officers had won. Their blanket rule was literally "SAP unless". They would rather pay (a lot to) consultants to build something custom in SAP than to have another product complicating their procurement life.

In my neck of the woods (XML document processing), this model never really worked. It was a little bit too niche for large vendors to step up their offerings. At the same time, generic products from vendors like Microsoft didn't work either (good luck doing XML in SharePoint). The end result was generally a witches' brew. Lots of little scripts that were hard to maintain. Sometimes custom software written in environments that were not really suitable. For example, I've seen workflow systems for XML production that used tools that were not Unicode-native. This was asking for trouble, and trouble is what they got.

Still, there was always pressure to "buy before build". Building was considered risky. Software is notoriously difficult to estimate. Capable staff can walk away to competitors. Maintenance can be costly when underlying components are upgraded by vendors working on their own schedule. If you buy, you can at least manage the contract. Even though it was clear from the start that vendors would try to scam you, it was considered a lesser evil.

We might have to reevaluate that bargain.

Of course, the reason is the radical improvement of AI over the last two years. Even if all AI development were to grind to a halt tomorrow, the current capabilities are already so good that it will have a massive impact. If you read in the news that a team of two can now do in weeks what a team of ten used to do in months, you better believe it is true. Because it is true for 90% of all enterprise ICT systems. There are always Amazons and Spotifys but the average organisation is really not that special in terms of volume or business logic.

The AI benefits directly attack the reasons why building was risky. If AI generates code more or less on the fly, a large part of the estimation problem is gone. Of course, we still need to do the hard work in specifying and designing, but we needed to do that anyway for a vendor/product selection. AI also completely upends the walkaway problem. Deep knowledge is no longer the result of years of experience. The infamous steep learning curve is gone. If the only knowledgeable employee walks away, odds are you can train a replacement. And finally, AI can keep track of integration and security issues. As a matter of fact, this is probably something you cannot afford not to do. With all the zero-day exploits coming up, you need to be running to stand still and using AI is the only way to do that.

So if build is back on the table, what does this look like now? It doesn't mean "just do it". We don't want to end up with vibe-coded slop that doesn't scale and that needs an ever increasingly advanced AI model to even modify it. Two things stand out: a proper foundation and a proper design.

To start with the latter: 90% of the work should be spent on designing a business process and the required tooling to support it. This should have been the case before, but now it is even more critical because a good design translates directly into good software. The aim is a 100% fit. Not too much, not too little, goldilocks. Why buy a tool that scales to 100s of employees when you only need 20 seats? Why settle for a tool that only covers 80% of your needs and has a crappy interface? You're no longer hostage to a roadmap.

Once the design is worked out, a small team should generate an end-to-end implementation. Not a prototype, but a real system. Only when this turns out to be too difficult should you buy something. Or probably go back to the requirements and make it a little bit more realistic. The odds of your organisation buying something off-the-shelf that cannot be implemented by an AI are getting lower by the day.

The other thing is the foundation. This is more than just selecting a database. It is things like identifier schemes, security strategy, compartmentalisation, etc. In the new AI world, functionality is effectively free. But some functionality has long-term implications, especially if it is shared between systems. Classic bangers from the XML document world are using normal file systems for storage and then finding out that files are overwritten or renamed. The foundation should solve this once and for all.

XML document processing can be one of the biggest beneficiaries of this paradigm change. If we can generate functionality at low cost, then any XML content project should have its own custom environment. There will be best practices, especially at the foundational level, but a lot of the system integration cost and environmental variation will be handled by AI. If something doesn't work, it can be changed in hours rather than weeks, if ever. The focus will shift to improving the data - the XML documents - instead of wasting time on barely functioning tools. This is in many ways a dream come true, because XML was always about the content.