According to Forrester, there are two types of #AI. #PureAI and #PragmaticAI.
Click To Tweet

Elon Musk, Bill Gates, and Stephen Hawking—to name just a few—have all broached the subject of intelligent robots taking over. And it’s been a favorite topic of Hollywood for decades. Think back to the “Terminator” and “Matrix” franchises, and, more recently, movies such as “Ex Machina.”

A different Hollywood take on AI is the movie “Her,” which features a computer operating system (Samantha, voiced by Scarlett Johansson) so intelligent that it develops an emotional attachment to the movie’s protagonist, Theodore (played by Joaquin Phoenix). This take on AI ups the anti from militant, oppressive robotics to a much higher level of sophistication—human emotions.

The question is this: Will any of us live to see a Samantha-like operating system or a robotic dominance on planet Earth?

Forrester on AI

In a Forrester Research Podcast, “The Risks and Rewards of Artificial Intelligence,” Analysts Mike Gualtieri and TJ Keitt label the Hollywood vision of Artificial Intelligence as Pure AI. The two analysts mention that some researchers predict that “100 years from now, we have a 75% chance of having Pure AI.”  I was actually surprised by the immediacy of this estimate. It’s coming much faster than I thought.

“100 years from now, we have a 75% chance of having Pure AI.”
Click To Tweet

The two analysts point out that Pure AI is one of two major classifications of artificial intelligence. The other major division is Pragmatic AI, or the AI that is actually being developed and applied to real-world use cases.

Pragmatic AI

Gualtieri and Keitt delineate eight types of Pragmatic #AI. (note that they said “nine” in the podcast, but I counted only eight), which can be applied alone or in combination with other types of AI. The eight types are as follows:

Gualtieri and Keitt delineate eight types of Pragmatic #AI.
Click To Tweet

1. Deep learning (underlying technology in neural networks)
2. Machine learning (used to create predictive models. Gualtieri and Keitt mention that this type of AI is most useful for enterprise applications.)
3. Speech recognition
4. Image and video analysis
5. Sensory perception (In many cases, for AI to be “smart” it needs to have sensory input.)
6. Natural language understanding (NLU, which is used for contextual analysis.)
7. Natural language generation (NLG)
8. Robotics

Real-World Concerns with Pragmatic AI

It’s clear from the podcast that Gualtieri and Keitt consider that any AI—even the pragmatic variety—poses genuine social problems that need to be overcome. One of their big concerns is data bias. The fact is that, like actual intelligent beings, the artificial kind need to be taught how to think and behave. This training results from sample data sets being fed into the system, in fact training the system in the process.

any #AI—even #PragmaticAI—poses genuine social problems
Click To Tweet

An example the analysts use is facial recognition, which they say is inherently biased by training data sets. They highlight the fact that facial recognition systems designed in Asia are very good at identifying minute distinctions in facial features among Asians, which make up the large majority of test subjects used to train the system.  But the same systems tend to be less accurate for a non-Asian population.

The exact analog exists for systems built in North America, for example, where systems might be good at distinguishing one Caucasian face from another but not effective for ethnic minorities. The implications are profound and potentially catastrophic, especially in law-enforcement applications where inaccurate facial recognition could influence dire outcomes.

Data Bias Expanded

Gualtieri and Keitt expand on the data bias problem by pointing out that any AI system is likely to have the biases of its creators built into it—the natural result of the data chosen to train the system. For me, that’s perhaps the most telling point of all—that AI will be no more objective in predictions or conclusions that its human counterparts.

any AI system is likely to have the biases of its creators built into it
Click To Tweet

The post Will AI and Robotics spell the end of human dominance? Forrester Analysts say maybe–in a hundred years or so. appeared first on AgilePoint.

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…
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…
Click To Tweet

g

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…
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 Platforms

The 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…
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. 

Runtime Updates

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. 

Summary

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…
Click To Tweet

Save

Save

Save

Save

Save

Save

Save

Save

The post What is a Digital Ecosystem? Why Do You Need One? appeared first on AgilePoint.

Sustainable Digital Transformation is what enterprises must strive for.
Click To Tweet

Digital transformation is not only one of the biggest buzzwords or 2017, it also represents the biggest challenge that IT departments have faced in years. This reality exists for a number of reasons:

Mountains of Technical Debt—Mature organizations have, over the course of years, accrued virtual mountains of technical debt—legacy systems and applications that need to be modernized.

Technological Mish Mash—Organizations are using a combination of on-premises systems, private cloud systems, and public-cloud services, all of which must either be replaced or incorporated into a self-sustaining digital ecosystem;.

The Plateau Myth—Digital transformation isn’t merely a plateau to be reached, after which it can be forgotten about; rather, it’s a state of being where software, itself, must be intelligent enough to self-adapt to technical and business conditions. In other words, if organizations can’t easily sustain digital transformation in a business environment that evolves by the day, then whatever effort and money they invest in transformation might very well be wasted.

The Quantity Problem

Digital transformation—“software-driven everything,” by some definitions—will require exponentially more software development. Hand coding all of the requisite new apps would require a virtual army of engineers. And even if there were enough senior engineers to go around, the cost would be prohibitive.

Digital transformation will require exponentially more software development.
Click To Tweet

The Technical-Debt Problem

Beyond the availability and cost of software engineers, there are several other problems related to hand coded apps, which

• must be compiled, linked, and executed.
• tend to be rigid, brittle, and inherently incapable of adapting to the constantly changing conditions of today’s digital business environments.
• require continual maintenance throughout their useful lifespan.

It’s hand-coding custom apps and connections that led to organization technical debt to begin with. Hand codeing exponentially more custom software would just compound debt all the faster. Put another way, hand-coded apps are the antithesis of self-sustaining, software assets.

