Information is truly the bridge between business and IT. While collecting and modeling business capabilities and business processes we are using information as inputs and outputs for business capabilities and processes. Information architecture is also heavily used in application architecture. We collect and model which applications manage which information, how information flow between applications, how applications and technology enforce information security, etc'. Actually it is not surprising that Information is the bridge, applications are created to support business users functionality and information manipulation. In this post I'll introduce what is my approach to Information architecture. I'm modeling information architecture in three levels: conceptual, Logical and Physical. Conceptual information modeling is an effort to collect the main information types (something like subject areas) which is used by the business in order to reach enterprise's goals and objectives. Conceptual information example could be a Customer or Settlement. Logical data modeling is an effort to break conceptual information into logical entities. Each entity resemble set of data that is used by the business as one unit. Logical modeling also include capturing relations between entities and setting non-functional attributes for each entity (availability, security, Audit and control, Availability, backup, etc'). Physical modeling includes databases schemas and the relations between physical tables and logical entities.
Information architecture also include modeling of information flow between business capabilities and modeling of information flow between applications. Mapping between information and applications that own or responsible for maintaining information entities concider to be part of infrmation architecture as well.
Identifying and modeling information has a lot to do with business capabilities and business processes. While collecting and mapping business capabilities (in different hierarchy), I tend to collect conceptual and logical information, which used as input and/or output for capability. Usually I'm using the conceptual information for capabilities in level one to three of the capability hierarchy, and logical information (entities) for capabilities in the fourth and fifth level of the hierarchy. I'm also using capabilities hierarchy to get relations between conceptual and logical information.
Setting logical information (entities) non-functional requirements also have a lot to do with business capabilities. Actually the non-functional attributes of logical information are inherent from business capabilities that are using information entities as inputs. If, for example, given business capability need to be available 24*7; all the data that this capability is using as an input/output should be also available 24*7.
Business capabilities and business processes are also helpful to set information security attributes. Accsess rights (Read, Delete, Add, Creat) and information compartmentalization (Show part of information on a need to know basis) can also be set by walking through business processes and capabilities and finding out who is using which information and how.
I'm using BPMN to model information flow between business capabilities and application architecture interfaces to model which information is flow between applications or products. Information flows are important components of information architecture for two reasons. 1) Information flows helps to understand how information interchanged between people and applications. 2) part of the non-functional attributes of information are impacted from the interaction of certain information in information flows.
Adopting logical information model, as the standard way to exchange information between application and people, is consider to be good practice. Using this approach applications know to get and return logical information entities, but internally they can break or unified information entities by their internal application schema. Such approach creates a common language between applications and different roles in the enterprise.
Mapping between logical entities and physical tables also help us to better understand our enterprise data. Logical entities resemble the way business work with data and it also serve as common language of applications. Mapping entities to tables helps to find and manage duplicate data as well as to get better understanding on impacts of changing certain schema structure.
