For Digital Transformation to be worthwhile, it needs to be sustainable. By engaging everything and everyone with low-code business apps that listen and adapt and trigger reactions and responses throughout your enterprise, you’ll transform your business into a self-sustaining digital ecosystem.For Digital Transformation to be worthwhile, it needs to be sustainable. Click To Tweet
The Digital Ripple Effect
Drop a pebble in a pond and the ripples reach every shore. Some of them will bounce off objects in the pond—rocks, stumps, etc.—and emanate in other directions. This ripple effect results from natural forces at work in natural ecosystems. The same phenomenon should occur in highly evolved business organizations: events logged in one system or application should trigger effects in others—status changes, process updates, notifications, and so on.
What we’re describing, here, is a step beyond software-driven everything, beyond garden-variety digital transformation, and far beyond wherever you can get by simply “building apps fast.” We’re, in fact, talking about the transformation of an enterprise into a digital ecosystem, a place where a butterfly can flap its wings in one division and the effects can be felt half-way around the world in another, and in real time.
Here are a few examples:
Marking a Salesforce® opportunity as closed should triggerthe beginning of the fulfillment cycle, the processing of an invoice, and inventory-related transactions and processes, any and all of which could involve other systems.
A digital signature on a contract should trigger a notification in Salesforce® for the account manager.
Changes in Salesforce® for Sales Forecast should cascade down to your ERP system, initiating supply chain modifications and manufacturing scheduling.
Now imagine thousands of events happening simultaneously, each emanating and affecting other processes and triggering additional events. That’s a true digital ecosystem, and it’s what all enterprises need to shoot for, and fast.Now imagine thousands of events happening simultaneously, each emanating and affecting other processes and triggering additional events. Click To Tweet
Digital Darwinism and the Need to Transform Now
Ray Wang, founder of Constellation Research and author of the book “Disrupting Digital Business: Create an Authentic Experience in the Peer-to-Peer Economy” (2015), points out the perils to those who fail to act fast:
. . . the impact is significant and now quantifiable with 52 per cent of the Fortune 500 gone since 2000 and the average age of the S&P 500 company in 1960 down from 60 years to a little more than 12 projected in 2020. That is a 500 per cent compression that has changed the market landscape forever in almost every industry. Basically, Digital Darwinism is unkind to those who wait. In fact, you will be out of business if you wait.Basically, Digital Darwinism is unkind to those who wait. In fact, you will be out of business if you wait. Click To Tweet
Getting from Here to There
Transforming your organization from what it is now to the highly evolved state that we’re defining will require a profound shift in software development paradigms. An exponential increase in application development and delivery (AD&D) will be required, and, perhaps more importantly, the mass of resulting applications will need to be self-adaptive to continual changes in business rules and technical requirements.the mass of resulting applications will need to be self-adaptive to continual changes in business rules and technical requirements. Click To Tweet
Agile in its various flavors is too slow and resource intensive for the world we’re envisioning, requiring senior software engineers to build the applications and create the deep inter-dependencies that would need to exist. Furthermore, the entire process of designing, coding, compiling, linking and executing is cumbersome, yielding applications that are too rigid in their feature sets and which would become legacy the day they were deployed, requiring constant maintenance throughout their useful lives. Put another way, they would end up on the debt side of an enterprise’s technical balance sheet.
Low-Code—But not Just any Low-Code—as a Vehicle
Low-Code development platforms are one of the IT industry’s hottest software sectors, and for good reason: Using such a platform, enterprises can build simple forms and workflows on up to custom line-of-business systems as much as ten times faster than they could using an Agile approach.
But many low-code platforms work on the principle of code generation. In other words, such systems use a drag-drop-and-configure approach to building application models but, then, run the model through a code generator, which converts it to low-level computer code. This code must then be compiled, linked, and executed. In the end, you end up with just as much code as you would have gotten using Agile; you just generated it faster.Using Low Code, enterprises can build apps ten times faster than they could using an Agile approach. Click To Tweet
Potential Problems with Code Generation
Depending on your goals, a code-generation-based low-code platform may fit the bill—simple (even complex) apps that don’t need to continuously adapt to ecosystem fluctuations. But the essence of digital ecosystems—numberless ripples emanating throughout an organization, triggering, updating, notifying, and so on, 24/7/365—requires that the avalanche of apps that make it all work can’t require constant maintenance, which would be a deal breaker. The code-gen approach will likely yield apps that have the same rigid, baked-in characteristics as hand-coded apps, meaning they can’t responsively adapt to ecosystem changes. Put another way, they will require never ending maintenance.
Responsive Low-Code PlatformsThe alternative to code-gen-based systems is responsive low-code platforms Click To Tweet
The alternative to code-gen-based systems is responsive low-code platforms, which may be architected any number of different ways but need to yield the same result: cross platform, cross environment, cross cloud apps of any complexity that can be built fast by someone other than experienced software developers and—here’s the key—can responsively adapt to evolving ecosystem requirements.
What’s needed, then, to catalyze digital transformation 2.0 (a true digital ecosystem) is a new software development paradigm, one that satisfies the quantity problem (lots of apps delivered fast) as well as the responsive problem—software that can dynamically respond to the constantly changing conditions. Responsive is, of course, the hard part, but also the critical part.Responsive is, of course, the hard part, but also the critical part. Click To Tweet
One low-code platform that has a responsive application architecture is AgilePoint NX, which can be used to highlight requisite platform characteristics for true digital evolution.
Model-Driven VS. Code Generation
In contrast to code-gen-based platforms, AgilePoint NX incorporates a true, model-driven architecture. With this approach, each component of a visual model constitutes metadata (stored in an XML registry) that defines how an underlying chunk of code will work. For example, as a developer drags an activity into a model, the relative positioning of the activity to other model components constitutes metadata, and this metadata affects the underlying code. If a developer changes the relative positioning of a component to other components, the underlying code, in turn, gets modified to reflect the change.
Likewise, any operational characteristics provided by the developer (configurations typed into dialog windows) along with flow lines between components constitute metadata, and all of it, taken in totality, is abstracted into application features and functionality.flow lines between components constitute metadata and are abstracted into application features and functionality. Click To Tweet
XML-Based Process Engine
As was mentioned above, with AgilePoint NX, the application model, itself, is XML. In execution, the model (XML registry file) is fed directly into the process engine. Note that, in contrast to traditional compiled apps, which must be fed into a process engine in their entirety, an AgilePoint XML-based model can be processed one component at a time. This piece-by-piece approach reduces storage and processing requirements, but, more importantly, enables components not currently in memory to undergo modifications. Regardless of the circumstances, any part of a model is in memory only while it’s in use (for a fraction of a second at a time) and then is removed. And once a component is no longer in memory, it can be modified.
A model-driven architecture combined with an XML-based process engine results in apps that can be modified at runtime as new ecosystem conditions arise. This results in data that is pushed into the model, causing the underlying code to be modified, and the running application changes mid flight. Depending on the application in question, updates to components could be made manually—a system admin or, perhaps, a line manager, entering data into component dialogs. But with digital-ecosystem apps, modifications are more likely to be made programmatically, via feedback loops of fresh data from any of millions of devices or systems.
Continuously Variable Applications (CVAs)
If you’ve ever pulled a trailer up a steep mountain grade, you may have experienced your vehicle repeatedly shifting back and forth between gears in an attempt to find a ratio that is appropriate for constantly changing requirements. One gear is too low, the other is too high. In contrast, continuously variable transmissions (CVTs) offer infinite gearing ratios, enabling a transmission, based on external data sources, to deliver the optimal ratio at all times during the climb. Needless to say, the CVT approach is way better allowing your engine to run at the most efficient rpm.
In some ways, the difference between a five-speed automatic transmission and a CVT can be likened to the difference between baked apps and responsive (continuously variable) apps. Baked apps offer a predefined set of options to handle various conditions, but when actual conditions vary from expected scenarios, the necessary permutations are not available. The app can be taken offline and modified to account for new conditions (think adding a couple of extra ratios to a transmission) but the same problem still exists—the machinery of adaption is not well suited to an evolving digital ecosystem.
In contrast, responsive apps are architected in such a way that they dynamically reconfigure on the fly to account for any number of changing business conditions and technical requirements, much the way a continuously variable transmission can generate any gearing ratio necessary to account for hundreds of external factors.
Just as CVTs are way better than regular transmissions, responsive apps are way better than baked apps, especially when it comes to the requirements of Digital Transformation 2.0. Regardless of whether you think you need a responsive platform, in the long-term you might, and, given that apps can be built just as fast and by people with the same level of technical training as code-gen-based apps, there’s no reason not to play it safe when it comes to potential, long-term requirements.
Regardless of the architecture that is used, software that is capable of functioning within the contextual rigors of a full-blown digital ecosystem must be able to adapt to fluctuations without recompilation and the baggage that goes along with it. AgilePoint NX utilizes a mode-driven architecture, a metadata abstraction layer, and a stateless process engine to get the desired results. Other platform vendors may get a similar result utilizing a different architectural design but unlike the CVT approach they’re not running the engine optimally.AgilePoint NX utilizes a mode-driven architecture, a metadata abstraction layer, and a stateless process engine Click To Tweet