hand-coded apps are the antithesis of self-sustaining, software assets.
Click To Tweet

Traditional Low Code Is Part of the Answer

Clearly a new paradigm for application development is necessary, which is why Low-Code Development platforms have become a thing. Not only do sophisticated low-code platforms allow you to build anything from simple forms and workflows on up to composite line-of-business systems, they let you do it up to ten times faster than even the most Agile methodologies.

Low-Code Platforms let you build apps up to ten times faster than even the most Agile methodologies.
Click To Tweet

Furthermore, Low-Code platforms enable many types of apps to be built entirely without code. In other scenarios, the amount of code required to build and deploy an app is greatly reduced. This realty dramatically expands the pool of available development resources to include “citizen developers”—typically non-programmers with strong domain expertise and general computer skills.

Where Traditional Low Code Falls Short

#CitizenDevelopers” are typically non-programmers with strong domain expertise and general computer…
Click To Tweet

If there’s a problem with many Low-Code Platforms it’s that they don’t so much eliminate code as they hide it. In other words, many platforms utilize a code-generation approach, which takes the visual app model and converts into computer code. This code must then be compiled, linked, and executed, just like any hand-coded app would need to be. And the outcome is the same—brittle apps that won’t adapt to a changing environment.

Some Low-Code Platforms don’t so much eliminate code as they hide it.
Click To Tweet

In some scenarios, this sort of app might work fine. In others, though, brittle apps simply won’t result in sustainable digital transformation.

Responsive Low-Code Platforms

Responsive Low-Code Platforms utilize a true model-driven architecture, where model components are abstracted into XML and pushed directly into a stateless process engine. Responsive application models can be modified at runtime, either manually, by business analysts or process experts, or programmatically via feedback loops of fresh data originating from devices or other applications.

The result is apps that can self-adapt to the constantly changing conditions.

Responsive #LowCode Platforms result in apps that can self-adapt to continually changing conditions.
Click To Tweet

A Stable Bridge to the Cloud

elite, responsive platforms yield apps that run seamlessly across environments.
Click To Tweet

Furthermore, elite responsive platforms yield apps that run seamlessly across environments. This capability catalyzes digital transformation by creating an open bridge to the target state. Consider an organization that has an immediate pressing need—perhaps, it is running multiple SharePoint farms of different versions but wants to migrate all of them to Office 365. But this organization also has thousands of custom workflows that are locked into the various SharePoint versions, and these workflows may incorporate other systems, both on-premises-based and cloud services.

An elite, responsive platform would enable such an organization to replace these workflows with app models that would run on any version of SharePoint, including Office 365, as well as all of the other relevant systems.

And, these same apps would be inherently capable of self-adapting to all future versions of SharePoint. With workflows transformed into hybrid-ready application models, the organization could then push its various systems to the cloud on its own schedule.

These same apps would be inherently capable of self-adapting to all future versions of SharePoint.
Click To Tweet

Sustainable Digital Transformation

Authentic digital transformation requires software that can intelligently adapt to evolving conditions. To see this reality in specific relief, consider the alternative—an ever growing army of software engineers to continuously maintain exponentially more software than it is currently working with.

With intelligent, self-adaptive apps, an enterprise’s digital infrastructure becomes ecosystem like—capable of intelligently evolving based on manual or programmatic changes at runtime, neither of which require software engineers.

With intelligent, self-adaptive apps, an enterprise’s digital infrastructure becomes ecosystem like.
Click To Tweet

The post What Is Sustainable Digital Transformation? appeared first on AgilePoint.

A Tale of Two Returns

I recently bought a ceiling fan from a well known online vendor. Before it arrived, I ordered an extension rod, having concluded that I would need it in order to mount the fan on a sloped ceiling. When the fan arrived, I quickly figured out that I had ordered the wrong unit, primarily because the online catalogue didn’t make it clear which version I needed.

With this particular vendor, the automated return process required a written explanation of why I was sending the item back. I typed into the field provided, “The fan did not work for my intended purpose.”

When I clicked the submit button, I was informed that I would not be charged for return shipping and I was then given a UPS shipping label to print out, along with instructions for how to repackage, etc.

A day later, when the extension rod arrived, I went through the same automated process. When asked why I was returning the rod, I wrote “Having returned the ceiling fan, I no longer need the extension rod.” I was then informed that I would be charged $6 for return shipping and provided a shipping label etc.

Text Analytics Triggers Process

Clearly, this particular online vendor is using Text Analytics (TA) software—a form of Artificial Intelligence—to extrapolate a trigger from natural language to set an automated process in motion. Text Analytics software is able to analyze unstructured data—writing—and understand its meaning, at least, to some degree. My first return explanation (the fan) included the words “did not work,” which caused the TA engine to conclude the fan was somehow defective and, therefore, that I should not be charged for return shipping. My second explanation had no such language, causing the TA engine to conclude that I should be charged shipping.

While this vendor’s return process is a simple example, it, nonetheless, illustrates the convergence of artificial intelligence (AI) and business process (BPM), one of the hottest new areas for high-tech investments.

BPM and AI Deliver Escalating Efficiency

In a recent report (“Artificial Intelligence Revitalizes BPM . . .”–subscription required),  Forrester Research analyst, Rob Koplowitz points to this type of Artificial Intelligence (Natural Language Processing/Text Analytics) as one of the primary intersection points between AI and BPM.  Another such intersection involves machine learning, the ability of AI engines to assess the relative efficiencies of automated processes and to make recommendations for modifications to business logic and even processes, themselves, in an effort to continually escalate process efficiency:

Not surprisingly, many BPM vendors focus on AI as a means to reduce the complexity of tuning and optimizing the very processes the systems manage. While the idea of using analytics to monitor process execution is nothing new, AI can now take that a step further through the use of machine learning to provide guidance on optimization.

