Information is an organizations biggest asset and yet so often it is not treated as such. Information Architecture is the architectural discipline that not only brings efficiencies and reduces informational risks and liabilities but enables Analytics, Artificial Intelligence and Machine Learning. Components that will give insights that create competitive advantages.
The information architect is responsible for architecting the information domain and I want share some of my thoughts and techniques to tackling this space.
Let’s start by exploring what is within the information domain. I look at information from the perspective of three categories: content, data and knowledge.
Unstructured information and includes: files, emails, documents, web content, records, publications…
Structured information and includes fields within tables…
Putting context around information…
It is one thing to have tools so that you can create, protect and use information but that is only the tip of the iceberg for this domain.
Let me back up a bit…
I want to travel back in history to really help get this concept across.
Creating information used to entail sitting down and typing or writing on a piece of paper and then taking it to a record clerk to file it away.
The record clerk would:
- Create relationships among information,
- File it so that it could be found,
- Destroy it when it was no longer needed, and
- Protect it so that it was only accessed by the appropriate personnel.
When you needed information it involved another trip to the record clerk.
The record clerk was responsible for a number of tasks but it was manageable because it wasn’t as easy to create information not to mention there was only one type, paper.
Travel forward to current day… it is soooo easy to create information and there are so many different types now.
Gone are the days of the record clerk, and in their place technology has been created to replicate the manual steps, for example:
- Document Management systems were created to manage multiple copies and versions of documents,
- Record Management systems were created to manage when something needed to be destroyed,
- Security Classification was created to manage protection levels, who could access what,
- Search Engines were created to find and access information across multiple storage locations,
- Archiving technologies were created to improve performance,
- eDiscovery was created to find relevant and reliable information for litigation,
- Metadata functionality was created to let systems know what to do with the information,
- … and the list goes on and on.
There is no way every employee can go through the training of a record clerk, to know which system to use for what, to build the relationships needed between information, and to classify and tag information so that can be filed, found and protected. Even if they could, information has a lifecycle and requires actions to be taken at various stages within that lifecycle. It was much easier for one individual or department to manage because they had their hands on all of it.
As you can see the easier it is to create information the more complex Information Management or IM becomes. The technology that has made it so easy for us to create information has now caused the iceberg below the surface to grow.
Honestly a big part of our problem is we continue to try and manage information using the same paper mentality and use technology to replicate the original manual steps. Information Management is not a “technical thing” and I continue to challenge the traditional IMIT thinking.
I have gone into organizations that say they are paper free but when you look under the hood they are still operating in a paper based environment:
- They are storing PDFs which are just copies of paper and storing them in file folders.
- Using naming conventions similar to a filing cabinet so that they can find information.
- Buying bigger monitors and setting up multiple monitors so they can read through PDFs to find the information.
- Printing off PDFs that have be scanned into electronic repositories.
Now that you understand how HUGE this area is and some of my thoughts behind the whole issue watch the following clip to understand how I introduce the Information Architect.
This clip is a subset from one of my lessons within the course on How To “Do” EA – Part III. The lesson focuses on how the Information Architect supports the Enterprise Architecture Practice and sets the stage for IM – the ability to manage and monitor information and determine when something is “unhealthy”
Subscribe to get notification for my next post where I discuss the Business Architect versus the Business Analyst.