Stormy Weather meets Compliance Oriented Architecture

In today’s Financial Times there is an article on the emerging science of enterprise risk management.

The author, Ayse Onçüler, identifies three significant areas of exposure:

Financial risks created by market fluctuations or change in credit status

Operational risks stem from inadequate procedures and systems

Business-volume risk driven by unexpected changes in the demand for products and services, supply structure or competitive environment

I am not sure exactly where risks from external factors such as storm damage come in but the approach makes sense. Risk management will ideally be democratized and pushed out to those best placed to assess risk. Thus, for example, a VP of a software company in San Francisco is probably not the best person to make decisions about risk exposures owing to changes in the European political landscape. Leave that to local decision makers. But risk must still be managed in an enterprise context, so that the VP in question is in a position to know what decisions have been taken and why and what associated risks are. There is a balance between central control and distributed decision making in all organizations–one of IT most’s potent metaphors, for example, is the swinging pendulum from distributed to host computing and back again.

Risk and compliance are tightly interlinked concepts. RedMonk is currently building a topology we call Compliance Oriented Architecture, and we’re looking for contributions from interested parties. Its interesting to map COA thinking to the notion of ERM–certainly the services within COA would need to support mitigation of all three types of risk identified by Ayse. Business volume risk is interesting because it ties to notions such as business service management, utility computing, adaptive, On Demand, or whatever you call tighter alignment between infrastructure demand and business process requirement. The policies and service levels set by lines of business drive the need for infrastructure control mechanisms and automation. Technologies such as grid computing and virtualization therefore mesh with higher order concepts such as risk management. Operational risk is where IT infrastructure management meets compliance with regulatory or voluntary standards.

Of course, just as in IT, different business constituencies use different language to describe the same things. There is no esperanto of risk, which is why I believe COA may inform risk management thinking, not just the other way around. If an organization builds a service-oriented architecture for compliance, by definition they begin to build a consolidated federated view of risk. COA can help risk managers.

At another level the merging of COA and ERM narratives throws up intriguing challenges for IT marketers– does VMWare, for example, need to train its salesforce to talk to risk management executives? If it does, COA can potentially help them have that conversation.