Applying AI to BPM (process efficiency) is definitely a step in the right direction, but real-time implementation of process modifications is the next frontier.

AgilePoint NX, the Responsive Application Platform

AgilePoint, a long-time player in the BPM industry and quick leader in the Low-Code space, is often billed as the “Responsive Application Platform,” a distinction resulting from a unique architecture that enables applications (automated processes) to adapt at runtime to changing business and technical conditions.

AgilePoint’s model-driven architecture an abstraction layer that translates model metadata in real time into functioning code, and a stateless process engine combine to yield this self adaptive capability. In regard to AI-driven process-efficiency analysis, rather than make recommendations to human developers, who must then refactor applications according to AI instructions, those same instructions can be fed directly into AgilePoint applications, which can adapt at run time to the continuous feed of process analysis.

The post Responsive Low-Code BPM Meets AI (Artificial Intelligence) appeared first on AgilePoint.

So impressive, in fact, is Salesforce® in its initial deployment, that customer-focused groups outside of Sales often want access.  Rymer’s presentation in the webinar included research published in a Forrester Research report (“Five Ways To Cut The Risk Of Going All In With A Salesforce Customer Platform”—subscription required). In this report, Rymer, et al, refer to this everyone-wants-in phenomenon:

. . . business leaders want to expand initial wins with Salesforce® CRM into customer and/or partner engagement, marketing automation, analytics, and more. New custom applications and customizations mushroom.

Scaling Salesforce®

It’s in this rapid-expansion stage where the wheels tend to come off. The Forrester report details an account of a government agency that encountered a scaling problem. After initial success with Salesforce®,

The agency quickly added about 12,000 Salesforce® seats in seven separate “Orgs” (accounts), lots of customizations, and many custom applications. As this expansion progressed, innovation on the agency’s core Salesforce® apps slowed to a crawl, and operating costs rose. Updates and changes to enterprise processes and existing apps were now sluggish, although the agency still could quickly stand up isolated new applications. “When you start adding custom code [to Salesforce®], you need developers to make changes,” says the agency’s CoE leader. “And Salesforce® becomes way more expensive to maintain.”

“Complexity of scale,” means innovation slows to a crawl and what was once flexible is now rigid. How so? According to Forrester’s team of researchers,

Every app change risks breaking one of hundreds of data and process customizations, integration links, and third-party add-ons. The result: Every change requires long and expensive impact-analysis and regression testing projects.

Forrester’s Proposed Solution to “Scaling Salesforce®”

Among Forrester’s recommendations for scaling Salesforce® is to architect a customer platform at the outset, rather than just customize a CRM application for the Sales team. Other recommendations include establishing a Center of Excellence (CoE) and taking a layered technology approach, so as to not encumber the core CRM with unnecessary code and content.

Third-Party Low-Code Platforms for App and Workflow Development

In both the webinar and in the report, Forrester is quick to point out the role that third-party low-code platforms play in architecting an enterprise-class customer platform. Aside from the fact that Forrester, contends that custom apps and workflows should reside on their own technology layer, Salesforce’s own portfolio of declarative application development tools aren’t designed with sophisticated process automation in mind. Salesforce’s mainstream technology, Force.com, is a leading low-code platform in its own right, but may not be the best choice for creating apps that must span multiple line-of-business systems; custom, on-premises applications; and disparate environments.

Building Self-Adaptive Salesforce® Apps with AgilePoint NX

As we pointed out above, one of the biggest challenges when scaling Salesforce® into a customer platform is hundreds—even thousands—of custom apps and the deep interdependencies that exist between these apps and the various technologies they interact with—changing one little thing could result in weeks of regression testing to ensure that everything still works.

AgilePoint NX, a leading low-code platform, has a unique architecture that solves much of this problem. Built on a stateless process engine and utilizing a true, model-driven architecture that abstracts model components into underlying code, AgilePoint NX apps can actually self-adapt on the fly to evolving enterprise conditions.

Furthermore, AgilePoint’s Salesforce® App (available on AppExchange) provides game-changing capability within the Salesforce® ecosystem. In essence, AgilePoint NX forms, dashboards, and Work Center can run as native code within Salesforce®. Not only does this approach improve performance and increase security, it completely eliminates the need for IFrames. Likewise, AgilePoint NX eliminates the need for API calls, typically required as third-party technologies in your customer platform need to continually poll Salesforce for updates.

To learn more, watch the webinar linked above, or just drop us a line. We’d love to demonstrate how AgilePoint can dramatically improve your efforts to scale Salesforce® CRM into a powerful, customer platform.

The post Scaling Salesforce® from a Simple CRM to a Powerful Customer Platform appeared first on AgilePoint.

Get Our Free Ebook: Software Driven Everything . . .

Not only will it require a methodology for lightning-fast creation of new, custom business applications that define workflow, codify best practices, and consolidate entire ecosystems. But this avalanche of new business apps will need added dimensionality—the ability to responsively adapt to changing technical and business requirements without having to be taken offline, updated, recompiled, linked, and executed every time something changes, which, in today’s business environment, would be constantly.

What’s the ETA?

So how far off is this futuristic world of software driven everything? An answer is hard to give but not because of a lack of hardware, bandwidth, or big ideas. Rather, the chasm to be crossed is inadequacies in the current technologies and methodologies used to develop and maintain software.

The Great Software Divide

It’s been years now since Agile overtook the old Waterfall method of software development, perhaps the biggest catalyst for this change being shorter development cycles. And while there are lots of different schools of Agile development, each, nonetheless, shares some sizable shortcomings in regard to full-on digital transformation:

