Thoughts on "SOA Meets Compliance: Compliance Oriented Architecture"
I have read and re-read the subject
study published by RedMonk
recently. In this document, Stephen O'Grady makes a compelling argument
that the growth of a services oriented architecture should not confine
itself to "silos" of implementation, but should be geared towards
the adoption of a common architecture geared towards corporate compliance.
His reasoning for this is that new regulations being promulgated by regulatory
bodies around the globe are not new innovations and practices, but the
implementation, codification and reinforcement of existing practices.
It is this message that has me saying
that RedMonk, while providing a compelling argument and roadmap for a Compliance
Oriented Architecture (COA), does not take it far enough. If I were to
rewrite this document (which I may do as a white paper under the CreativeCommons
license provided by RedMonk), I would rename the architecture the "Business
Process and Internal Controls Oriented" (BPICO) Architecture.
I am not going off the deep end here,
but am looking at it terms of what any architecture should do: ensure that
any information systems projects
- satisfy a clear business objective
- gain necessary approvals before beginning
- are designed to ensure reuse of common assets are reused
- ensure that effective controls are built into the systems.
This is often easier said than done and Stephen clearly articulates this in the RedMonk study. But if systems were consistently built with the considerations I state above, there would not be a need to push for a COA. I have seen too many organizations have a knee-jerk reaction and run around like chickens with their heads cut off to respond to the latest fire drill or regulatory requirement. This is often what leads to redundant data stores and the acquisition/
implementation/deployment of unnecessary resources, as Stephen points out.
Stephen likens compliance as "a journey, not a destination". The destination of any business is to be successful and to do so means the development of a sound internal controls environment. This environment needs to be supported from the highest levels of management (yes the "C" people). The need for this environment needs to be communicated at all levels of an organization. Processes need to be put in place so that silos cannot be built and that individual fiefdoms cannot override or undermine the environment.
If this is done effectively, the journey will show wondrous results in the form of being able to respond to and tailor process outputs to whatever regulatory and/or legal requirements might arise. Think of it as driving across Medicine Bow National Forest in the Rocky Mountains. Your destination may be the great fly-fishing in Saratoga on the other side. But because you have mapped out the journey well, you are able to stop and see that your thought out journey allows you to see and appreciate the beauty of the pristine Lake Claire.
It really is that basic. Let compliance be a pleasant by-way on the journey to business success mapped out by a strong business process controls environment.
