What is not included here, is the time it takes staff to synchronize and determine what the “truth” or information of record is.This activity often turns into projects, and projects that occur anyone wants to build anything that uses or attaches to this data. It is necessary to determine who entered what, and when it was done to determine which information is more current.

Where and What are Your Truths?

While we all know this, we almost all accept it as a problem that we ourselves did not create. It is almost always left to be done later, which we all know never seems to happen. One of the ways that some organizations deal with this is to use data warehouses and store information about validity and truth within the meta data repositories. More data, more work, more synchronization and more updates.

Yes, it’s better than redoing the research projects each and every time we wish to use the data, but not necessarily the best use of our time.So what can be done now? As we seek to develop projects that need or use the data, we can seek to reuse data that already exists where possible, and seeks out those who will take responsibility for keeping it current.

Easier said than done, but if we are to find those who experience pain in not doing this, it is possible. The other things we can do is build bridges back to the best known source of the information and attempt to decommission the areas we find not to be valid or reliable as we find them. There are very few projects on our books that are willing to incur the expense in doing this type of work, but as business and IT organizations, we need to treat this as some sort of “tax” or “levy” for using common information in the first place.

Organizations who are information intelligence focuses, those who primarily provide and use data to create revenue are the most able to gain from such a perspective. Problems we created years ago don’t go away over night, but the best way to eat an elephant is chunk by chunk, and if we don’t put this one on the menu, no one will ever eat it, and the pain will cost us far more over time than these one time taxes ever will!

I do however have to spend some time discussing content management – the credible side of information architecture. Many organizations have deemed these folks “librarians” of the content provided by content owners. Christina Wodke defines IA as “The art and science of structuring and organizing information systems to help people achieve their goals. Information architects organize content and design navigation systems to help people find and manage information.”

In it’s utmost simplest terms, Content management is an other name for publishing. The main objective of publishing is to get the right content to the right person at the right time at the right cost. Publishers manage publications. Key staff include contributors (authors) and editors. Authors create content. Editors decide what content should get published, and how much editing that content requires.

The web was invented by Tim Berners Lee as a publishing tool. HTML was created to be a publishing mark-up language. That’s the core reason the term web ‘pages’ is used. Content management is web-based publishing. The early stages of web publishing, like the early years of printing, were very dependent on the programmer, in the same way book publishers are reliant on the printer. It was a major technical feat to publish a large website.

Many people like to make their discipline sound complex because that makes them more valuable to the organization. Web publishing sounds very complex. I have personally seen business cards passed around at industry events that contain the title “Information Architect” to find out they may be the webmaster or the content librarian at their organization.

Web publishing technology is becoming streamlined and standardized. The focus is moving away from the tools and towards the content. The basic rules and concepts are the same as they’ve been for many centuries as they were for publishing, whether you are publishing to print or to the web.
A couple of new terms have come to light in the most recent years that never existed years ago, and here is where the architecture comes in.

Information architecture is the name being misused as many web publishers as the discipline of managing the organization and layout of web content. In print, editors have managed information architecture-type challenges for centuries (table of contents, indexes, etc.)

Why is IA Important? It’s all about the metrics, especially when we talk about public facing content sites. Each company who runs an online storefront, as well as the bricks and mortar variety will know that a good website keeps the buyers coming back, and makes it worth the investment in the first place.

Several metrics are key: Cost of finding information on the site – the time, # of clicks, amount of frustration or precision in finding something. Adversely, there are metrics surrounding not finding the item – success, recall, frustration, and alternatives which are harder to measure.