1. 1. Agile development requires actual software engineers to write code, which, of course, is time and resource intensive. Put another way, while Agile is faster than Waterfall, it’s still nowhere near fast enough to automate every little process in a company, at least not in most of our lifetimes. Furthermore, given the sheer number of apps that will need to be written, the gap between available and necessary software engineers capable of this level of development is, at present, huge but will get ever wider for the foreseeable future.
   2. Hand-coded software has to be compiled, linked, and executed. And it’s this reality—baked-in feature sets—that may be the biggest short-coming of current software-development methodology when juxtaposed with the sheer size and scope of full-on digital transformation.

The bottom line is hand-coded apps simply can’t be produced fast enough to keep up with status-quo requirements, let alone the exponentially larger requirements of digital transformation. And these traditional, hand-coded, baked-hard-as-rock apps lack the responsive characteristics necessary to function in today’s more liquid business environment without constant upkeep. In fact, upkeep is arguably the real rub, being a pernicious form of technical debt that would quickly eclipse the financial upside of digital transformation.

Low-Code Platforms—a Step toward Software Driven Everything

Over the past several years, many pure-play Business Process Management Suites (BPMS) have morphed into low-code process platforms, which can still be used to automate processes and improve operational efficiency but which can also be used to build composite apps offering broader value to entire business ecosystems. This new breed of low-code platform is lighter and more nimble than its BPM predecessors and requires much less upfront investment and long-term commitment from customers.

Low-code platforms across the board utilize a point-and-click development environment that allows citizen developers (power users but not necessarily software engineers) to compose applications by dragging activities, forms, and other types of controls onto a canvas and then configuring each to application specifications. The result is an application model, a visual construct that incorporates any number of on-premises-based systems as well as cloud-native services and which depicts flow as well as inter-relationships between application components.

Part Way There

Today’s low-code platforms address one of the problems listed above: low-code apps can be built much faster than hand-coded apps, and they can be built by people with less technical skill sets than actual software engineers, a fact which dramatically increases available human resources. Shorter development cycles and more hands on deck is definitely a step in the direction of software driven everything.

However, the other, perhaps bigger problem mentioned above (actual digital transformation will require software that can self adapt to continual changes) will demand a technology far in advance of the current low-code standard, which is code generation.

Baked-In = Non-Responsive

Virtually all low-code platforms use a point-and-click approach that produces application models. Most of today’s low-code platforms must then transform the visual model into an actual software application through a process known as code generation, which, as the name implies, converts the model into low-level computer code. This code must then be compiled, linked, and executed. In other words, once a low-code app is deployed, it is no different than any other hand-coded app, having baked-in features and functionality.

Exacerbating the problems of “baked-in,” such apps, in order to run, must be loaded in their entirety into a process (workflow) engine, where they will live throughout execution. This permanent residence in the engine accounts for much of the shortfall of today’s software in regard to digital transformation, and here’s why:

When business or technical requirements change the state of each running instance of the app must be preserved while the app is taken out of memory. Modifications are then made to the model, at which point the model must once again go through the code-gen process. The resulting modified code must then be recompiled, loaded back into memory, and reconciled with the preserved state of each running instance of the app.

The sheer weight of the machinery involved in this endlessly recurring cycle brings the digital-transformation problem into specific relief: An app with baked-in features that must live, in its entirety, in a process engine throughout execution is dysfunctional in an environment where application characteristics must continually change, primarily because baked apps can’t self adapt to change, meaning they have to be manually updated. Again, in the world of software driven everything, apps must be self adaptive, eliminating the resources and accompanying expense of manual maintenance.

Responsive Low-Code Platforms

What’s needed, then, to catalyze digital business 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 of digital business. Responsive is, of course, the hard part.

Most low-code platforms evolved from BPM suites and simply don’t have architectures that support responsive-application development. One low-code aPaaS that does is AgilePoint NX, which can be used to highlight requisite responsive platform characteristics.

Model-Driven VS. Code Generation

In contrast to code-gen-based systems, 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.

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. Under any 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.

Runtime Updates

A model-driven architecture combined with an XML-based process engine results in apps that can be modified at runtime—as new business conditions are pushed into the model, the underlying code is 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-business apps, modifications are more likely to be made programmatically, via feedback loops of fresh data from any of millions of devices equipped with sensors and radio frequency tags.

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.

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 a liquid business environment.

In contrast, responsive apps are architected in such a way that they can 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 a software-driven-everything organization.

Application Liquidity

Regardless of the architecture that is used, software that is capable of catalyzing a state where software driven everything is possible must be able to adapt to changes 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.

The post Software Driven Everything and What It Will Take to Get There appeared first on AgilePoint.

Defining Digital Ecosystems

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 organizations: events logged in one system or application should trigger effects in others—status changes, process updates, notifications, and any number of other related activities.

The Self-Sustaining Nature of Ecosystems

Natural ecosystems are self-sustaining. No one needs to tell the fish to feed or the bees to pollinate. In fact, barring any kind of external impetus, a natural ecosystem will continue to thrive on its own. For an enterprise to become a digital ecosystem, it needs more than just a lot more software, a lot more automated processes, and a lot more connected devices. It needs digital intelligence, the ability for all of its digital connective tissue to be self-adaptive to change, to in fact be capable of evolution in its own right.

Self-adaptive is more than just a feature; it’s the catalyzing agent. To envision this in specific relief, just imagine the dysfunctional alternative: thousands of software developers constantly maintaining millions of lines of code to keep everything working in perpetuity. Without self-adaption, a digital ecosystem would be crushed under its own weight.

Salesforce® at the Center

Having invented the concept of Software as a Service (SaaS), Salesforce® began as just a CRM delivered as a cloud service, evolved into a sales platform, and has now grown into seven separate cloud services. The software giant has recently entered the business intelligence space, which will expand its reach and influence even further. But perhaps more telling than its sprawl is the fact that it has become the de-facto system of record for tens of thousands of enterprises.

