We've all seen cities that don't just quite seem to have a sense of place, where the zoning didn't yield a coherent set of uses or designs and things just seemed thrown together. This results from a lack of planning. Imagine the difficulty and danger of living in a place where there were few standards for building, multiple electrical voltages and phone systems, and roads were put in place willy-nilly.

This is a situation that most enterprises find themselves in with their digital identity infrastructure. The systems are thrown into place with little thought to standards or interoperability. Solving the problem of the day, week or month becomes standard operating procedure. The end result is a tangled mess of systems that are brittle and unreliable. Heroic efforts are required to make small changes or even keep the systems running day-to-day.

In the same way that city planning creates a set of standards and rules for buildings to ensure the overall area is consistent and workable, an enterprise architecture is a set of standards and rules that creates, if done right, an interoperable and flexible enterprise IT infrastructure.

The work of city planners can be divided into three primary categories:

• Standardization - dimensioning of pipes, voltage, roadways, etc.
• Certification - regulated and standardized qualifications for workers
• Management - rules, notifications, permits, approvals, etc.

The work in enterprise architecture is largely the same.

If enterprise architectures are like city plans, then system architectures are more like the plans for a single building. The plans for the building are made within the context of the scope of a city plan that not only has defined roads and lots, but also set standards for sidewalks, set-backs and so forth. Furthermore, the city plan has adopted building codes that define how the building will be implemented and sets out best practices. As someone who's recently built a house, I can testify that none of this is cheap and the builder is required to pay for all of it right down to the compliance inspections.

Enterprise architectures, likewise define a context for system architecture. A well defined enterprise architecture will make demands on system architectures to certain ends. Like a good city plan, a large part of the effort is the governance procedures that create and maintain the plan and the inspection and quality assurance processes that endure its followed correctly. Also like a good city plan, conforming to the enterprise architecture will be neither convenient nor cheap and there will be considerable pushback if the organization is not committed to the process.

Enterprise architectures are important to building IT systems that are aligned with the business and provide lasting value. Identity management is a critical part of an enterprise architecture since it touches every aspect of the organization. The ideas and methodology involved in creating an enterprise architecture can easily be turned to the task of developing a subset of the enterprise architecture regarding the enterprise's identity infrastructure. I call this an Identity Management Architecture (IMA).

I'm using Identity Management Architecture in the same sense that I've described an enterprise architecture--a coherent set of standards, policies, certifications and management activities aimed at providing a context for implementing a digital identity infrastructure that meets the goals and objectives of the business right now and is capable of evolving with the business to ensure that the infrastructure continues to meet business needs.

Identity management architectures differ from typical information security planning in several important respects:

1. Identity management requires a functional business model. Information security planning rarely makes mention of the business. The business model describes in some detail how the business functions. This includes identifying important entities, resources and processes and their relationships. The functional business model may be detailed or abstract depending on the depth of the identity management architecture planning process and the level inside the organization.
2. Identity management requires that resources and entities be identified first. Since typical information security plans are largely about perimeter defenses, they are usually concerned with networks and servers rather than business documents and customers. Like the functional business model, the level of detail in the inventory of resources and entities varies depending on the nature of the identity management architecture planning process, but these are its central focus.
3. An identity management architecture identifies dependencies between identity data and systems. These dependencies are used to determine implementation priorities. Security planning, and most IT planning for that matter, often emphasizes projects that are deemed critical without seriously considering dependencies between data and systems. An identity management architecture highlights those dependencies so that they can be used in the planning process.
4. An identity management strategy is driven by long-term business goals surrounding employees, partners, suppliers, and customers, whereas security planning usually reacts to these relationships as perturbations or exceptions to the plan. I rarely talk to a business executive who doesn't complain about business goals being at the mercy of security planning.

Identity management architectures turn the tables by providing business justification for security and directory infrastructures that go beyond keeping the bad guys out and extend to enabling valuable business activities.