Government decision makers faced with the need to streamline their business operations have begun to worry that the architectural construct we call services-oriented architecture (SOA) cannot be reconciled with the implementation of bundled, enterprise-wide product suites – a.k.a. Enterprise Resource Planning (ERP) solutions. This article helps to unravel the conundrum plaguing those that see the challenge of reconciling SOA with ERP solutions as something of a difficult choice for business owners, to be made between the “best-of-breed” approach and a “one-size-fits-all” solution.
Those in government already using ERP solutions are learning to appreciate the fact that such enterprise-wide products, though seeming to be enormously complex, actually come with a great deal of embedded logic that reflects industry best practices in some of the most frequently used business areas, such as Human Resource Management and Financial Management. SOA, on the other hand, represents a whole new paradigm for organizing and leveraging all sorts of disparate IT-capabilities that may be already embedded in legacy systems and applications under the control of different business domains within the enterprise. Using SOA, such existing capabilities can be integrated with the best features of core ERP modules to bring both constructs to bear more quickly, and in complementary ways, on the business needs of government.
As suggested by Figure 1, the instantiation of an ERP solution in a government agency could treat some modules of the out-of-the-box product suite as “core” modules. As the ERP solution is implemented to enable such basic business functions, “core” modules associated with financial management, for example, should require no customization to speak of, since the product design accommodates these basic sets of business requirements by applying business logic that reflects industry- (and increasingly, government-) best practices. Such “core” module are at he same time treated as core business enabling services, from an SOA perspective.
Figure 1 also suggests that an ERP implementation may treat other modules of the product suite as optional add-on functions. Employed to satisfy other sets of requirements that may be less applicable to the enterprise as a whole but supremely important to at least one business domain (e.g., requirements associated with supply-chain management), such modules may satisfy business needs that are nearly the same in every enterprise with that business need, though they often require extensive configuration and administration of relevant (and configurable) business rules. Tightly integrated with the core modules of an ERP product suite, these business enabling services also reflect industry and government best practices as they have been learned by the ERP vendor from numerous instantiations of that product suite.
Whether meaning to or not, an agency effectively opts to treat the “core” and selected other modules it installs and activates with an ERP implementation as the basic business services of its SOA – i.e., if the agency aims to adhere to an SOA model for transforming the enterprise. When an agency decides to implement an ERP solution, all of its other IT-systems, applications, and infrastructure will need to be not just aligned with but adapted to it, including all legacy IT-assets.
If SOA has also been adopted as a fundamental premise of the enterprise, with respect to its architectural goals, then its activated ERP modules need to be treated as central services that can be used immediately to support SOA objectives.
The Importance of Web Services to Enterprise Application Integrations
Generally speaking, SOA relies to a great extent on the concepts of modularity and the layering of services, which can be readily bundled or nested in sets of interdependent, more robust services, as they are accessed to enable business functionality. SOA differs from the traditional notions of architecture by emphasizing the separation of data from its associated business logic by providing separate layers of “programs” that can be shared by multiple applications. This means that similar business logic does not have to be redundantly coded into every application that needs to rely on it. It also means that, when the business logic needs to be changed, it can be modified once, with fewer resources required to make the change. It also means that different applications can treat with the once-updated business logic in a similar fashion.
Increasingly, ERP solutions come with extensive tooling for Web services that comply with a set of standards that have been implemented widely enough in the past to make the integration of legacy applications on disparate technological platforms a less daunting task. Web services offered by ERP vendors today can be leveraged, using the SOA approach to enterprise architecture, to readily enable the integration of legacy applications with the basic business services provided by an agency’s ERP solution.
Though an investment may be required, in learning how to use web services for application integration, it is also possible to achieve the desired integration in an environment that was not originally created for SOA. Fortunately, in the case of SOA, perfect optimization doesn’t have to be the enemy of good enough. Indeed, a compounding effect can be realized by agencies using SOA more often – they soon learn that projects can be completed more quickly than before.
Residual Points to Ponder
SOA can be used to disguise the complexity of an agency’s legacy IT assets, as ERP solutions are implemented to satisfy the ever-changing business needs of government agencies. By enabling portal access to multiple legacy applications, business users, customers, and IT-support staff can work with consistent views of underlying data and business logic, despite the fact that users access information via multiple applications that may be running in vastly differing production environments.
The prepackaged functionality that comes with ERP product suites can be leveraged, especially when embedded development tools are also smartly applied, within an SOA framework to provide essential Web services support for the integration of an agency’s legacy applications and data.
Time and money can be saved by relying on Web services as a virtual adaptor for integrating legacy, often custom-built applications with the business enabling services installed and activated as key components of ERP solution.
Regardless of the solution set selected by an agency, or the architectural approach it chooses to apply, the replacement of human-provided services with online services means that the agency’s whole approach to the affected business processes needs to be revisited. It also means that business process management (BPM) and organizational change management (OCM) skills need to be included in the mix of expertise applied to such an ambitious transformation initiative.
