One of the basic tenets of control theory is that a control system must have as much flexibility and variety as the system it is trying to control. This is known as Requisite Variety. Previous attempts at internal audit and control have either themselves lacked flexibility and responsiveness, thus compromising their ability to deliver effective control, or have imposed inflexibility and unresponsiveness on the underlying system. Neither of these outcomes is acceptable.
For the management controls to be effective there must be some way for the management system to intervene in the transaction system. There is an architectural choice between direct and indirect intervention.
| Direct | Indirect |
| When the management subsystem detects an anomaly, it immediately intervenes in the transaction subsystem - possibly changing the status of some transaction record, or moving a transaction to a different account within the general ledger. Changes to the transaction system may also involve adjustments to elements of policy or context governing the transaction subsystem. | When the management subsystem detects an anomaly, it triggers a piece of workflow, or generates some additional transactions, which are fed back into the transaction system. A human supervisor is notified, who may have the authority to make changes in the transaction system and/or undertake further investigation. |
| This approach tightly couples the management subsystem and the transaction subsystem into a single unified system. The management subsystem is intrusive into the transaction subsystem. | This approach maintains loose coupling between the management subsystem and the transaction subsystem. The software component of the management subsystem provides non-intrusive monitoring. This can be implemented as an instance of the Observer pattern. |
The SOA principle of loose coupling clearly favors the indirect, non-intrusive approach. However, we must be careful to ensure that the indirect control remains effective. There needs to be some coordination between the collaboration or process management layer in the management subsystem, and the collaboration or process management layer in the transaction subsystem.
In a dynamic SOA environment, we actually need a double instance of the Observer pattern. The management system needs to monitor dynamic changes to the transaction workflow, as well as the transactions themselves.
The management subsystem must be as adaptable as the transaction subsystem - and this calls for the same SOA design principles to be applied to both.
| Information Management / Business Intelligence | Information architects may wish to think of SOX requirements in terms of data integrity - providing a guarantee of consistency and completeness across multiple diverse applications and data stores. For information management, Sarbanes-Oxley provides a push towards real-time closed-loop information management and business intelligence. Many BI products are now Web Service enabled, and this makes it easier to quickly plug BI capabilities such as monitoring and data mining into the business process. |
| Model-Driven Compliance | It is impossible for an organization of any size or complexity to achieve SOX compliance without some serious modeling effort - involving both data and process, and showing how data are transformed across multiple and diverse applications and data stores. |
| Web Service Based EAI | SOX compliance typically requires a major rewiring job to corporate financial information systems. In some cases, some additional applications and packages will need to be quickly plugged in to complete the solution. New or reengineered interfaces should be rendered as Web Services by default. Organizations that are already using a Web Service or EAI platform will be able to leverage this to achieve SOX compliance more quickly. |
See also
CBDI Report April 2004: Sarbanes-Oxley Drives Web Services Adoption
Notions: Bezzle
No comments:
Post a Comment