Category Archives: Technology

The One Big Benefit Of NOT Going AI …

You don’t have to worry about your AI vendor going toes-up when power costs go through the roof and your AI vendor can no longer charge pennies for compute when its costs rapidly become dollars and it can’t pass them on due to contractual commitments to existing clients (or to new clients who won’t pay dollars for computations that might return hallucinations).

The new generation of AI tech — Gen-AI LLMs / AGI — requires way more compute power than the last generation, 100 to 10000 times more on average, for most requests. Grids are stretched and beginning to break. We’re at the point where only nuclear can power the data centre needed for a modern Gen-AI/AGI offering. And, as per Koray Köse’s recent article on AI leadership is about who controls the power, U.S. nuclear plants operated at 92.3% capacity last year. OUCH!

THERE IS NO ENERGY LEFT!

You can’t build a new nuclear plant overnight — if you can even build one at all anymore! Last year, DOGE’s Firing Fiasco at the NNSA stretched an already stretched organization even more. Many returned to work, but not all, but budget cuts likely left them without the capacity to even properly monitor existing aging nuclear infrastructure, yet alone approve more plants.

And it’s not even clear how much know-how is left in the US to build new plants. The Vogtle Units 3 and 4 in Georgia were the first units built from scratch in over three decades. The experience and expertise isn’t there to safely build these plants en-masse.

And the last thing the US wants to risk is another meltdown. Three Mile Island wasn’t a Chernobyl, but all it takes is a rushed private sector job with a lack of proper oversight and testing and one small mistake to trigger the next meltdown on US soil.

In other words, the power isn’t there for more AI.

So those organizations that can do without modern AI, that can use classic solutions with fit-for-purpose last generation AI that requires a fraction of the power and can run on already strained, non-nuclear, grids will be the big winners when the power squeeze hits and the Big AI players start dropping like flies.

AI is Exacerbating the Need for Global Data Centres NOT Controlled By US Firms!

A recent post by Joël Collin-Demers on why Your LLM Doesn’t Need a US Passport pointed out two very important facts that you’re probably not aware of but should be:

1. Your company is feeding sensitive data to US-based LLMs every single day.

2. The US CLOUD Act lets American authorities demand data from any US-based provider REGARDLESS of where their servers sit in the world!

In other words, you’re giving the USA full access to all of your proprietary and confidential data anytime they want it — in full breach of your data localization laws if you’re NOT in the US and in a country with such laws (and if you’re not in the US and don’t yet have data localization laws to adhere to you will soon have such laws to deal with as a result of the US global over-reach for your data to feed its AI).

This is not just an AI problem (which, if you think you really need, you have other non-US options if you are not a US company as per Joel’s extensive list), it’s an overall SaaS/SaS problem. If you’re not a US company, you need to make sure that not only your data, but all of your applications (including, but not limited to, AI) are hosted in non-US owned data centres off of US soil without safe harbour agreements.

This Should Be Obvious But Expert in the Loop …

… is Human in the Loop. Not another (AI) system in the loop, no matter how specialized that system is or how well it is trained!

The future is Augmented Intelligence, NOT Artificial Intelligence (which doesn’t exist and won’t exist any time soon until brilliant researchers come up with a few more insights that get us closer to understanding

  1. what intelligence actually is and
  2. modelling it.)

The algorithms might be getting more accurate in average use cases, but the illusion of intelligence, no matter how grand, is still NOT intelligence. (And, even worse, The Wizard of Oz has been replaced by a very poor digital facsimile.)

Done right, Augmented Intelligence will still let your organization reduce its non-value-add tactical workforce by 80% to 90% because the right tools will enable the strategic experts to be 3, 5, 7, and even 10 times as productive and oversee all the tactical work that needs to be done using an exception based approach where every instruction that is given forms a rule that allows the system to automatically deal with the same, and similar, exceptions should they arise again in the future in a predictable and repeatable fashion.

Instead of having to oversee a team of tactical grunts that just take up space (because they don’t have the education, experience, or raw capability required to make good strategic decisions, manage projects, and identify value), a strategic expert can instead focus her time on value-centric activities and training a protege or two who will be one that posses the right mix of EQ and TQ to grow into, and take over, her expert role (when she moves on and up).

In the near future, there will be no more bodies in seats just to push bits around, because that’s what software does best. Number crunching and thunking. NOT analyzing strategically and thinking. (I admit most humans don’t do that well either, especially these days, because they are too attracted to the principle of least action and/or enjoying the cognitive decline from ChatGPT, but those willing to practice strategic thinking daily still do it way better than a machine ever will based on our current approaches to AI). [And while there might be fewer of us each year that are willing to think, there are still enough of us to get the job done if you let us select tools that work. Not necessarily AI. Tools that work.]

You CAN Afford to Wait for AI. But you can’t afford to wait to

  • get your data under control
  • build an infrastructure to allow for greater connectivity between apps within your enterprise and its greater ecosystem
  • update your processes
  • acquire and train the right talent with the knowledge they need to compete in the modern world
  • get digital and implement modern, current, generation technology based on best practices, proven (A)RPA ([Adaptive] Robotic Process Automation), and last-gen “AI” tech like optimization, predictive analytics (based on clustering and curve fitting), and point based neural networks with proven reliability and mathematically understood confidence where those apps are needed (and not a Gormless AI)

The reality is that you have to operate as lean and mean as possible. And

  • without good data, you can’t make good decisions
  • without good connectivity, you’re manually re-entering data across systems or missing critical external data you need to make good decisions
  • without good processes, you are inefficient and if not already, about to be circling the drain
  • without good talent, you are running on fumes at best, your ability to compete is at risk, and you can never improve
  • without modern tech, you are at a continual disadvantage and will continually fall behind

