In this article, I’d like to talk about Information Architecture. In the past, I’ve been hot about the misused term “Information Architecture” when only referring to content andlayout of websites. This week I had a reality check of what it’s really about.
I have clients that I have been helping to design some future releases of an automated business system. One particular component requires entry of healthcare billinginformation. We created some GUI prototypes after some site visits, and gleaned therequirements gathered for the past three years. My job is to visualize the future state ofall of this. What is the single most important thing an architect can do? Architect in the ability for change and architect out the restriction of change.

We discussed and squabbled over past restrictions, and what could and was likely to happen over the next few years internally. We it came to the value of entering healthcare information, it was necessary for me to remind them to look forward. Even if previous attempts to collect more data have failed or have been rejected, we, as information architects, must architect in for the ability for data structures and environments to absorbfuture change.

My example includes today’s methods for Pharmacare programs to directly bill insurance companies. Even if such a system is primarily manual today at an organization, one has to be reminded that eventually all pharmacy information will be transferred electronically to those who need it. Eventually, each area of healthcare will be automated in such a way
that billing information will be received, validated and processed, rather than entered from invoices.

Putting on your architecture hat, think about all of the related architectures that should be considered to ensure your soon-to-be architecture will enable change. On the business side, what are the business processes that are creating the most grief? Are there endless enquiry telephone calls? Ensure you architect in the ability to both access this information and input it, or some view of it, electronically — eventually almost everything will become self-serve or SaaS

When selecting the database system and environment to support this, what will your current systems handle? What about B2B bridging? If you were to pass data between suppliers, vendors and your companies, can your database security handle it? Are there business resources willing to step up and be the guardians for this new data? Are there business and process staff that can achieve benefit from what is collected?

How about the technology architecture? Is there security on the servers which will accept or send data? Is there the ability to handle the type of load an online enquiry system might contribute? When designing the databases, are all of today’s business data fields captured? Can ability to capture them be added to the existing set of data and “floated by” stakeholders to determine whether or not there is value to them in doing so now?

What about the application architecture? Is there anything you’ve built before that can be adapted to handle the type of data capture you are looking at today? Are the classes capable of maintaining this data, or do you have to start from scratch? Do you have class models to adapt? Build upon?

These are some of the considerations an information architect must make when designing with the big picture in mind. These are future considerations of impending standards, methods of data capture and requirement for analytics that we must demand of ourselves today. Information Architecture is not just ensuring that your “page tree” is balanced, and your content management software can handle the load.

At its most basic definition, information architecture is the construction of a structure or the organization of information. 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. Read the rest…

The City Planner

If you’ve been around architecture, this one is old hat. I’ve seen it used and reused many times. The metaphor of the City or Urban Planner must be the most popular used, as the timeline, budget, size, complexity and vision parallel to that of Enterprise Architecture.

There are few city planners that are fortunate enough to have a clean slate, other than those who win the proposal of a lifetime to build a huge urban community in the desert or something of that nature. City planners are usually heavily constrained by what is already in place, what has been built, and they rely heavily on the coordination of many ongoing and future projects. They must forecast costs well into the future and rely on statisticians to estimate growth, capacity and the like.

This metaphor works to compare to Enterprise Architecture as it includes the necessity to follow the cultural and trendy desires in design, fashion, the environment as well as complicated areas such as dynamic building codes, legislation and our ever changing weather patterns.

I’m not going to belabour this metaphor, but if you haven’t seen this metaphor, it’s worth checking out again. Visit the site, and resubscribe if you’ve lost your link or copy.

Metaphors in Business Architecture

The Company Directory and Handbook

This one is a bigger reach, but if you consider a large companies’ personnel directory, or even a handbook on departmental responsibilities and goals, you will find such information as organization charges, lists of departments and locations, descriptions of business responsibilities and potentially business processes.

Some businesses will have shelves and shelves of business processes and guidelines. Even more common now is company intranets packed full of form templates, processes, guidelines and potentially legislation and laws governing operations. The business architecture is much more detailed, but this is a great way to start – it’s the description of the who and what in the business.

Metaphors in Information Architecture

The Library