Consequently, teams working in various line-of-business systems across an organization need access to Salesforce®-based data. More important, though, is this:

Given the role that Salesforce® plays in many organizations, events in Salesforce® must cascade throughout an enterprise. Likewise, events being logged in other systems should often be reflected in Salesforce® data records and be represented to teams and individuals who live in Salesforce®.

That’s the digital-ecosystem concept in play, and for thousands of enterprises, Salesforce® is key, perhaps even the critical piece.

A Sampling of Real-World Examples

While there are a virtually unlimited number of Salesforce®-centric, cascading effects we could highlight, here are just a few examples:

• Marking a Salesforce® opportunity as closed triggers the beginning of the fulfillment cycle, the processing of an invoice, and inventory-related transactions and processes, any and all of which will involve other systems.
• A digital signature on a contract triggers a notification in Salesforce® for the account manager.
• Changes in Salesforce® for Sales Forecast cascade down to your ERP system, initiating supply chain modifications and manufacturing scheduling.

Thinking down this path, it’s easy to imagine thousands of events happening simultaneously, each cascading, in turn triggering other processes, and launching additional events. To the extent that data is a driver, Salesforce® is the vehicle that must be woven into ecosystem DNA.

The question is how to actually build this highly evolved digital ecosystem?

Building Salesforce® Low Code Apps Fast—Just a Beginning

Low-code development platforms constitute one of the fastest-growing IT sectors, and the reason is the common goal of digital transformation, which, in the eyes of many, simply means lots more software, lots more automated processes, and lots more connected devices. But even this two-dimensional vision of digital transformation is a pipe dream in a world where Agile is the fastest way to develop and deliver custom software assets.

Low-code platforms, in contrast to Agile, can speed application development and delivery up to ten fold. And they can dramatically expand the pool of potential developers to include non-senior-system engineers (novice engineers and even power users [citizen developers]). Just the same, not all low-code platforms are created equal, and building an actual digital ecosystem requires a platform that can go far beyond mere rapid-application development. And building a digital ecosystem powered by Salesforce® data is yet another step beyond.

What Else Is Needed?

Finding platforms that can play at this level isn’t easy. Lots of them can speed the development process. Lots of them have extensive portfolios of adaptors and connectors, enabling cross platform, cross-cloud interactivity. But the self-adaptive aspect of requisite apps? Building apps that are responsive, not just to devices and browsers, but to technological and business changes throughout an enterprise? That’s both the hard part and the transformational agent. Salesforce®, of course, presents additional problems that require a truly unique low code approach.

AgilePoint NX, the Responsive Low Code Platform

AgilePoint NX has been in the market for a couple of years now, and has lived up to its billing. When Forrester released its initial Wave Report on this technology class (The Forrester Wave: Low-Code Development Platforms, Q2 2016), AgilePoint received a top-five ranking among all platforms across the five major platform categories. (Note that Force.com, Salesforce’s own low code entrant was another leader in the report.) At the time, much of AgilePoint NX’s capability simply fell outside the scope of the report. (If Forrester analysts had included responsive-application functionality as a benchmark, only AgilePoint NX would have qualified.)

Since that report was published, AgilePoint NX has made major advancements regarding Salesforce®, separating itself as what we believe to be the only low-code platform that can be used to transform an enterprise into a digital ecosystem fueled by Salesforce®-based data.

Responsive Application Architecture

Major components of AgilePoint NX’s responsive-application approach include the following:

• A model-driven-architecture that allows manual or programmatic updates of business logic and application structure at runtime
• A metadata abstraction layer that translates model modifications and data input into application code, which, for AgilePoint NX, is XML
• A stateless engine that processes components within application models as they are needed for each running instance (rather than loading an entire model into memory and keeping it there throughout process lifecycle).

What AgilePoint NX Brings to the Salesforce® Table

Now available in the Salesforce® AppExchange is the AgilePoint NX App for Salesforce®. This app enables AgilePoint NX forms, dashboards, and management consoles to be embedded in Salesforce®. Here are a few of the reasons why this design characteristic is an important advancement.

Salesforce® Secure

AgilePoint NX’s unique architecture enables it to pass Salesforce’s stringent security review, enabling AgilePoint’s dashboards, forms, and reports to run as native code within Salesforce®.

Native BPMS Functionality

AgilePoint NX, a multi-year occupant of Gartner’s iBPMS Magic Quadrant, brings world-class low-code BPMS functionality to Salesforce®, enabling you to model, build, monitor, measure, and refine automated processes, both for use within Salesforce® and throughout your enterprise.

While other BPM suites and workflow tools can push/pull data from Salesforce®, surfacing forms within Salesforce® in IFrames (functionality also available with AgilePoint NX, by the way), AgilePoint NX runs natively within Salesforce® and requires no IFrames.

Event Monitoring without API Calls

A critical aspect to ecosystem development is being able to monitor everything going on in an enterprise. AgilePoint NX includes event listeners that can monitor Salesforce® events and trigger various AgilePoint processes that include interactions with other applications. Likewise, event listeners can monitor events in other applications and trigger processes that interact with Salesforce®.

Most importantly, because AgilePoint NX is embedded in Salesforce®, AgilePoint event listeners can monitor Salesforce® activities without continually polling Salesforce®. Because this design characteristic virtually eliminates the need for Salesforce® API calls, system architects can design process applications with end users in mind, rather than how many API calls will be required.

Extensive Activity Support

AgilePoint enables extensive interactivity with Salesforce®, supporting nineteen separate Salesforce® activities.

Cross Platform, Cross Environment Workflows

AgilePoint NX enables you to build enterprise-class workflows and business apps that will run natively within Salesforce® and other cloud services but which will also interact with on-premises systems, both commercially produced and custom-built.

Beautiful Data Mashups Surfaced Anywhere

