Solutions

Solutions ) PensionGold PE . Enterprise Solutions Foundation

Our goal in designing PensionGold PE was to build a completely flexible structure capable of quick and easy adaptation to changing business needs. We knew that such a structure would reduce the time required for implementation as well as changes to business rules.

We built PensionGold PE on a solid, stable foundation - the Enterprise Solutions Foundation (ESF) - and designed the entire structure to be completely flexible. To appreciate the incredible flexibility offered by PensionGold PE, you have to understand the ESF's basic architecture.

The ESF is made up of multiple layers, or tiers, which are separate from each other but work and communicate with each other in an orchestrated, or coordinated, manner. Technically speaking, ESF has an n-tier, loosely-coupled, Service-Oriented Architecture (SOA).

The ESF implementation of SOA features three main layers between the user interface and the database:

  • The Façade layer, which enforces security and directs messages coming to and from the interface by inputting the data into a series of contracts, allowing it communicate with the subsequent layers.
  • The Business Application Process (BAP) layer, which applies business rules and actions to information for the purpose of completing a desired action such as adding, updating or deleting a record.
  • The Persistence Access Layer (PAL), which handles communications with the database itself, including all data retrieval and storage.

In the ESF implementation of SOA concepts, business databases are completely separate from the programming code which tells the system how to work with the data. Business logic in the BAP layer, including the details of calculations that determine a retirement system member's future benefits, for example, is also separate from the programming code.

All of this separation gives ESF and PensionGold PE the flexibility to add or change functionality on the fly without risk that a change in one area of the system will have an adverse impact on another area of the system. That's one of the downfalls of a traditional, tightly coupled architecture: making a functional change requires rewriting programming code, and a change in one section of code very often affects one or more other areas of the code.

In a traditional architecture, just checking for the impact of a revision requires programmers to compile source code and test the result. If testing shows that the revision created a bug, it means the programmers have to rewrite code again and compile code again and test again until they find and fix the bugs created by the original revision. All of these steps, and the necessary reiterations, add to the time and cost required for any functional or business rule change.