Overview#A clear statement of technical position on a variety of technology questions is a big help to system architects making individual technology and design decisions.
The creation of statements about business principles as part of enumerating business drivers. Technical position statements build on those principles. We would expect principles to change infrequently and follow the business strategy of the Organizational Entity. Technical position statements similarly flow from the technical strategy that the organization is pursuing.
Burton Group has developed a reference architecture for identity as part of its research and advisory services. They recommend organizations take a position on the following technology issues in Identity Management:
Directory Service access, administration, and security#How should organizations manage and secure their directory services while giving authorized applications, users, and administrators trouble-free access?
Directory applications#What tools and interfaces should application developers use to tie applications to directory instances?
Directory content, structure, and distribution#How should organizations organize, store, and reference information in a general-purpose directory system?
Directory integration#How can an organization manage and share useful, high-quality data in multiple directory services, repositories, and other sources?
Directory tiers, instances, and roles#How can organizations use tiered directory architectures to resolve structural, political, and functional differences that accompany general-purpose directory deployments?
User management#How should an organization identify internal and external users, and manage the lifecycle of those users?
User authentication#What strategies, technologies, and mechanisms should organizations use to authenticate users and provide appropriate protection to resources in a cost-effective, manageable manner? Public Key Infrastructure systems?
Making Decisions About Technical Positions#Identifying the questions is one thing. Making decisions about the organization's technical position is another. The end goal of the process is twofold:
- . Gather input from as many smart people as we could.
- . Create a group consensus around the decision.
In a large organization, the second point can be more important than the first. Taking technical positions does no good if people are going to question and even fight them.
Whether formal or not, taking a technical position requires several steps that can be enumerated and followed.
- . State the problem. The list of technology issues from the last section is a good starting point for problem statements. Usually the problem statements come down to a question that needs a technology answer such as "How will we use directories in our identity infrastructure?"
- . Determine your organization's requirements with respect to the problem. The purpose of this step is to customize the problem stated in step 1 to the specific goals of the business. Rather than a simple list, this step can be best accomplished as a white paper that can be distributed and commented on.
- . List the options for solving the problem. This step enumerates the options at a high level. For example, in creating a technical position statement on directories, the options would probably come down to a large centralized directory, a metadirectory, or a virtual directory.
- . Research near-term future developments. This step protects you from any impending developments, and is a good point at which to check in with analysts and other outside sources about your plans.
- . Determine the evaluation criteria. One way to go about this is to prioritize the requirements determined in step 2 and assign point values for each.
- . Establish subordinate technical positions. Big technical position statements are often collections of related smaller technical positions. For example, in creating a technical position on directories, you might take technical positions about whether to rely on real-time integration or synchronization, how to create unique IDs, and whether to use packaged software or customize the integration between applications.
- . State positions and justify them with reasoned arguments. The final step is to state your positions. Usually, technical positions are dependent on assumptions and thus tend to be best expressed as nested IF-THEN-ELSE statements. The arguments can simply be paragraphs stating why certain choices follow from certain assumptions and are a reflection of the work in steps 1 through 6.
These steps can be followed informally by a small group or through a more rigorous process with larger groups. We have often used offsite meetings and even professional facilitators. That may seem like overkill, but remember that your primary goal is to create consensus. Professional facilitators are trained to help groups do just that.