Difference between revisions of "Information architecture"
(→Description) |
DavidBeraha (Talk | contribs) (→Definition) |
||
| (2 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
==Definition== | ==Definition== | ||
| − | + | {{ {{PAGENAME}} }} | |
| − | + | ||
| − | + | ||
== Description == | == Description == | ||
| Line 20: | Line 18: | ||
The deliverables in the plan and prepare stage are completed through discussions with the sponsor and stakeholders, which results in an agreed upon project charter/scope document, and workshop materials. | The deliverables in the plan and prepare stage are completed through discussions with the sponsor and stakeholders, which results in an agreed upon project charter/scope document, and workshop materials. | ||
| + | |||
| + | '''Governance''' | ||
| + | Moving forward the accountability for the maintenance and up-keep of the information architecture rests with the KM Steering Committee (KMSC) or other such KM governance body. While the KM team (responsible for day-to-day KM activities) will be responsible for keeping the information architecture updated, it is the KM Steering Committee who is accountable for approving changes. In executing their duties to approve changes, the KMSC ensures that any changes made are in alignment with the existing information architecture, that duplication does not occur, and that best practice heuristics are followed. They have final approval before the KM team implements the changes to the information architecture. | ||
'''Information Architecture Heuristics''' | '''Information Architecture Heuristics''' | ||
| Line 41: | Line 42: | ||
* Does the information architecture structure match the task structure, i.e. common scenarios? | * Does the information architecture structure match the task structure, i.e. common scenarios? | ||
| − | + | ||
| − | + | ==Synonyms and related terms== | |
| + | Taxonomy, meta-data | ||
| + | |||
| + | |||
| + | ==Related Articles== | ||
| + | [[Taxonomy]] | ||
==External Links== | ==External Links== | ||
Latest revision as of 14:07, 18 December 2015
Contents
Definition
The structural design of shared information environments: a discipline and a set of methods that aim to identify and organize information in a purposeful and service-oriented way; the resulting document or documents that define the facets of a given information domain.
Description
The process of developing an Information Architecture In the development of an information architecture, business-IT alignment considers the business needs, e.g. “what are the business processes that need to be supported?”, “what are the information flows?”, “how do people currently think about the information they use?”. These questions and others will be examined in the execution of the workshops.
Between one and three key stakeholders/process owners/subject matter experts from each of the functional knowledge domains should participate in workshops and/or interviews which will be scheduled to provide input and feedback on the information architecture. It is expected that these individuals will provide information on their business/ operational processes, information flows, any information architectures that they currently use, and any other information that may be useful in determining the information architecture.
The workshops result in buy-in and support of the project work group and lead to the completion of the synthesis phase of the project where a final information architecture is agreed upon and a report generated which captures a summary of the discussions and decisions that were made in the execution of the workshops.
The facilitation model that is generally employed in workshop delivery is one that establishes ground rules and values for the group from the outset and obtains consensus that group participants agree to be bound by the ground rules. It is a model that establishes the group norms from the start and ensures group members participate in a respectful manner.
The synthesis stage of the project actually starts during the workshop delivery, as the output and results of the previous workshop will be validated in the current workshop before moving on to the work of moving towards consensus on the enterprise information architecture. It is also true that the workshop activities may be modified as progress is made through them, as is shown graphically below.
The deliverables in the plan and prepare stage are completed through discussions with the sponsor and stakeholders, which results in an agreed upon project charter/scope document, and workshop materials.
Governance Moving forward the accountability for the maintenance and up-keep of the information architecture rests with the KM Steering Committee (KMSC) or other such KM governance body. While the KM team (responsible for day-to-day KM activities) will be responsible for keeping the information architecture updated, it is the KM Steering Committee who is accountable for approving changes. In executing their duties to approve changes, the KMSC ensures that any changes made are in alignment with the existing information architecture, that duplication does not occur, and that best practice heuristics are followed. They have final approval before the KM team implements the changes to the information architecture.
Information Architecture Heuristics
- In creating and finalizing the information architecture, it is important to keep the following guidelines in mind:
- Does the information architecture use a clear grouping principle?
- Are the categories sufficiently distinct from each other?
- Are subcategories within a category homogeneous?
- Is poly-hierarchy used where needed?
- Is poly-hierarchy used consistently to allow all likely access points?
- Do subcategories fit logically into categories?
- Does ordering of subcategories within a category follow a recognizable pattern that helps users to find products?
- Is ordering of subcategories within a category consistent?
- Is the structure consistent throughout the taxonomy?
- Is the structure of the information architecture consistent within comparable categories?
- Do high-level groupings effectively convey what can be found on the repository?
- Is the hierarchical structure logical?
- Are single-child categories avoided?
- Is the information architecture free of Other/Miscellaneous categories?
- Is the information architecture free of General subcategories?
- Is the information architecture extensible--would it be easy to classify a new product type into the taxonomy?
- Does the information architecture structure match the task structure, i.e. common scenarios?
Taxonomy, meta-data
