This morning I had the pleasure of moderating a panel discussion at the
Gilbane Conference that
included Carole Stern Switzer of the Open
Compliance and Ethics Group, Lynn Brewer of The
Integrity Institute, and Michael Evans, Ernst and Young partner responsible
for developing the compliance architecture within Ernst and Young. One
objective of the discussion was to provide the IT people and project and product
management people, who make up a substantial part of the audience at Gilbane
Conference sessions, with some of the conceptual tools they need to help create
more effective compliance and risk management programs within their companies.
One of the questions raised from the audience toward the end of the
discussion asked about the "enablers" of an effective compliance
program. Lynn Brewer’s answer was interesting. Her observation has
been that companies that are making really effective use of compliance, rather
than just treating it as a checkmark, are typically ahead of the curve in terms
of investing in and integrating IT systems into the compliance effort.
Both Lynn and Carole Switzer argued that one of the key "enablers" is
the early and active engagement of people doing hands-on work on the IT side of
an organization.
These comments from two people who have been taking a broad look at
compliance efforts across many companies are similar to observations–from a
different perspective–that have been showing up on a couple of
technology-oriented blogs over the past few months. For example, James
McGovern, Enterprise Architect for The Hartford Financial Services Group, has
written a
call to action for people working on the technology side of organizations to
become actively involved in compliance work.
James Governor makes an argument similar to Lynn Brewer’s, but with a
twist. In a piece titled "Compliance
Projects Need Architects and Operators," he argues that system
architects "should be brought into compliance initiatives as professional
skeptics" and that system operators are most likely to be the people at the
"intersection of business process and data governance" who are in the
position to push back when data security or integrity is compromised.
One of the points emerging from the discussion here at the conference this
morning was that, even though this engagement of technologists in the compliance
process is important, it often won’t be easy. In many companies,
compliance and risk management used to be owned by the legal department.
That is changing, and companies are increasingly likely to understand that
compliance initiatives and responsibilities cut across departments and
disciplines. But there is still a tendency to see the IT staff as implementers
of the compliance system, rather than as important contributors to fundamental
questions about compliance architecture concerns, objectives, and design.
My own view is that the ability of IT staff to insert themselves into the
early stages of this process will require them to move beyond the role of being
professional skeptics and gatekeepers. Governor is right that those roles
are important, and it is also true that those roles are familiar and comfortable
for many IT professionals. But IT’s ability to get engaged in the
compliance process at the ground floor, shaping program objectives and
priorities, will require moving beyond saying "No" to saying
"Yes," actively affirming the importance of good governance,
compliance, and risk management. Being an enabler means putting your
shoulder to the wheel and helping to push. On the basis of the questions
and concerns raised in the sessions here at the conference, it is clear that
there are a number of IT people who are looking for ways to make that commitment
and effort.
Information Security and Forensic Oriented Architectures (Part One)
Been busy thinking about the original work done by RedMonk on Compliance Oriented Architectures and figured I would take the opportunity to expand the community of knowledge with something I am labelling Forensic Oriented Architectures……