Information Architecture - The bridge between Business and IT

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.

1 Comment

  • Several interesting points here.

    Firstly some history of terms. I've been an "enterprise architect" since the mid-1980s, but before this term gained precedence, it was called information architecture.
    The term Information Architecture was originally coined by Richard Saul Wurman in 1975, to mean .....
    Enterprise Architecture emerged around xxxx, and gradually superceded the term Information Architecture.
    In parallel, information architecture often came to be a synonym for data architecture, while more recently, Information Architecture has been used in a narrower sense in relation to the web (the Polar Bear perspective).
    The evolution and crossover between these terms has caused a great deal of confusion and discussion over the years, and will probably continue to do so, so it would be useful to find a way to avoid this minefield.
    More interesting is the discussion around why we build an enterprise architecture, and what do we hope to achieve by doing so. At the risk of being too simplistic, the prime reason we architect is to make effective use of information within an enterprise, supported by, among other things, our use of information technology.

    To put this another way, we architect information first, and then architect the supporting technology. So going back to Natty's opening sentence: information is truly the bridge between business and IT. Just as a building architect works with spaces, creating boundaries around space through architectural construction and form, so an enterprise architect works with information - with the limitations and constraints being imposed largely by information technology. [You can find this discussed in much more detail in my book, Information First, which is based around the idea that we architect information first, and then support that with our use of technology.]

Comments have been disabled for this content.