The architecture of enterprise systems is rarely considered outside the realm of the IT department. Though it will always be IT that is most concerned with software architectures, understanding what an architecture provides to enterprise resource planning (ERP), enterprise asset management (EAM) and asset performance management (APM) software is critical—not only to the scalability and flexibility of your operations, but to your bottom line technology costs as well.
To understand how enterprise software architecture can affect scalability, flexibility and costs, it’s important to understand the concept of layered software architectures. The move toward layered software architectures began more than a decade ago with the adoption of service-oriented architectures (SOAs), says Amy Eager, technical solution architect at IFS North America, a supplier of ERP, EAM, maintenance and service management software.
These new architectures introduced the ability to develop and deploy enterprise software in a modular fashion, allowing companies to “implement new technologies quickly or support them as they branch out into new geographies with different regulations to consider,” says Eager. This modular ability of SOAs represented a major improvement over the monolithic enterprise software systems previously used (and which are still in place at many companies today).
Layered application architectures take the modularity of SOAs to the next level by “further increasing enterprise agility and reducing the amount of time and resources enterprise software consumes—time and resources that can be better invested elsewhere,” says Eager. “With SOA, components within the structure are organized into layers, with each one performing a specific function—the presentation tier to present data to the end user, the business logic tier to process information, and the data storage tier to hold the information. Modern, layered architectures take this one step further by creating separate layers that can contain modifications to the code, or customizations that users can make to adjust how their application performs. This approach makes the adoption of new business processes and technologies a lot easier.”
She adds that “one of the main strengths of a layered architecture is the ability to separate each function. For example, the presentation tier doesn’t need to pull information from, or store it in, the database or execute on the business logic, it just supports the various user interfaces accessed by end users. This makes it easier to develop, test and maintain the application as changes made in one layer do not directly affect any others.”
The abilities of layered application architectures mean that companies can tailor the software to fit specific work processes and routines. “For example, businesses can create user-defined fields and custom events to notify specific employees via pop-up messages on tablets or smartphones that a customer order just placed is below an approved margin,” says Eager. “This can even be extended by providing a warning or even stopping a customer order, which previously would have to have been done via modifications.”
For help in understanding how such a specific technology detail of enterprise software can affect a manufacturing business, consider CDF Corporation, based in Plymouth, Mass. A supplier of semi-rigid and flexible liquid packaging for the chemical, petrochemical, cosmetic, food and beverage and industrial markets, CDF is also part of Cheer Pack North America, a strategic partnership established in 2008 with Hosokawa Yoko (Japan) and Gualapack (Italy). Together, the companies have a customer base that stretches across six continents.
The specific software architecture aspect that provides CDF with the flexibility it needs is the layered architecture offered by its IFS ERP software. “We make heavy use of the configuration layer,” says Alex Ivkovic, director of IT at CDF. “We have made no modifications to it, and I believe this is the way to go. But other customers I interact with have told me they have been able to significantly reduce their use of modifications by using the configuration layer.”
Explaining the difference between modifications and configurations, Eager says the main differentiator is that modifications are new executables that run in place of existing software functionality. “These [modifications] require coding and testing, and must be rewritten or uplifted to accommodate each new version of the underlying software,” she says. “Configurations, however, are extensions to the underlying functionality that can be executed easily, even with more complex changes—such as when an existing database field needs to be changed. Modifications must be supported by the software vendor and therefore increase ongoing maintenance cost; configurations, on the other hand, carry no added support cost.”
Layered architectures also handle country- or region-specific localizations, adds Eager, meaning manufacturers can rapidly expand into new regions while region-specific functionality is implemented in each geographic area. “By getting rid of the need for modifications, layered application architectures can help lower total cost of ownership, as remaining modifications can be easily moved over to new versions without needing to be rewritten,” says Eager.