Everyone who has worked with databases or has tried to describe one to a layperson has used the metaphor of a filing cabinet. When we are talking about traditional Information Architecture, that which doesn’t just describe a website or content management system, we can use a library as a metaphor.

The library metadata or systems to govern and catalogue information. This is is the Dewey Decimal System, and some ‘servers’ full of information on the products, searching and cataloguing software, as well as some booking and/or registration mechanisms. The systems are put in place to only intentionally store duplicate copies of books for the popular items, or items that might want to be stored in multiple locations.

Technology brought into library cataloguing systems has allowed patrols to search by any number of keywords for books that meet their search criteria, much the same as the way content sites are stored. Keywords or metatags are stored with each document, allowing search engines to find the appropriate materials.

Duplicate filing systems are used in multiple locations to allow patrons to search for items at either their locations or others. This is much like the sitemap, or in the case of the traditional IA, the design of indexes, metadata and datamarts. The searching software allows patrons to find products based on keywords, much like content management software and it’s components will do the same.

Now on a reach, we can mention that the librarian must seriously consider the impacts when contemplating reorganizing or reindexing when wanting to add space for storage of the books, much like our system administrators do when adding new server, disk space or racks. Adding a new floor, shelving unit or even facility spreads the products out thinner, but makes room for new additions.

Now what about valuable old books and artifacts? Are then kept in a fireproof facility? What about old newspaper clippings and magazine articles stored by topic or title? These might be put away on microfiche in a library, and in today’s world, we’re employing enterprise content management and document imaging systems to keep these items catalogued, organized and stored safely.

Metaphors in Technology Architecture

The Set of Blueprints

If you’ve ever built a house, or have seen a set of plans or blueprints, you have a perfect metaphor for technology architecture. The typical set of house plans has several sheets of very large paper bound together and typically ‘rolled’ up for storage and travel.

The general contractor and surveyor will use the elevation plan to mark the land for excavation and then set forms for the foundation. There will be sheets for basic wood framing of rooms and floors, and then framing details for things like stair wells, niches, closets and alcoves.

A blueprint which includes details on the systems in the home or building will include markings for telephone, cable, vacuum, thermostats, door chims, ventilation and ducts, smoke detectors and possible ceiling speaker systems. A detailed electrical blueprint sheets will be included in the plan for the electrician to set up all of the various types of power circuits, outlets and switches that are included in the home.

More system diagrams and blueprints will exist that include plumbing, pipes and exhaust systems. Finally, floor plans and elevation sheets will be included that show the look and feel both at a one dimensional level as to where the rooms and doors will be placed, as well as the window openings. A three dimensional elevation will show the views of the home, as well as to list what types of exterior coverings will be used such as stucco, brick, shingles or siding.

If you liken this to a technology architecture, we are most likely to have a collection of models and diagrams. We have network diagrams, hardware diagrams, diagrams that show our intra and internet configurations. We most likely include layers that list our middle layers and servers, and often diagrams of servers that list the types of software components that sit on each of the servers. We depict presentation layers on the top that list the types of components.

Each layer may include services that are included in this topology. We may include an intersecting layer that provides systems such as security and our operational systems to maintain all of the technologies.

If there is any bigger time waster in IT, I’m not sure if there is one larger than redundant data. At the core of it all, IT is about collecting, storing, retrieving, moving, transforming and reporting on data. If the same data is stored in multiple places, let’s say two or three, that’s twice or three times the amount of effort to perform all of these functions.

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!

Everything you read recently declares: “It seems like all roads lead to business intelligence. For organizations that have started business intelligence initiatives, they soon find that they have huge storage issues.

Typically, DW projects are initiated without a large concern for much more than the software required for actions such as extraction, transition & loading, modeling and report generation. Building and maintaining such systems require you the architect to either contract for or perform design work to ensure that there is focus on deploying user-driven data warehouses that are based on an enterprise architecture and are scalable, fast, available, and secure.

Integration is needed between operational and analytical systems to support the applications. Six key business goals are needed to ensure that the business intelligence applications that bridge large packaged software applications and data warehouses:

1. User-driven. Unless data warehouses are designed and architected to address specific business drivers, they will not support the strategic applications considered key to your organization.