AgilePoint NX includes an eForms designer that can produce forms of any complexity. AgilePoint NX enables you to build forms that include data from multiple sources—no extra coding required. Forms can be interactive based on embedded business logic and can incorporate field-specific validation rules. AgilePoint NX’s eForms toolbox includes more than sixty control types. Any AgilePoint NX form can be surfaced in any other system.

Ubiquitous Dashboards of Visualized Data

AgilePoint NX enables you to track details regarding all relevant processes across your enterprise and compiles them on customizable dashboards for each Salesforce® user. Likewise, the same dashboards can be embedded in any other application or system, on-premises or in the cloud.

Granular Governance

AgilePoint NX allows you to embed its Work Center, Task Management, and Governance dashboards in Salesforce®, enabling Salesforce® Admins to interact with and monitor events in other applications throughout the enterprise without ever leaving Salesforce®. From these dashboards, Admins can define and extend rights and privileges to select people, while protecting sensitive data and processes from people who don’t need access to them.

Seamless Interactions with Other Systems and People

AgilePoint NX includes a library of Salesforce® AgileParts that you can drag and drop into your apps and workflows that enable them to integrate and inter-operate with Salesforce®.

How to Proceed

The good news is the AgilePoint NX App for Salesforce® is available now. And you can begin the process of transforming your enterprise into a digital ecosystem right away.

The post Salesforce® on Low Code: Transform Your Enterprise into a Digital Ecosystem appeared first on AgilePoint.

A few years back, Gartner began using the term “Nexus” to describe what it saw as the four IT forces that are shaping the lives of the world’s inhabitants: (1) the emergence of social platforms; (2) the proliferation of mobile devices; (3) the shift from on-premises based software, infrastructure, and platforms to cloud-native services; and (4) the explosion of data being generated along with technologies capable of processing massive datasets and identifying predictive patterns hidden within them.

Get Our Free Ebook: Digital Business will require a Software Revolution

Digital Business

Understanding the Nexus is important because it’s a precursor to understanding the term “digital business,” for which there are any number of interpretations, depending on which facet of digital business is in question. One broad definition of the overall concept states that digital business results from combining the nexus of forces with the Internet of Things (IoT), creating a world where people, businesses, and things become equal peers.

Implications of Digital Business

The implications of this view of digital business are profound: Consider a world where things, like people and businesses, will, in fact, take on the characteristics of customers. This eventuality is realized when sensors become so common that they are not only in our devices and machines but in our clothing and in the packaging of day-to-day items that we consume. Put another way, “things,” when they become depleted or worn, may actually initiate actions to replace themselves. In such a scenario, marketers, then, would need to devise ways to influence things as decision makers in billions of daily business transactions.

Furthermore, in this digital-business environment, requirements for any given app could change any number of times a day as billions of sensors monitor activity and push data to processing hubs that index it, synthesize it, and feed it back to billions of other devices running apps that need to be dynamically reconfigured based on this veritable kaleidoscope of changing business information.

What’s the ETA?

How far off is this futuristic world of digital business? An answer is hard to give but not because of a lack of hardware, bandwidth, or big ideas. Rather, the arrival of digital business is tough to predict because of inadequacies in the current technologies and methodologies used to develop software.

The Great Software Chasm

It’s been years now since Agile overtook the old Waterfall method of software development, perhaps the biggest catalyst for this change being shorter development cycles. And while there are lots of different schools of Agile development that might be applied to any particular development initiative, each, nonetheless, shares a couple of sizable shortcomings in regard to digital business:

1. 1. Agile development requires actual software engineers to write code, which, of course, is time and resource intensive. Put another way, while Agile is faster than Waterfall, it’s still nowhere near fast enough to catalyze the emergence of digital business. Furthermore, given the sheer number of apps that will need to be written, the gap between available and necessary software engineers capable of this level of development will get ever wider for the foreseeable future.
   2. Hand-coded software has to be compiled, linked, and executed. And it’s this reality—baked-in feature sets—that may be the biggest short-coming of current software-development methodology when juxtaposed with the looming requirements of digital business.The bottom line is hand-coded apps can’t be produced fast enough to satisfy future demands, nor do such apps have the responsive characteristics necessary to function in a global, data-driven, digital nervous system that ebbs and flows and changes constantly.

An Emerging Software Solution

Over the past several years, many pure-play Business Process Management Suites (BPMS) have morphed into low-code app platforms, which can still be used to automate and improve operational efficiency but which can also be used to build composite apps offering broader value to entire business ecosystems. This new breed of low-code platform is lighter and more nimble than its BPM predecessors and requires much less upfront investment and long-term commitment from customers.

Low-code platforms across the board utilize a declarative environment that allows citizen developers (power users but not necessarily software engineers) to compose applications by dragging activities, forms, and other types of controls onto a canvas and then configuring each to application specifications. The result is an application model, a visual construct that incorporates any number of on-premises-based systems as well as cloud-native services and which depicts flow as well as inter-relationships between application components.

Part Way There

Today’s low-code platforms address one of the problems listed above: low-code apps can be built much faster than hand-coded apps, and they can be built by people with less technical skill sets than actual software engineers, a fact which dramatically increases available human resources. Shorter development cycles and more hands on deck is definitely a step in the right direction.

However, the other, perhaps bigger problem mentioned above (digital business will require software that can self adapt to continual changes) will demand a technology far in advance of the current low-code standard, which is code generation.

Baked-In = Non-Responsive

Virtually all low-code platforms use a declarative approach that produces application models. Most of today’s low-code platforms must then transform the visual model into an actual software application through a process known as code generation, which, as the name implies, converts the model into low-level computer code. This code must then be compiled, linked, and executed. In other words, once a low-code app is deployed, it is no different than any other hand-coded app, having baked-in features and functionality.

