Layered application architecture delivers enterprise agility.
Defining digital transformation is hard enough. Wikipedia defines it as “the change associated with the application of digital technology in all aspects of human society.”
Technopedia says the term refers to how “companies are striving to keep up with changing business environments brought about by customer demand and technology.”
InfoWorld Executive Editor Galen Gruman, on the other hand, sees it primarily as a buzzword that is “hot again, mainly for the wrong reasons. That is, vendors want you to buy stuff because IT has been cutting back.”
But even Gruman sees a central truth to digital transformation, namely the importance of fungibility, or the intrinsic ability to change. And he rightly points out that many of the core processes addressed by enterprise resource planning (ERP)—security, identity, finances, orders, deliveries, payments—should really not be fungible. This is a system of record that, after all, must indelibly record business transactions.
This makes actually practicing digital transformation next to impossible, particularly if your ERP software throws roadblocks up in your path. As your ERP software system of record chugs along predictably and reliably to facilitate your current business model, how can it still be fungible or agile enough to change course as you, for instance, add a new division that facilitates engineer-to-order projects? As regulation is affecting your industry changes, how do you evolve your system of record to capture new data required by regulators without disrupting your steady-state operation? Or maybe your company purchases a division in Brazil and you need functionality to issue nota fiscal documents for tax purposes.
In these cases, your ERP software must be agile enough, fungible enough, to enable these new processes in a timely and cost-effective fashion.
But once you manage to adjust or modify your ERP software to meet these changing needs, what additional expense does this create as you try to upgrade that software solution? Modifications to source code need to be rewritten for each new version of enterprise software and then tested to make sure they are still performant. ERP users with a large number of modifications may find it too expensive to upgrade, stuck on old technology or forced to move onto an entirely new enterprise software product that better meets their current needs.
LAYERED ARCHITECTURE FOR EVERGREEN ERP
IFS has long understood that ERP must meet your business needs not only today but over that seven- to 15-year software lifecycle. IFS customers stay on IFS Applications even longer, in part because IFS has led the movement toward the agile enterprise since 1994, when we rebuilt IFS Applications with elements of layered architecture. In recent versions of IFS Applications, layered application architecture (LAA) has become a powerful tool to facilitate change.
Today, IFS Applications has been architected to be highly configurable and customizable so that our customers can easily adjust their software environment to fit their business as opposed to the other way around. And in order to ensure these customizations to not get in the way of regular upgrades, IFS has segregated them off into a separate layer of the application
How exactly did this work? To find out, I bought lunch for my officemate Michael Glorioso, who does a great job explaining this type of stuff to our customers, what this layered architecture looks like in real life. He told me how changes made by IFS customers are carried over into new versions during each new version upgrade.
“Code modifications and customizations are housed in a separate layer segregated from the core code,” Mike said as we both leaned into our chicken burritos. “A source code control system sends the code through a code generator that turns it into deployable code. Where necessary to support modifications or customizations, it adds an override to appropriate software components telling the application to use an executable from the modification or customization layer instead of the original code. As it compiles the deployable code, the code generator will recognize the override and invoke the alternate functionality as indicated.”
So a customization layer and the core code are zipped up together, in essence, with zero disruption. This allows IFS customers to change what they want and retain what they need as their business evolves with fungible, agile, evergreen ERP.
Learn more about LAA by reading our new white paper, Layered Application Architecture for Evergreen ERP.
Do you have questions or comments?
We’d love to hear them so please leave us a message below.