Friday, January 30, 2015

SOC in an Automated Approval Process

Recently, I was involved in a project regarding an application which has an approval process to onboard an account from another system for use. The design is such that the data is duplicated in the systems. There is an issue that the data gets out of sync or is out of sync from the start.




For sake of example, let's say that we have a shipping system and an ordering system.


The shipping system contains all the source data for transportation companies (USPS, UPS, FedEx, Yellow, RoadRunner, etc). The shipping system is responsible for quoting and booking shipments.




The ordering management system uses the shipping system to send orders to customers. When a user of the ordering system has a new transportation vendor that they would like to use, they must enter the request in the ordering system for approval. Once approved, users may select the shipping vendor to use for shipping orders to customers.




The current design uses the record from within the order system with the shipping company name, and other info as it was entered for the approval process. This design has lead to data maintenance issues. I came up with a design that is not as fragile in terms of data consistency.




The proposed design for automated approval is as follows and may be used whenever this type of approval pattern is needed. The Automated Approval Pattern is a processing pattern that can be used whenever an entity must be entered into a system for use - whether or not the entity is foreign or native to that system.




The main benefit of the pattern is to keep the approval data separate from the usage data. The usage data may change. Once approved, the approval data is historical only. The data should be copied to a usage data store and all usage should relate to that store. The store may reside in another system or local to the usage system.




This separation implies that the approval process could be completely isolated to it's own system. This implies re-use of code and processing.




The basic flow follows different paths depending on the state of the entity in the source system. For our shipping system, a vendor may be non-existent, active, inactive, possibly other states. If the vendor exists, the approval data should be copied from the source data. If not, the user must enter the approval data in the approval system.




The approval process itself may involve one or many steps and the details will vary. The outcome of an approved vendor is that the primary key of the entity will be referenced by the usage system. The reference entity will be a proxy entity to the true entity in the source system. The proxy entity contains some usage system specific data as needed.




The usage system should always present relevant data from the source system - perhaps via a proxy class that represents the proxy entity in the usage system. The proxy class could use data from both systems, but only save to the usage system.




This pattern can be followed whether approval is required or not. The approval process should be separate from the loading and integrating of data. The approval process is volatile and should be contained as is own separate concern within the approval system.


When approval is not required, there may be yet be some benefit to using the approval system for adding entities. Perhaps some automation can be contained within the entry process. Another benefit would be the audit trail. Perhaps the most relevant would be the flexibility to add an approval process.


This pattern can be further normalized to an entry subsystem, an approval subsystem, and an integration subsystem. The entry system would be strictly responsible for lookup and validation. While some kind of hook would allow for the approval process from the approval subsystem to manage the approval workflow (whether existent or not). After the approval process, the integration subsystem would handle the setup of data in one or many usage systems and perhaps the source system.


The benefits of this pattern are greater flexibility, reuse, and data consistency. Costs may include greater complexity especially at scale and when building for reuse. I recommend using this pattern with some sort of relevant high level diagram of the architecture of the pattern clearly available to developers and technical support as to make clear the intent of the design. Basic component diagram and workflow diagram to follow....



No comments:

Post a Comment