Chapter 14. Governance and Business Modeling

When I became CIO for the State of Utah, I had very little appreciation for how much time and effort went into governance issues in a large organization. Before my stint as CIO, I'd been CTO of http://iMall.com, a company I founded; I had hired nearly everyone who worked for me. As we'd built the organization, we'd also built and shaped the vision and the culture. People naturally understood the business, because they'd seen it develop and had crucial roles in making it work. Furthermore, while we'd had our share of culture problems, we'd handled them on the fly and with decisiveness. When decisions needed to be made, we made them, and things worked marvelously.

I soon found out that the state was a different animal altogether. There were, of course, differences between the public and private sectors, but over and above those, the organization was an order of magnitude larger than what I was used to, and there was what I call "legacy lethargy." Moreover, IT was organized in a decentralized fashion so that no one really had the authority to make important decisions, even when there was clear and imminent risk.

For example, at one point, for a period of about two months, a wireless network was set up in the capitol with no access control whatsoever. Anyone with a laptop and wireless card could come to the capitol and surf the Net at taxpayers' expense. What was worse was that the network had been set up for legislators, so it was possible to monitor network traffic between legislative laptops. I knew about it almost from the beginning, and yet, I was powerless to put an end to it. The network had been put in place by another organization, and even though it presented a clear risk—not just to the people who used it, but to the entire enterprise network—there was no process in place to review plans, audit compliance with policy, or take corrective action. In short, we were stuck by our lack of a governance process.

Governance issues seemed to take up almost all my time when I was CIO. The governor had a clear vision for what he wanted IT to accomplish, but it was difficult to see how to move the organization toward those goals. Part of the problem was a lack of understanding on my part of how to use the organizational tools I had, because they were different than the tools I was used to. Part of the problem was that we needed some new tools and, most important, an enterprise-wide vision and commitment to achieving the goals of the chief executive.

After months of frustration, we finally embarked on a process to create that vision in a large cohort of the executive management, both business and IT. We were also to determine the process by which we'd govern the implementation of that vision. Those meetings, which I'd now call the "architecture initiation phase," lasted over a three-month period and involved over a hundred people in dozens of meetings. It was exhausting. Nearly everyone grumbled, including me. I wanted to build things, not spend all my time in meetings, and so did they. I've come to understand, however, how important that process is when creating enterprise-wide vision, designs, services, and systems.

In the end, we created a governance process that, looking back, had many of the required features of a good governance model but, for many reasons, failed to take hold. The process was a step forward, but it ultimately suffered from three things:

We could have mitigated these problems, had we had a better idea about what the initiation phase had to accomplish in order for it to succeed. At the time, I couldn't see the forest for the trees; I was too caught up in immediate goals and meetings to understand the true nature of what we had to accomplish. Looking back, I have a clearer view and can see the pitfalls and have tried to help others avoid them.

You may share my initial lack of appreciation for governance and wonder why you're reading about it in a book on digital identity. You may be itching to get to the business of building a digital identity infrastructure and be tempted to just skip all this political stuff and get to the meat. I hope the preceding story will help you overcome that temptation, and you'll spend some time understanding the governance process, along with the modeling and planning work that follows.

Before we get too far into discussing the IMA governance process, we should spend some time discussing the IMA lifecycle . Figure 14-1 shows that lifecycle, in general terms. The first thing to note is that a lifecycle implies a continuing process, and that's exactly what we're hoping for. The IMA should be an ever-evolving architecture that reflects current business needs. The IMA lifecycle is an up front acknowledgment that the IMA will affect the business on which it is built. As the IMA is built and put into practice, the business will change. The lifecycle feeds those changes back into the architecture to create a dynamic process.


The cycle starts with modeling, by which we mean the process of understanding the business, data, application, and technology environments within which the identity infrastructure will exist. We will spend a great deal of time in later chapters discussing the modeling aspects of identity management architectures. Modeling is not just where we start, but where we return, time and again, to gage the vitality of the IMA and monitor the ever-changing environment.

The second phase in the lifecycle consists of planning and documenting. This is an important activity that takes the models built in the first phase into account and creates plans for meeting the identity needs of the organization. This is the phase where standards are defined or set forth, certification requirements are laid out, and policies are created and discussed.

In the third phase of the lifecycle, the plans, policies, standards, and so on that were created in the second phase are reviewed. There might be several iterations back through the modeling or planning activities before they are finally approved. Once they are, the plans and policy are considered in force and, in a healthy organization, should be considered binding.

The next phase of the lifecycle is labeled communicate. You should not interpret this to mean that the other phases are carried out in secret, and this is the first time that others in the organization are informed of what's happening. To the contrary, we'll see that the entire process is designed to involve as many people and communicate the happenings as broadly as possible, even gaining consensus around important ideas before they are approved.

However, after the plans of the second phase have been approved in the third phase, they need to be communicated as approved plans and be maintained in a way that they serve as a reference for others in the organization who used them in their work. This implies more than simply sending them out in an email and hoping that everyone keeps the most recent copy. The communication phase requires version control, authoritative storage and presentation, easy reference, and searching.

The IMA is used in the implementation phase by system architects and others in the organization. The IMA should affect what is bought, how systems are built, and how data is stored and used.

The final phase of the IMA lifecycle is one that is often overlooked, but plays a crucial role in turning what would otherwise be a dead-end planning exercise into a living, cyclic process: auditing. Auditing is, perhaps, an unfortunate name, because no one wants to be audited. Even so, the feedback that the organization gets from comparing the plans to the implementation and then suggesting changes is invaluable. Just the number of outflows from the auditing box should be a clue to its importance. The audit might suggest changes to implementations to bring them into compliance with established plans. Alternately, the audit might suggest changes to the plans themselves, because they are unworkable in certain situations or not accomplishing their goals. Lastly, the audit might suggest changes to the models based on an evaluation of existing conditions.