2. Architected. All business intelligence initiatives should be supported by a common enterprise architecture that standardizes processes, components, and tools. The architecture needs to provide a common systems and application infrastructure that makes it easy generate new data marts and modify and leverage existing applications.

3. Scalable. When you architect a user-driven data warehouse, it typically grows fast, both in numbers of users and volume of data. Huge amounts of detailed data come from both packaged and custom applications that users may want to analyze inside a data warehouse. The correct servers must be included, as well as enterprise storage to manage terabytes of data.

4. Fast. Users always want speedy responses to their queries, but this is always the expectation with any system. Massive systems require powerful servers designed for precisely the purpose of handling complex query workloads.

5. Available. Data warehouses supporting analytic systems will be continuously updated. Users and applications will want real-time information from the previous day, previous hour, or even the previous minute. Loading and backup and restore capabilities must be planned in order to minimize the impact of any unforeseen outages.

6. Secure. If you must open up a data warehouse to external parties and link them with multiple heterogeneous systems, close attention must be paid to security issues. Access control and encrypted data are also considerations that you need to make.

I’ve been known to rant when I see the pages and pages of links that come up when one searches for “Information Architecture” and all they get is content management garble. I will have to succumb to the fact that when dinosaurs are extinct, the kids that survive will be the ones who believe this stuff and gone will be the good stuff like information models such as logical and physical diagrams, server diagrams and data dictionaries. All the makings of mature information architectures.

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

Everything you read recently declares: “It seems like all roads lead to business intelligence. For organizations that have started business intelligence initiatives, they soon find that they have huge storage issues. Read the rest…

Let’s get back to it – the business architecture defines the future state business design and strategy, and last week we talked about it. This week we are going to talk about ways to kick off the information architecture. Both business and information architecture are the engines behind applications and technology investments. The information architecture is articulated in the terms of information models and key artifacts.

First Steps

Our first step is to figure out which models we can create from the information we have, and which artifacts can also be completed. Last week we talked about creating a high level use case diagram (at the business level), or a domain model. In either case, we have some grounds to create a conceptual data model. A conceptual data model differs from an Entity Relationship Diagram (ERD) in that only the very high level business entities are modelled. If you have crossed the line to object oriented modeling with UML, this can also be created with Entity Classesand UML symbols in a class diagram. If you are using Rose, create a package for the Conceptual Model and start creating.

Very elementary

The model should show very elementary business relationships, enough that would align with business verticals or departments within the company. If you are lucky enough to have a business strategy, there may be information in it that will give you further hints to the desired changes to the data landscape.

The enterprise information architecture is driven by the business architecture, and it requires a disciplined process to detail the enterprise’s information strategies, its extended information value chain and their impact on technical architecture. Now we should talk about artifacts. They would mirror the business architecture. We need a requirements vision statement, the Conceptual Architecture (we just talked about that), and current and future state information models.

Describe Key Information artifacts of business events

The models should describe the key information artifacts of business events, models and information flows. These should include logically consistent information management principles. The information should start a design that would enable rapid business decision making and information sharing. Other artifacts should describe the processes and details around information acquisition, classification, storage, retrieval, editing, quality control, presentation, security, distribution

The principles should directly map to the business goals and strategies laid out in the business architecture, although some will be high level basic principles that are too generic to map. If you wish to start describing information content, you can do some high level content mapping. If you wish to get a start on the physical implementation
on the current architecture, you can go so far as to diagram your server and database environment as it stands today, as well as to inventory the tools and services you utilize.

Information Architecture Links Most Easily to Business Architecture

The information architecture is the most easily linked to business and I’ve just given you a brief elementary start to get you going. It is far more complicated than this in the fullest detailed architecture, but these are actual pieces that are key and need to get completed to come to the final state of maturity anyways.

Information architecture is of critical value to an organization, and will not come without a whole bunch of hard work. It is incredibly worth lots of forethought to structure, layout and future usage when designing target state. Thoughts about any needed migration are also welcome at anytime in the process, and documenting the thoughts now, rather than losing them will pay off later.

At its most basic definition, information architecture is the construction of a structure or the organization of information.

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!

To describe a Mature Information Architecture the following is likely present at these levels

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.