Early in my career I was influenced by the work of Christopher Alexander, an architecture professor at the University of California, Berkeley. Alexander and his team researched and cataloged patterns representing building, city and community construction best practices that had evolved over a considerable period of time. I used their seminal work, A Pattern Language, to guide the construction of my own home, and many of their principles to teach software engineering as a discipline.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Alexander, et al., note that, “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.”
Each of the architectural patterns includes a picture and a paragraph explaining how it works in context. Architectural patterns don’t constrain or inhibit creativity as much as they free designers to focus on the differentiations that have the greatest impact on the end user.
Twenty years ago, I documented some of my thoughts on software development patterns in an article titled “Systems Design: Lessons from Architecture.” I have been recently writing about the relationship between enterprise risk management and sustainability, and it occurred to me that GRC managers could benefit from taking a pattern-based approach to their work — especially for organizing their teams and system architecture.
Patterns are like musical forms — there are infinite varieties and parts to be created, but the overall structure is known to “stand the test of time.” We already have well-established sets of controls for GRC, such as COBIT and ISACA’s Risk IT. These are all important, but not an alternative to patterns because their intent is to support auditing rather than to provide a creativity framework. Instead, patterns should complement controls.
A GRC pattern language, like a programming language or even a natural language, would be a shared resource to enable faster and more reliable enterprise system development. GRC patterns should include all the key constructs needed to ensure best governance and compliance practices (in this context, controls would be embedded in each pattern).
They also must be flexible. For example, with governance we know that it’s alright to have exceptions as long as there is a repeatable, auditable process for justifying and documenting them. Given the pace of technological advancement that drives business model changes, any pattern repository must allow for rapid changes, too.
I believe we need a GRC pattern guidebook, similar in spirit to Alexander’s work but one that leverages a broad community supported by collaboration tools and assembled by a flexible process. Changes in the environment may lead to the identification of new patterns based on analytics, and pattern retirement when conditions change is equally important. In other words, we need a Wiki to capture, catalogue, review and update patterns as a community.
With that in mind, SIG411 LLC is launching an open source patterns project that will include GRC patterns contributed by practitioners and academics who will be recognized for their contributions. The scope of the project is broader than GRC, as it will include patterns for all aspects of sustainable enterprises and societies. But given my personal interest in the intersection of enterprise risk management and sustainability, GRC will be an early focal point. I encourage all interested parties to get involved and contribute, as well as use, the patterns from this Wiki.
Adrian Bowles has more than 25 years of experience as an analyst, practitioner and academic in IT, with a focus on strategy and management. He is the founder of SIG411 LLC, a Westport, Conn.-based research and advisory firm. Write to him at email@example.com.