Has there ever been a time when we’ve challenged the ever-increasing stranglehold enterprise applications and their codebase have been inflicting on us for decades? Where each version upgrade requires more and more code to be rewritten just to keep everything working; where we’re subjected to aging developers holding us to ransom for their dated programming languages. Because they can.
Where it just takes bloody ages to get anything done because our enterprise technology just sucks and these cloud migrations are a big mess. And where both our personal and professional lives are beset by the constant inability of applications to talk to each other, to validate who the hell we are every day, to keep upping their subscription fees… Because they can.
Well maybe they won’t for much longer as the sheer energy behind this move to generative solutions takes hold, and the desire to drive actions to bypass bad antiquated technology overwhelms the old ways of doing things. So who better to speak his mind after a lifetime grappling with technological stranglehold than our new Chief Technology Evangelist, Francis Carden…
Our future is all about visible actions and invisible technology
After a remarkable journey through the era of computerization and its remarkable contributions, we stand at a pivotal moment of innovation. It’s time to bid farewell to a core element that has been instrumental in its success: We must undertake a comprehensive reevaluation of our enterprise application suites and the ecosystem of coding that has been central to their development and support.
Our reliance on codifying applications suffocates innovation
Something hit me in the face when I recently heard that we were going to start using AI to write code. My first thought was that this is BS. Writing code was never really the problem at the creation stage of each software application! Because even if the business and IT requirements were always in total alignment to codify great applications, it was really the next 10,20, or even 30 years of supporting this “software” through coding hacks that created the slow strangulation towards legacy debt and accelerating cost of ownership. These mammoth costs and constraints stalled so many enterprise innovations and dare I say, will continue to stifle our ability to embrace the new transformative shift in technology with AI if we stay on this course. We must stop thinking about coding the old way.
The new focus is on ACTIONS, not applications
Enter the new world of Large Action Libraries (LALs) where ACTIONS are the true makeup of all future business processes and application needs. Easily understandable and digestible, ACTIONS can be consolidated into Large Action Models (LAMs) that become consistent and flexible interconnected assets to meet any current or future business, or IT need rapidly. ACTIONS are key and can still be built by programmers in code, but more and more likely, by citizen developments using lowcode and nocode. Software will now be constructed, not coded.
This concept of ACTIONS, LALs and LAMs is not new because we’ve dreamed of being able to do this since the first program became a callable “subroutine”! But until more recently, we have never had the technology to do this properly. The dream of modular, reusable code through ACTIONS, LALs, and LAMs, once constrained by hardware limitations, is now achievable and transformative due to the exponential growth in computing power and cloud infrastructure, mirroring the AI revolution’s leap from theoretical to practical, game-changing applications.
A world without code frees us to innovate with technology at a speed we’ve never experienced
Picture reducing the ongoing costs of supporting apps written with code for our users, consumers, and partners to a mere fraction of what we’ve accepted as normal since the start of the computing era. Envision being able to near instantaneously create, modify or improve any process or task for governance, competitive advantage, or even just aesthetic purposes. These goals can now be achieved without adding another gazillion lines of code to each “app”, which only serves to spaghettify our already complex business logic nestled within. Instead, we can adopt a revolutionary approach that simplifies our software implementations, permanently.
I can now foresee where service providers will provide prebuilt actions of public or private LAL’s and even host and execute LAM’s themselves as well (think Microservices around the most common business rulesets across all common horizontals and verticals. I mean, why are there 10,000 different codified versions of a US driving license validation when one would suffice across all enterprises? This license validation process may thus be created as a LAM, available to some or all, and each consisting of ACTIONS chosen from the LAL’s. Your enterprise was never better because it has the best driving license validation, it’s just more expensive to run! This quagmire of coded software is duplicated within and across millions of tasks and processes today. Each unnecessarily exists in isolation, duplicated many times over, in each and every enterprise!
The world of enterprise applications we have built no longer makes sense in the GenAI era.
To be clear, most enterprise applications still in use today were written logically (often illogically) to make data calls (transactions and APIs), describe the business logic (rules, coding, subroutines, functions), along with the conditions and branches to determine the correct order to run. Combine all that with the multi-denominations of user interfaces, squirrely logic at each layer, most likely too, encased with many modified duplicates of all the same coded capabilities, from the back end to the front end and everything in between. And there we have it, the birth (and hostage) of the legacy systems. This huge but impossible-to-measure TCO (Total Cost of Ownership) keeps being piled on just to “keep the lights on” with no end in sight except more risk, more downtime, and stifling the business needs to innovate and lead. This is our “enterprise apps”, with old school code.
A little side history lesson: Before “apps,” users would simply log in to access a “system” or “run a program.” But when we started building richer UIs, we suddenly felt the urge to lump it all together and coined the phrase “apps,” a term that has stayed ever since.
Is there a NoAPP for that?
In reality today, primarily outside of the enterprise, we have turned full circle as consumers may only just consider apps, an “app”, when they download something first (often from an app store!). Is the browser itself an app or a browser? Is Facebook running in a browser an app or is it only an app when it’s running ON a phone? There’s an app for everything – but is there really? With ACTIONS, LAMS and LALs, perhaps nothing is really an application until it’s consumed and presented with a UI. The introduction of NoAPPS software? Food for thought.
Successful LAMs will pave a sustainable path for the future of technology
LAMs could even be construed to represent the renewable energy revolution within the software development industry. Just as the shift to renewables offers a path away from the harmful emissions that threaten our planet, LAMS (NoAPPS) promises to move us beyond these ‘Legacy Gases’; the outdated, inefficient duplicated practices that suffocate innovation and progress within our field. This approach not only mitigates the risk of internal stagnation but also revitalizes our industry by reducing the dependency on cumbersome and polluting legacy systems. By embracing ACTIONS, LALs and LAMs, in a NoAPP era, we are choosing a sustainable future, one where software “development” is cleaner, more efficient, and infinitely more adaptable—ushering in a time where our industry’s growth is no longer at odds with the health of its ecosystem. See what we did there? Green NoAPPS? But it’s important, because our current legacy systems are beyond recyclable, though our future ones don’t have to be!
Why have we not really achieved this before? For sure we tried! 3GL’s, 4GLS, lowcode/nocode, Rapid Application Development tools and model application development. And even, dare I say it, object-oriented programming to drive reuse! But to be fair, all of these great concepts were often long before their time, constrained by memory limits, CPU power, storage and networking bandwidths to name a few. Our coding became atrocious, through no fault on any individual, but by the desire to not get left behind. so we are out of excuses for the new future of software. This is why we need to rebrand software development that can easily adapt to any current or future desired outcome. Hooray for NoApps and LAMS consuming ACTIONS from libraries to create the sustainable autonomous enterprise and the dream of the OneOffice.
Setting standards for the NoApps revolution
The first part of this new paradigm is to capture any process and task detail in some form, into an agreed standard, albeit a new open standard or unique to you (thought I don’t encourage the latter). You also need to capture the variations and the rules (separately). No programming or tech speak necessary unless you want it (because you will always want it easily explainable!). Once captured, in whatever form we desire, with all of the variations and business rules, they will be consuming, ready for translation into ANY desired execution format, even code. Remember, these ACTIONS, that go into the Library (LALs) can be small (the execution of the simplest of tasks), or grouped into LAMs for more complex needs. These actions and the models they are consumed by, will always be the core of what you need for your business to run and evolve, albeit for true end to end execution or an app. Apps are born of the NOAPPS description, only if required, not the other way around.
In this methodology, you actually do not even need to know how ACTION descriptions will be consumed. Will they be used by an application? An API? An AI call? It doesn’t matter yet because these things don’t change based on the use, that’s where we went with legacy coding. Each action would 100% describe what needs to be done, and can even run and be tested standalone in many cases. And cleverly, when something that already exists, is detected (by AI), it will be reported and attempt to force the reuse (or logically split into multiple inheritable actions)! The goal must be to never have two copies of the action, model or rule but rather, now it should be added to the broader library for the business to consume, and now, with AI, automatically. Actions will tracked as to where they reside and run (think always on mining here). When a change is made to a now encapsulated ACTION or LAM, process, or task, it can transition easily upstream to live, post-testing.
What about the database and what about the UX I hear you ask. They are irrelevant for the implementation of NoAPPS going forward. ACTIONS and ACTION MODELS should no longer be tied or locked into either. You will regret it. We are not living in the 80’s where indexing and storage sacrifices were mandatory before software design! Standard for the consumption and runtime executables will be encryption, roll-forward, roll-back, transaction reliance, smart locking, reporting et al. Just as with the cloud, so many upstream guardrails become automatically inherited and trusted.
Bottom-line: Technology’s future is about driving actions that you define. You are the outcome, and the tech must be invisible
Some in IT, or even business, might argue that they need their own unique version of these ACTIONS, but I submit that they don’t.
They may need variations in rules and flows but to hard code them will become sacrilege. Most enterprises already use the same cloud vendor as their competitors, the same security and encryption as their competitors, and the same browser or mobile access device. Do you care which insurance company you use to cover your home and car? Probably not, you just need an action (when you need it) at a reasonable price. It’s becoming the same with technology… it is a means to an action, not the action itself.
The days of which one you choose giving you the competitive edge are dead. It’s irrelevant for most. And if this last holy grail of software and application development is where your business wants to hang its hat, then even if someone notices and applauds you for it, it might just very well be your most costly downfall.
Posted in : Artificial Intelligence, Automation, Buyers' Sourcing Best Practices, ChatGPT, GenAI, Large Action Models, Large Language Models (LLMs), Lowcode Nocode, OneOffice