Exacerbating the problems of “baked-in,” such apps, in order to run, must be loaded in their entirety into a process (workflow) engine, where they will live throughout execution. This permanent residence in the engine accounts for much of the shortfall of today’s software in regard to digital business, and here’s why:

When a business or technical requirement changes (remember that constant change is the hallmark of digital business), the state of each running instance of the app must be preserved while the app is taken out of memory. Modifications are then made to the model, at which point the model must once again go through the code-gen process. The resulting modified code must then be recompiled, loaded back into memory, and reconciled with the preserved state of each running instance of the app.

The sheer weight of the machinery involved in this endlessly recurring cycle brings the digital-business problem into specific relief: An app with baked-in features that must live, in its entirety, in a process engine throughout execution is dysfunctional in an environment where application characteristics must continually change.

Responsive Low-Code Platforms

What’s needed, then, to catalyze digital business 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 of digital business. Responsive is, of course, the hard part.

Most low-code platforms evolved from BPM suites and simply don’t have architectures that support responsive-application development. One low-code BPM that does is AgilePoint NX, which can be used to highlight requisite responsive platform characteristics.

Model-Driven VS. Code Generation

In contrast to most low-code platforms, which produce static models for code generators, 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.

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. Under any 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.

Runtime Updates

A model-driven architecture combined with an XML-based process engine results in apps that can be modified at runtime—as new business conditions are pushed into the model, the underlying code is 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-business apps, modifications are more likely to be made programmatically, via feedback loops of fresh data from any of millions of devices equipped with sensors and radio frequency tags.

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.

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 a liquid business environment.

In contrast, responsive apps are architected in such a way that they can 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 business.

Application Liquidity

Regardless of the architecture that is used, software that is capable of catalyzing digital business must be able to adapt to changes 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.

The post Digital Business and the Need for a Software Revolution appeared first on AgilePoint.

With digital transformation being top-of-mind these days for thousands of enterprises, low-code platforms are becoming one of the hottest sectors in the IT industry. The reason, of course, is simple: for most organizations, digital transformation means a dramatic increase in software development—new business apps, new mobile apps, new automated processes that cascade throughout an enterprise, completing, updating, notifying, and so on. Trying to pull off this sort of accelerated development with traditional methodology would require a virtual army of engineers, and not just to write the code at the outset, but to maintain it in perpetuity.

Low-code platforms, in contrast to development teams using Visual C++or any other traditional development environment, can speed application development and delivery up to ten fold. And these platforms can dramatically expand the pool of potential developers to include non-senior-system engineers (novice engineers and even power users [citizen developers]). Just the same, adopting a low-code platform for business and mobile app development as well for complex process automation doesn’t guarantee low code success.

The Low Down on Low Code

Elite low-code platforms utilize a declarative, drag-drop-and-configure approach to software development. And most have large portfolios of connectors/adapters to allow you to incorporate major systems, cloud services, and devices into custom apps and processes. These platforms enable experienced development teams to fly through complex development projects.

But such elite platforms are sophisticated environments having many hundreds—even thousands—of features organized in deep menu structures. Furthermore, these platforms have well defined protocols for application development that must be adhered to. Finally, they are called “low-code” for a reason—while many applications can be built entirely without coding, in many cases your IT department will find it necessary to extend the platform on the fron-tend, back-end, or both to accomplish its objectives.

Four Keys to Low Code Success

There’s no doubt that low-code is the wave of the future for a big part of custom software asset development. But like all IT initiatives, low-code platform adoption and deployment has inherent risks. The good news is that after almost fifteen years in the BPMS (Business Process Management) and low-code markets, our own Professional Services department has defined four keys to low code success when adopting, launching, and delivering software assets with a low-code platform.

Key One: Establish Executive Sponsorship

In one regard, low-code platforms are designed to create the digital connective tissue throughout an organization. (See Digital Ecosystems and the Enterprise Ripple Effect.) Many, if not most events affect more than one department. Automating processes that are triggered by events in one department that then cascade throughout an enterprise performing any number and variety of tasks is, by some definitions, the essence of digital transformation.

But this reality requires buy-in from multiple departments, including allocation of resources and budgets. And to ensure that interdepartmental cooperation exists, it’s extremely important to have executive sponsorship of your low-code initiative.

The executive sponsor does the following:

Develops Vision with Senior Management
Ensures Alignment with Senior Management
Manages Communication to Senior Management
Provides Support for Organizational Transformation

Key Two: Establish a Center of Excellence

A Center of Excellence (CoE) is the guiding entity that keeps all required components of an organization in line with a corporate vision.

Why Do You Need a CoE?

An organization’s low-code CoE has several important functions: The CoE

establishes a collection of methodologies, tools, and techniques that will be used by experienced staff to continually improve development procedures and projects.
orchestrates people and processes across IT and business units within other enterprise departments, such as Human Resources, Finance, Operations, and so on.
provides expertise to support application development across the organization.
addresses the need for a unified approach.
defines the complex relationships between various constituents of the system on an ongoing basis. This function provides governance over the process and people competing for resources and time while providing quality for new software assets.

Who should be on your CoE Committee?

Staffing your CoE with the right types of people is critical to low code success, enabling it to guide your low-code development initiatives. The CoE should include the following:

Visionary—someone who understands the enterprise processes that drive revenue and has a clear understanding of how they could be improved.
Project Manager—someone on the frontline of application development, who actually manages development projects for the company.
Platform Expert—someone who has deep understanding and experience with the low-code platform being deployed.
Enterprise Architect—someone who is involved in designing your organization’s software stack and has a big-picture view of your entire IT portfolio, including which systems and applications are rising in value and which ones are losing value.
Multiple Subject Matter Experts

Key Three: Ensure Governance