So you can’t wait to

  • institute Master Data Management (MDM)
  • enforce Open APIs in your solutions and acquire integration and orchestration solutions
  • review and modernize your processes where necessary
  • focus on acquiring, train, and retaining top talent
  • modernizing your tech to CURRENT generation proven tech, not experimental HYPE tech

BUT YOU CAN WAIT ON “GEN-AI“. It’s about getting the job done as efficiently and effectively as possible … with a low error rate and no significant risk! 99 times out of 100, you don’t need experimental “AI” to do that. Only the investors who spent millions/billions/trillionsw on unproven tech and the consultancies who need massive projects to employe bodies do … but that’s not to help you. That’s to recoup their wasted dollars. And that’s NOT your problem.

Building a Good Solution ABSOLUTELY Requires a Good RoadMap

A few weeks ago we tackled the subject of How Does a Vendor Build a GOOD Solution? and outlined seven key steps. SI received some feedback, and most of it revolved around the roadmap and how it should only look three months out!

So we have to address this insanity!

First of all, name ONE great or revolutionary technological invention that was invented with three months effort. You can’t, because there isn’t one.

Now name ONE great piece of software that solves a significant business problem that no other system that came before solved that was invented with three months effort. You can’t, because there isn’t one.

Now name ONE Billion dollar enterprise software platform that went to market with an MVP in 3 months that became a powerhouse that a large swath of businesses are using. You can’t, because there isn’t one.

All you can do in three months is a crap an app that is a piece of crap. Now, you might be able to make a big splash on the app store or in the consumer shareware market, but enterprise software is a complex piece of enterprise technology that requires years of development … and years of planning!

Secondly, remember what a roadmap actually is. It’s a graphical document that shows all of the roads you have available to you, how fast you can travel down them, and where they will take you. It’s not a detailed travel plan!

Similarly, in technology, a roadmap lists out all the things you would like to do, what it might take to get there, and what options could take you there. It is NOT a detailed functional specification or a development plan for the next three to five years (which should be the length of time you should be thinking through). (Also remember that, historically, great inventions came from research labs where the researchers were thinking three, five, and even ten years out and had years to develop groundbreaking developments!)

There are a number of reasons you need to be thinking three years out (even if your plans completely change nine months in), but the most critical reason is this:

If you plan for three months, or go for speed over quality (assuming you can always fix it later) your teams take shortcuts, build crap infrastructure, and add technical debt faster than you can ever eliminate it! (It’s almost as bad as vibe coding your way to an MVP, and then realizing you can never support an enterprise stack on it and have to go back and rebuild it from the bottom up after you’ve wasted months of effort and tens of thousands (or more) on AI credits. (Alex Turnbull gives a good summary in this LinkedIn post.)

When you start thinking about where your enterprise application might need to go, even if you choose not to go in that direction, you understand what processes you will eventually need to support and how you will need to build the foundational data model, workflow and orchestration engine, integration capabilities, internationalization support, and other core foundational features to either build that out or integrate that capability in the future. You’ll have a better idea of what you’ll need in the stack, what you’ll need for the platform, and what the best development environments for your team will be. (Having to change out any of these is very time consuming and expensive should you make a mistake early on.)

For (an easily understood) example, if you think invoice processing sucks (because you only looked at three vendors as you are too clueless to do market research, like many vendors that started during COVID because they all of a sudden realized that the business back-office should be capable of running 100% online, distributed, and remote), what else are you likely going to do after that. (Unless you’re a world leader in invoice processing technology, no one is going to buy just that!) In other words, are you going to support invoice analysis and predictive payment analytics, payment platform integration, contract and PO data extraction and matching, enhanced procurement (platform) support, etc. All of these capabilities will dictate data model, orchestration, and stack requirements.

Again, the point is not to plan out a detailed release schedule, but understand where your customers might ask you to go, where you want to go, where you want to hire a guide (to provide you with the expertise you need), and where you might want to hire a service to take your customers there (because a certain capability is best done by a specialist). This, along with constant monitoring of customer functionality uptake, customer feedback, and user forums will give you the complete picture you need to create the high level development plan for the year and the detailed functional specification for the final release of the next quarter (which might be built incrementally using agile methodology).

To put this in terms non-technical people will understand, you can’t build a twenty-story high-rise on a foundation for a two-story house. By thinking ahead, you’re building a solid foundation, and when you start building, you’re building the frame for the twenty-story high-rise that you can then build out and complete floor-by-floor once you know what the tenants you are signing on want on their floor.

By thinking at a high level years into the future, you are visualizing how you are going to fit into and evolve with the organizational ecosystem you want to sell into, and you are making good architectural decisions as you will be able to build that understanding of what you’ll need to support!

Moreover, as one commenter pointed out, and we noted above, watching how users work with the system is key! That not only helps you understand the depth and configurability of workflow process management required, the breadth of the data models that will be needed, and what systems they will want interfaces to (based on what they use before and after), but how to design a good UX based on now they work and what they are adopting! (It should be noted that designing a good UX, including a good UI, can be harder than the model and controller algorithms — which, if you need advanced analytics, optimization, and higher performance, might take a PhD to get right — because it doesn’t matter how good the application core is if no one uses it!)

Roadmaps are key. That’s how your Chief Software Architect and Chief Technology Officer build great applications. It ensures that once you select a destination, they know the route they have to navigate to get there!