There are also some metrics that should be tracked in any content management solution, or for the web design. There is the cost of development (time, budget, staff, and frustration as well as the value of learning for the consumer (related products, services, projects, people.)

The latter of which has become known as usability, and there are folks that have now focused their careers on being web usability experts. This is an incredibly fast moving target, as styles, tools and technologies remain fast-paced release wise.

Personalized content is publishing is by definition an act of personalization. Your city newspaper has a specific scope and focus. Vogue is about fashion, and Sports Illustrated is about sports. So, if you edit for a website, you are by definition creating personalized content. Like so much about the Web, personalization has been vastly over-hyped and again, sold as a feature of content management tools.

Now further to metrics, we must design and consider the information environment or the context in which content is stored. In large companies, Enterprise Content Management projects are undertaken because they have increasingly global and distributed enterprises, multiple cultures and languages, and potentially have acquired several different companies. It would be nearly impossible to locate any document, so typically many copies are stored in department file systems before an ECM is included in the landscape.

It is complicated further by numerous intranets and web sites, and the fact that authors and users spread across departments. Often ownership is unclear. Many of the issues revolve around the centralization versus decentralization discussions.

IA consumers needs are both complex and diverse – they have diverse information seeking behaviors, needs and expertise. We are now approaching real information architecture, as we need to include storage, servers, networks, and database and application software to manage the content.

It is a large undertaking to study user behaviors to determine what will be best for an organization. Methods of organization of files and searching content that is not text-based becomes further issues. The method of categorization of the information is crucial. Content dictionaries should contain some or all of the information about the content being stored. Most content management solutions will provide for this type of indexing so that the content may be easily stored.

To provide you with some value for today’s eZine issue, here are some variables you should track in your homegrown dictionary, or data collection points if you are investing in content management software or a metadata store:

ID : The ID should be unique and descriptive. A little different than a unique ID in a database. It’s best if we use text within <a href> tag (link label), or you can use either the <title> of the HTML doc or headline for the content. These should be numbered in the data store, and can have an outline like structure as per levels in your web. e.g. 1.0, 1.1, 1.1.1

Description: A Brief description or summary of content, e.g. ” Specs for application X’

Link (URL/Location): Record the URL of content item you’re looking at – this allows you to (1) click and navigate from the dictionary and (2) capture the location of the document on the Web server. It should be noted that the URL should point to the location of the actual HTML file, not a symbolic link or redirect. Web Crawler results always need a lot of editing to be meaningful. Non-digital content should include the physical location such as the content owners name, phone number, location address.

File Type (format): Note whether the item is text, audio, video, image, etc. The size of the item may be included here.

Content Type: Different from the “topic” entry, the content TYPE tells you what kind of content it is, not what the content is about (“topic” – next attribute), e.g marketing content, navigation, data sheet, technical specifications, application, customer stories are all content types. Note: a pre-defined glossary or vocabulary is necessary so that data sorts and finds can be performed.

Topic: What’s the content about? No need for standard values–this is an open field for developing metadata (e.g. keywords), category labels for sorts, initial structure and content gap analysis. These are the keywords that are required by browser source views.

User group (audience): mapped to explicit departments, groups. This one may be harder to use and keep up to date, but well worth the effort.

Content Status: Exists, Planned, NTH (nice to have) : Does content exist? Is it definitely planned and accepted with resources available/committed? Or just a wish (no development plan, commitment)?

ROT: No, this is not the rule of thumb, but more status information. Redundant, outdated or trivial is a label indicating that the content should be removed from current site if possible, not migrated to redesigned site. It is often a placeholder in case of future need.

Responsibility/Owner: Name of person responsible for this content–who has primary/lead authority to approve or change it. This is a tough one, and your governance procedures will have to include this. This may become part of any data stewardship program that you may have.

Current status: This should be
C?= Create? (questionable, for future review and/or acceptance)
C = Create
D = Draft
R = Review
F = Final

Date Due: Date, time (e.g. “end-of-day”) FINAL is due for delivery, by mutual agreement

Date Delivered: Date, time (e.g. “end-of-day”) FINAL was delivered, by mutual agreement

Contents: Any/all pertinent information not relevant to proceeding (left) columns, e.g. broken links, images; characteristics of page; management of page; quirks of content ownership, etc.

Sitemap Page ID: Architecture diagram (sitemap) component #–destination for this content. E.g. 3.2

Wireframe Type: Type of wireframe (template) appropriate for this content. E.g. Type C. Note – we will discuss Wireframes as they pertain to GUI design at some later date.

Location within wireframe (template) – specific text field, column. E.g. text ‘field’ 2

An Information Architecture is the “blueprint” of an enterprise expressed in terms of information models which show what information resources are required;  their processes and information, and the infrastructure and processes required to manage and store them.

Information architecture defines how data is stored, managed, and used in a system. In particular, a information architecture describes how data is persistently stored and how components and processes reference and manipulate this data.  The information architecture describes how external/legacy systems will access the data, and includes descriptions or diagrams of interfaces to data managed by external/legacy systems.

Last but not least, the information architecture includes information regarding implementation of common data operations.

Why this article now?  What is really new in the last 5 years?  I was recently horrified when researching trends on IA for my recent Architecture Boot Camp course.  The first page of results when searching on “Information Architecture” on Google referred to website content management.

Information Architecture is NOT website content management and website content organization, although these are an important part of it.  Another recent trend is to include directory data structure and identity management within IA — caused by the proliferation  of data driven security access and LDAP databases supporting our applications.

In a nutshell, the over simplified most prevalent benefit of Information Architecture is the enablement of rapid business decision making.  Without linkage to the business architecture, information architecture really can’t exist on it’s own.  We must first understand business architecture, and then use it to create our information architecture.

A quick laundry list of the levels included within a mature InformationArchitecture:

Highest Level: An information environment, which includes an organizational  culture around information, as well as information strategies.

Second Level: The Enterprise Information Architecture which includes Information principles, rules for information governance and sharing, information content design, and linkage to the Business Architecture

Third Level: Information Management which includes Data Stewardship, Information Security and Access tools, processes and procedures, Extraction and Transition and Loading Strategies, Database Server Administration Policies & Guidelines, Data Quality and Integrity Rules, Data Definition Standards,  Dictionaries and Content Indices.

Fourth Level: At the most granular level, the Information Architecture contains the information architecture made up of databases, data
warehouses, logical, physical & data warehouse data models, backup and recovery procedures, database execution scripts, meta-data management, data performance and auditing, etc.

To conclude today’s message, here’s my tip: Look beyond content and use this as an example that a simple “Google” search does not provide the true definition or meaning behind a technical topic in the first page of results.  Databases, models, structure and governance were around far longer than web page content and all are needed to even store the content!

The Enterprise Information Architecture is the center most intersection of this diagram.

This is where all high-level planning activities and artifacts are created.

The three domains – Business, Users and Organization contribute data and context to the activities.

* Users: (who they are, what their information-seeking behaviors and needs are)
* Content: (volume, formats, metadata, structure, organization)
* Context: (business model, business value, politics, culture, resources and resource constraints)

Highest Level: An information environment, which includes an organizational culture around information, as well as information strategies. The strategies include planning and maintaining relationships from business to information through structures and technology. It also includes data governance at the highest levels.

Second Level: The Enterprise Information Architecture which includes Information principles, rules for detailed information governance and sharing, information content design, and linkage to the Business Architecture.

Third Level: Information Management which includes Data Stewardship, Information Security and Access tools, processes and procedures, Extraction and Transition and Loading Strategies, Database Server Administration Policies & Guidelines, Data Quality and Integrity Rules, Data Definition Standards, Dictionaries and Content Indices.

Lowest Level: At the most granular level, the Information Architecture contains the information architecture made up of databases, data warehouses, logical, physical & data warehouse data models, backup and recovery procedures, database execution scripts, meta-data management, data performance and auditing, etc.

We need to understand what the data will look like and what is needed before we can design. After all – information technology is about information and always about moving it around. We manipulate, massage, analyze and display it – what impact does it have?

Today I am trying to help clients come up with a new way to allocate files based on a bunch of business parameters. Over the years, they have bandaided the process, and morphed it based on many business needs that have nothing to do with the allocation itself. It was almost mind numbing to walk through the paths and rules that had been added over the years. I’d get
frustrated and start over and over going back through the data.

Eventually I thought “this is crazy – what are we really trying to do here, and what is the bare minimum of information we need?”. Simplifying things brought clarity. After I weeded out all of the special cases, I found that the solution was rather simple – there were two basic methods, with a third method that could be applied to one of the first two based on a third parameter. Voila – done. Add a bit of history logging to enable lots of great reports on performance, volumes, etc and we have a great solution that everyone understands.

There – that’s it – my first thought of the day – this is going to be addictive to be able to organize all of these Architecture thoughts in short bits, as I have them.

Happy Architecting