Tekes – the Finnish Funding Agency for Technology and Innovation conducted a research (PDF 1.0mb) about state of the enterprise architecture within 25 large Finnish companies. The result was both interesting and sad at the same time! Information architecture was mostly missing from these organizations. How is it possible? Don’t we need information architecture?
I believe that information architecture is the most important task of any enterprise or IT architecture work. I could not design requirements for any application without solid information architecture. Too much emphasis is put on process architecture with the cost of neglecting information architecture. Why? Is it because of lack of understanding?
People find process design “easy” compared to information design. Typically, during requirements collection phase we ask 1) “what” are you doing 2) “how” are you doing it and 3) “with what” are you doing it. However, we should also get to the questions of 4) “what do you need for doing it (inputs)” 5) “what is the expected output” and 6) “what are the output quality metrics”!
Even if all the above questions are answered we have just completed the “requirements list” part of the problem. This is where the hard stuff starts! Here most projects fail! Why?
Information has its own structure which processes do not “expose”. If we only look at information through processes we do not see the structure of the information. So, what defines the structure of the information? For example “contract” information structure is defined by law. This means that there is nothing “technical” about contract information model. Who should then be responsible for modeling it? We argue that business people should be modeling it, but the problem is they do not have methods or experience to do it. Stuck? Not yet!
The answer is to have experienced information modelers who understand information relationships in depth! Typically, most information best practice initiatives only get to the point of understanding main domains of enterprise information model and the key relationships between them. However, there is far more information exchange use cases between processes than what typically appears at first. The problem with most master data management programs is that they concentrate “mapping” information between applications to align terminology. However, they do not get to the point of creating structure of the information. Why the structure is so important?
Structure of the information is important because it 1) it covers the relationships between information 2) it helps to create common terminology 3) it exposes the nature of the information. This last point is crucial. By understanding nature of the information, we can categorize information better and find commonalities of information. Let’s take an example. Service Level Agreement, software license, invoicing policies and account are all types of contracts. They have very similar information and information structure between them. WE CAN SAVE LOTS OF MONEY in understanding this nature of information and by investing a lot less for managing this information.
Remember that applications are either storing information or processing it. The more we understand about our information models the more we will save money by buying more fitting software, integrating less systems and designing better use cases.