Governance is largely the domain of your CoE. Governance should be driven by committee, and, consequently, for each individual low-code project, you may require additional representatives from various departments.

One of the biggest issues with governing a low-code development initiative is configuring the platform itself. Likewise, depending on the platform you choose, each individual application or automated process may require additional configuration, extending rights and privileges to various staff members and blocking access to staff members that don’t need it.

Effective governance of a low-code project also includes establishing and codifying naming conventions, defining application specifications and feature sets, and implementing a system for change management and support. It is critical to ensure that Governance is appropriately applied to avoid restricting the benefits of the low code approach to development.

Key Four: Utilize a Low-Code-Development Methodology

Low-code development projects differ from traditional development projects only in the production of the software asset. All other non-coding activities and practices relating to a software development cycle need to be completed and adhered to. Put another way, it really is possible for non-programmers to build sophisticated apps and automated processes with a low-code platform, but designing and managing the development cycle is best handled by your IT department.

AgilePoint’s own Professional Services team has developed, over the course of several years, what it calls Beyond Agile Methodology, a systematic way to successfully complete low-code projects by combining best low-code-development practices with traditional, Agile techniques. While the Beyond-Agile approach evolved around AgilePoint NX, it, nonetheless, can be applied to almost any low-code development initiative using almost any elite low-code platform.

Beyond Agile is a three-stage process:

Define the scope of the low-code project in question.
Developing the software asset, as well as training materials and communications protocols.
Deploying the low-code asset in production.

Beyond Agile is an evolved methodology that leverages the power of AgilePoint NX to allow both rapid iteration and comparative paths to be realized in the development space in significantly less time than normal development times used in Agile. Designed to encompass even the most sophisticated development scenarios Beyond Agile and AgilePoint NX work together to improve the development cycle without additional resources. To learn more about Beyond Agile, visit us on the web at AgilePoint Professional Services or Contact us directly.

Summary

Because low-code is such a growth market, lots of vendors—both large and small—are hurrying new products into distribution. Perhaps the best advice you can receive is this: Be careful not to mistake brand visibility as a proxy for value. Put another way, spending a lot on a big brand is no guarantee of low code success. Find a platform that has functionality above and beyond what you need with flexible, reasonable licensing options (See Digital Transformation with the Safe-Choice Low-Code Platform.) from an established vendor with a history of success and recognition. A well chosen Low-code platform along with appropriate resources, strong governance and an innovative approach to development becomes the first stage in your transformation to a Digital Ecosystem.

The post Four Keys to Low Code Success appeared first on AgilePoint.

The report, of course, points to leaders in the space—huge players that include IBM, GE, and Microsoft and which have solid offerings in all five categories. Other major brands, such as SAP, Amazon Web Services, and Cisco lag behind a bit, and several others fall into niche categories, offering some categories of functionality but not all or offering all categories but having distinct weaknesses in one or more. However, none of the leaders may have the type of IoT application development capability that AgilePoint brings to the table, which makes AgilePoint NX a legitimate extension to any of the platforms in the report.

Forrester’s Five Categories

Forrester’s five categories are as follows:

1. Connection—Technologies that manage the link from devices to the Internet. The analysts point to two classes of connectivity technologies—short and long-range, which include specialized radio technologies designed to work over existing WiFi and Bluetooth networks and IoT software platforms that have the capability to manage “multiple carrier relationships and enable over-the-air device management.” Some of these technologies support specialized network protocols and may support specialized application and messaging protocols that are more efficient than HTTP.
2. Security—Technologies that protect IoT devices, data, and identity from intrusion. The IoT creates a diversity of potential security attacks. Devices generate proprietary data and information about companies and their customers and transmit that data via specialized protocols over the Internet. Exacerbating the problem is the vulnerability of the devices themselves, which can be hacked for information. Given the nature of IoT-connected devices, such hacks could go beyond data leaks, potentially placing expensive equipment at risk and even endangering lives. The analysts point out that IoT software platforms incorporate a variety of security components to ensure that breaches and intrusions can be avoided.

<li>Management: controlling of the provisioning, maintenance, and operation of IoT devices. IoT scenarios often involve many thousands of connected devices to monitor and measure state information, such as pressure, temperature, or vibration. Elite IoT platforms enable IT personnel to more easily configure, provision, and initiate the operation of connected devices, applications, and products, and facilitate the monitoring, testing, updating of software, and the troubleshooting of connected devices.

• Analysis: transformation of data into actionable insight. Thousands of sensors pushing data to processing hubs can yield enormous amounts of unstructured, unusable data. Leading edge IoT platforms, such as IBM’s Watson IoT platform and SAP enable analysts to visualize all of that data and even help analysts interpret the data to find actionable insights.
• Application Development: create apps and integrate systems. The diversity of IoT use cases requires software integration and APIs that support business processes and applications. Many IoT platforms allow developers to more easily create apps that are integrated with specific IoT connectivity, security, and manageability capabilities. IoT platforms often have development and API tools as well as connectors and adaptors that facilitate integration of enterprise applications.

AgilePoint NX as a Platform Extension

AgilePoint NX provides much of the same functionality that IoT platforms have regarding application development and integration; however, AgilePoint NX is a low-code platform, enabling the development of IoT apps up to ten times faster than the more traditional coding methodologies supported by IoT platforms.

Furthermore, AgilePoint NX application models are built on a responsive architecture, which is ideally suited for the rigors of IoT computing. AgilePoint NX utilizes a true model-driven approach coupled with real-time metadata abstraction into code that is interpreted at runtime. This design characteristic enables data from thousands of sensors to be rendered down into actionable data points by an IoT platform, fed into an AgilePoint application model at run time, and the application will reconfigure itself on the fly as ecosystem dynamics fluctuate.

The post Forrester’s Five IoT Categories and Where AgilePoint Fits In appeared first on AgilePoint.