It was a year back that I was still working in the area of Quality management and one of my colleagues in Product Development explained me in simple words as to what Service Oriented Architecture is all about. He said, with this architecture, we will not reinvent the wheel or rediscover new ways of bottling old wine, but start to build a common, centralized repository of independent business functions in the form of web services which can be consumed on-demand. This in turn exponentially increases the modularization and decreases redundancy too.
And now, extrapolating the above concept to achieving compliance, it can be definitely simpler provided we establish the core and pull out to create instances whenever required. A typical large enterprise usually has to comply with starting a few from the list to many of them:
- Quality Standards/frameworks/best practices: ISO/CMMI/SPICE/Malcomn-Baldrige etc
- Global regulations: Sox/KonTraG etc
- Industry specific regulations : HIPAA/MSHA/EU/EEC
- Vendor specific regulation: SAS70
- IT and continuity management frameworks: ITIL/ISO20K
I leave the list at that. The effort required for planning, acquiring and maintaining these certifications/compliance statuses every year is no doubt a substantial one. Making the job often tough is that not all functions in an Enterprise would need (or opt) to get certified and not all locations and subsidiaries may need it. This disparity induces complexity. It is in this situation when the teams start working in silos and disconnect from creating synergies. The implications are not only redundant effort but a complex process map – both for the enterprise and for the certifying body.
I have known and heard from my business contacts that there are different teams managing say SOx and SAS70 reports for the same business unit. Of course, I have to agree that the materiality and hierarchy of both types of controls are different but, on the other side, there exists a clear opportunity to integrate and synchronize things here! We should use/implement our new age tools with SOA concepts. So, here’s how to go about:
- Know your Organization: It is not unusual not to know what the team next door does! So break the barriers and some walls too:-
- Define your own framework which is typical only to your organization. This is a parent framework that may have many male and female children of different interests
- Define “controls” at appropriate hierarchy levels. There’s a good opportunity to integrate/carry over from already established systems (CRM/ERP). This will serve as a centralized repository of controls
- The defined controls should address one and only objective and should connect to dependencies Once we have this done, then its time to let the results fire! It shall be as simple as to pull out reports of compliance to controls which are specific to regulation in question. No doubt this procedure takes a considerable amount of effort initially but elementary mathematical aggregation proves it to have a good RoI over time. Though I have cited an example of a large enterprise, it fits just fine for an organization of any size.
Integrate this with operational risk management and incidents (and this list has no end, it can link into Performance management, Budget planning etc). Each incident has to undergo a react cause analysis and should be fed into the controls repository if need be. It is only if regulations are viewed this way, it can a boon to an Organization, else, alas! It is as of now – a burden