Information Architecture – which one?

Are you looking for one for discovery, knowledge sharing, records classification, collaboration, case management, SharePoint, GCDOCS or all of the above?? It’s becoming very confusing and different Information Architects are offering up an array of seemingly different approaches to choose from.

I’m one of those Information Architects. My focus is on digital information. I’m interested in “foundational” enterprise information architectures; and I’m also interested in specific goal-oriented and/or system-based “implementation” information architectures. My strong belief is that they are not mutually exclusive approaches; but you have to start by understanding how you are going to approach the foundational piece to ensure the integrity and interoperability of potentially multiple implementation architectures.

Now you’re probably even more confused. So I’m going to start by stating some basic truths about digital information (in a government department) that I think we can all agree on:

  • we have a lot of it, in many forms, created internally or gathered from external sources
  • an information asset, like any other asset, has more value the more it is used, now and over time
  • we don’t know what we have unless we can find it
    • we can’t find it unless it is organized in some way or we have a really great, intelligent search tool
  • we have to manage it (as an asset)
    • we can’t manage it if we can’t understand what it’s for and what it’s value is
  • we need to share it
    • we can’t share it if we don’t understand its value to others and what can be used in what circumstances
  • we have to classify it in order to ensure we are retaining it for the appropriate amount of time
    • we can’t classify it if we don’t know what it’s for and its business value

Moving on, in the workplace . . .

  • when we collaborate we create and use information . . . we have to manage it etc. etc. . . .
  • case management is essentially about managing sets of related information along a defined process or stages . . . we have to share (at least some of) it . . . we have to classify it etc.

Then there’s the technology . . .

  • SharePoint provides a collaboration environment for creating, managing, sharing and classifying information – its technical environment is proprietary and has its own set of features and limitations
  • GCDOCS enterprise content management suite provides an environment for creating, managing, sharing and classifying information – ¬its technical environment is proprietary to OpenText and has its own set of features and limitations

Recently, at Systemscope, we have been involved with information architecture projects involving all of the above considerations.

We have learned that you have to start with a technology agnostic, enterprise information architecture to address that first, most important batch of considerations – how to organize, manage, share, and classify all information resources. We have learned that these architectures are most stable and relevant when based on core business functions stemming from the department’s mandate, Program Activity Architecture and, if one exists, its Function-based Classification System.

This activity-based enterprise information architecture identifies an organization’s high-level activities, the business groups that conduct them, and the “subjects” or “business objects” (such as programs, clients, industry sectors, organizations) that are acted upon, used or referenced in the execution of the business activity. It also identifies the specific “types” of information resources associated with the activity. In other words, the enterprise Information architecture determines the Business Context for the information resources, as shown below.

Enterprise IA diagram

The important Life-cycle Context (to demonstrate the integrity and reliability) of an information resource is represented by the other facets shown, while additional information about the resource may be captured for specific goals such as records management (or project management, for example) and for specific systems.

These facets are captured as information metadata and can be implemented in different ways in different systems to achieve a variety of goals.

For those of you who know about SharePoint architectures, in SharePoint document management and collaboration implementations, we have applied this technology agnostic architecture by using the SharePoint Content Type feature to associate information resources to business functions. In other words, we have associated each core high-level activity with a Content Type that is assigned the right “Managed Metadata Term Sets” for the related sub-activities and subjects. The Managed Metadata associated with each Content Type are then used to accurately determines what an information resource (using the Content Type) is for, why it is of value and how it should be classified. This ensures consistent architectures across site collections and sub-sites where the Content Types are used, while still allowing for:

  • different solution/site “implementation” architectures to account for system capacity and performance factors
  • “implementation” collaboration and case management site architectures, using single purpose sub-sites or libraries etc. for more finely grained metadata inheritance at the lower architectural levels
  • use of Content Types (as children of the activity-based Content Types) for specific document type templates
  • different metadata-based navigation and search solutions for enterprise and lower-level team knowledge sharing requirements
  • site or library-based IM rules to automatically identify and capture active “authoritative” information of business value
  • a virtual Knowledge Centre across all sites
  • back-end repositories for managing long-term retention of inactive information resources of business value

The technology agnostic, enterprise information architecture can also be applied to GCDOCS folder-based architecture (with metadata inheritance and capture) for use of GCDOCS as a records repository back-end or as a standalone solution.

So the bottom line is while information architectures may come in different forms to achieve different “implementation” goals, the enterprise information architecture provides the foundation and should be thoroughly described and thought through before single-purpose implementations are designed. It would be a mistake to start the other way around and find you are trying to maintain the integrity of an enterprise architecture based on system constraints, document templates, particular case management and workflow requirements, or a business group’s particular way of sharing information amongst themselves.

Which architecture should you have? Have all the ones you need.


Leave us a comment: * Your information is never shared