Making Governance Work at a Developer Level


Cliff Berg

May 2007

Summary: This article will show you how to implement business policies without creating a bureaucratic nightmare. (4 printed pages)


Ensuring Compliance
Architecture as Policy
What Is Business Value, Anyway?
Beware the Big Plan


"What policies?"

That is the response that I got when I asked a developer if he knew about the company's policies with regard to compliance and security. The company—a Fortune 100 company—had been chastised by financial auditors and had been in a Sarbanes-Oxley (SOX) compliance quagmire for several years. Upon inspecting various portions of the internal Web site, I identified somewhere around 200 policies (some out-of-date) with which software developers were expected to comply when developing software. The assumption seemed to be that policies could just be published on the site and that developers would then comply.

"Yeah, I'm working on that." That was the response of a project manager when I asked him the same question. As it turned out, he thought that to comply, all he had to do was fill out any paperwork that was required to assert compliance. Entire categories of compliance ended up being addressed merely by checking off items in a list. When I responded that this did not sound like it was very effective, the project manager said, "Yeah, they [the executives] think they can just throw it [the policies] up on a wall and everybody will follow it."

Ensuring Compliance

Governance is fundamentally about implementing policies. Policies embody strategies for addressing enterprise goals and concerns. An effective governance system does not merely check for compliance, it ensures compliance. To be effective, IT-related policies must impact what developers do when they sit at their desk every day. Otherwise, the policies have no impact on the organization.

One of the problems is that most IT-related policies are rarely absolute. Suppose you were reading a data-quality policy and it said that all departments must implement controls with respect to data quality. Most likely, there would be departments that had not yet complied with this policy for various reasons. Exceptions inevitably abound. A colleague of mine once gave a talk on service-oriented architecture (SOA) security and pointed out that the SOA vision of an enterprise service bus is rarely the actual architecture that real organizations have—that the real architecture is myriad exceptions—and that this was one of main challenges to securing SOA environments.

The lesson here is that policies are not absolute, that there are business trade-offs with respect to when—and to what degree—policies should be implemented. Thus, to implement a policy, you must implement a decision-making process that arbitrates the policy against other policies and other concerns of the organization.

Architecture as Policy

Enterprise architecture is an elaboration of enterprise policy in that it interprets policy in technical terms and provides a set of predetermined technical decisions that help to ensure alignment with policy. For example, enterprise architects might choose to address the data-quality-controls policy by defining an architectural rule that requires all systems to have built-in data-quality controls. What, then, should be done if the business identifies a new commercial off-the-shelf (COTS) system that will allow it to move into a new market very quickly, and the COTS system does not have the required built-in controls? Arguing that the organization should not buy the COTS system will surely fall on deaf ears, because a significant business opportunity is at stake. Furthermore, the business proposes that data quality be addressed in this case by adding on secondary data-quality processes—in violation of the architecture—and that the COTS system can be replaced later by adding its capabilities to better-integrated in-house systems. The architects respond that this is feasible; but history shows that every time the organization makes an exception to an architectural rule, it never goes back to "clean things up," because new business drivers will take precedence.

What Is Business Value, Anyway?

The real issue at stake is business value. The architects can pontificate all they want about policy and enterprise architecture, but unless they can talk in terms of life-cycle cost, business agility, and business risk, no one from the executive team is going to listen, and for good reason.

The implication is that governance cannot be effective unless it incorporates business value into its decision-making processes. Governance may be about implementing policies, but policy implementation requires decision-making, and decisions must be made based on business value.

The challenge is that developers are so very far removed from business-value calculations. How often have you encountered a software project that had the goal of reducing life-cycle cost by a certain amount? Or of increasing business agility by a certain amount? Or of realizing a particular gain in market share? IT projects are usually framed in terms of functional capabilities, instead of actual business value. Software developers think in terms of features, not value.

When IT professionals hear the term "business value," they often think in terms of features and opportunity—the new things that users can do with new features, and the business opportunities that might create. The paradox is that IT architecture is usually about agility and life-cycle cost; more often than not, architecture rules specify practices that encourage consolidation, simplicity, and clear definition of the responsibilities of components. If followed, such rules tend to increase business agility (because systems are more consistently designed) and to reduce life-cycle cost in the long run (because data flows are simpler). Nowhere does business opportunity enter, except in the amorphous realm of agility—representing the ability to respond quickly to unanticipated future opportunities.

One thing is clear: As a group, IT professionals do not have a clue about how to deal with business value in terms that business people can understand. This is why IT is so seldom involved in major business decisions, and why it sits apart from the business in most organizations. It is also why IT governance has such a challenge before it: How can a business-focused organization govern something that does not communicate with the rest of the organization in business terms?

Beware the Big Plan

Organizations often realize that they need better IT governance and address it in the traditional way by gap analysis, and then by crafting a large, complex plan to implement a system of IT governance. The plan is decomposed into department-level tasks, and overall progress is tracked, based on the completion of those tasks.

The aforementioned approach suffers from extremely high risk and low efficiency, is often damaging to morale, and fails to deliver rapid results. It fails to address the deep deficiencies that are present in IT skills and the capabilities of departments. Additionally, the "big-bang" nature almost guarantees that lots of effort will be spent on approaches that do not quite work—requiring backtracking and, perhaps, putting the entire plan in question. A better approach is to start small.

A pilot effort is the best way to start small. A particular business area can be chosen and a team assembled that comprises subject-matter experts from that area, together with senior IT architects and a project manager to oversee the effort. The goal should be to establish and test a framework for governance by implementing the control and decision-making processes, and trying them out on a small scale.

Scalability must be considered from the outset—recognizing that decision checkpoints such as review boards are potential bottlenecks, and that it is more effective to teach people how to get things right the first time, so that they do not have to make several trips through a review board. One of the central goals should be to address how people can be made more effective; how meetings can be reduced; and how decision-making can be delegated or integrated into processes, instead of relying on communication between groups, because inter-group communication is much less efficient than intra-group communication. Therefore, the pilot effort must find a way to measure the "turnaround time" of governance processes, and find ways to make it as efficient as possible and have low latency.

Another goal should be to identify the skills that are needed by various functions and what is required to have those skills. Because people learn best by doing, it might mean that skills such as the ability to express business value might require that people from certain lines of business—even finance, perhaps—be embedded with IT teams to help them to develop these new skills. Opportunities for skill dissemination should be explored in addition to other avenues for elevating the skills of the various departments of the organization and for integrating governance-based decision-making into the operation of each department.


About the author

Cliff Berg is a consultant in IT assurance, agility, and governance. He is the author of three books, most recently High-Assurance Design, which addresses principles and practices for designing reliable and secure software. Earlier, Cliff was cofounder and CTO of Digital Focus, a software-services company that was an early adopter of agile methods.

This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit