Information Engineering

At MIDIOR, we use the term information architecture to refer to the various roles and processes related to making data more useful to the organization, whether that be through better integration and management, greater attention to quality, better definition of requirements or a host of other data maintenance activities.



Today, data is the raw material of every business, whether it is for managing internal processes, such as manufacturing or sales, or as a key component of products and services delivered to customers, as seen in financial services, media, or professional services industries. The vast amounts of data available to businesses present opportunities for better informed strategy and decision-making yet, we find that poorly organized data is the Achilles' heel of many information technology initiatives.



Consider that many companies invest billions of dollars in CRM systems that promise to deliver greater access to and understanding of customers, or in ERP systems that consolidate systems and integrate business processes. Yet many of these initiatives are perceived as failures after months, if not years, of investment and effort. Then, the finger pointing starts and the limitations of application software or project management by the systems integrator are often blamed for the lack of anticipated results



Where are the librarians?

In many organizations, the primary focus turns to what data is required for the applications, rather than the more fundamental issue of design of the data flow itself.



At MIDIOR, we apply a systems and engineering perspective to data organization and management and when we start every information architecture project we ask our clients, “where are the librarians?” If the answer is, that’s an add-on to another functional responsibility, perhaps the programmer’s, that’s the wrong answer. In every organization, resources need to be dedicated to understanding the design, definition and mapping of the data.



We find that the missing ingredient is almost always the top-down design of information requirements. Important questions that a systems and engineering approach would demand answers for - what data is needed, where that data will be sourced, what level of quality meets user expectations, how the data will be maintained – receive scant attention. And, realistic projections of how much it will cost to maintain the data or identification and allocation of resources to accomplish this, are rarely factored into initial projections.



Based on our experience working with a variety of firms developing new products and services, we recommend that clients start with what appear to be simple questions, such as:

 

• What data is needed to complete this task?
  
• What data is needed to deliver this service?
  
• Who is the expert in this type of data?
  
• Who is responsible for that data?
  
• Where does that data come from?
  
• Is that a trustworthy source?
  

 

Attempts to overcome the lack of fundamental information architecture come camouflaged in many important sounding names – business intelligence, data warehousing, federated search, information lifecycle management, semantic objects. Many of these can be useful technologies but they should fit into the framework of a detailed understanding and definition of what data is needed.



So your product is a table.

Let’s take the example of data requirements for building a simple product such as a table. As the librarian considers the top-down design of information and the product manager thinks about his or her tables, how much information is really necessary? Your product line consists of nice tables - six styles, four sizes of each style, nine colors for each style and three different finishes for each color. How much information do you need to know to specify which table you will build and ship? How much information do you need to know about your paint options to keep your catalog descriptions current? Do your tables need to meet regulatory compliance and what information will you need to provide? What categories of information do you need to build out the price list? You want to work with online catalogs and fulfillment centers and they need to know about your inventory. Your manufacturing group wants to know about your forecast. Your boss wants to see how gross margins will be impacted by the new pricing scheme for distributors. You are selling tables in Afghanistan so the assembly instructions need to be translated into Urdu. Now, how much data do you really need for this “simple” product and how will you keep it organized?