The enterprise architecture online group

Current Articles | Categories | Search | Syndication

Monday, August 03, 2009

Information Architecture - The bridge between Business and IT
By Host Account (host) @ 4:03 AM :: Article :: 3 Comments :: 1135 Views

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.

Comments

By Rick 'RickB' Bosworth @ 8/4/2009 7:54 AM

I agree that Information is one of the keys to to communication not only between business and IT but between any business units in the enterprise.

My approach is very similar to yours with a few modifications. I also advocate the 3 levels of information modeling. I have stopped using formal data models at the logical level in favour of a data dictionary style of documentation. I find that the DD style model (which is thankfully supported by my tool of choice) has several advantages over the more formal data model:

1) old names familiar to the business can be retained in the DD and pointed to the new "official" names which eases the transition to the new official language
2) "things" in the DD model do not care whether they are entities or attributes and don't have to change between the 2
3) derived and compound attributes can be defined in the DD model whereas most data model methods don't support them.

I also model interfaces at three levels. At the Conceptual level the interface just depicts the fact that data is exchanged. At the logical level business data is defined for the interface(s) by using data from the DD. At the physical level actual tables & columns from the DB models are mapped from the source to the target, generally through an intermediate format that uses a standard message format.

Rick

By Amanda 'amandaxu' Xu @ 8/4/2009 2:40 PM

Both of you are very well said here. My approach is to start with questions /problems to be addressed, types of queries and reports to be supported and generated, etc. Clarify and define basic question like, e.g. what is the value proposition for an application?

In other words, I would start with the following:

1) expected outputs;

2) expected user interaction and types of activities to be supported by the application from the perspective of six users' views defined by something like Zachman Framework;

3) check into:

3a) user satisfaction requirements, etc.;
3b) competitive business advantage requirements according to types of domains and businesses;
3c) capability maturity requirement defined by industry standards, e.g. CMMI, COBIT, etc.;

4) perform capability planning, etc.

Aftwards, I would get into input analysis, information flow & process analysis, output analysis, etc. and finally come up with conceptual modeling, logical modeling, physical modeling, etc.

By jacques 'jrossard' rossard @ 8/5/2009 3:22 AM

I totally agree with you. I particulary like the concept of capabilities which is too often, forgotten.

I just want to do a comment. Your modelization souds good, in my mind, in a limited organization. It was right till the 80's - 90's when the boundaries of the companies where well defined and it still ok with no so big companies.

Today, organizations are biggest. And what is organization ? Is it the IT organization inside a company (some are bigger than companies) ? The business organization ? Well, even this level moves. We deal with the IT organization, inside a company which belongs to a group ... ok, everybody is still led by one strategy even if routines, capabilities and processes could be different. Well, with some very strong modeling stuffs, I agree, it is still feasible.

But nowadays, the business boundaries are completely different than the company or group boundaries. Look at some examples : Is Nike doing snikers ? Not really, they don't have factories. Is Michelin doing tires ? Well, a little but the core competencies are in marketing, communication, R&D and design. Same for l'oreal, coca-cola, renault, etc....
Ok, I speak only about big groups in private sector. But it's the same with public sector and it begins to be the same for SMEs because they work either for the big groups as a supplier or either they work in a network with others to be competitive in the market. And I don't begin to speak about the stakeholders theory ... In short, you are right to speak about the bridge built by information and it is more right that the bridge is more important between all the organizations. And, in this case, they don't have only one strategy.

Now, we know the issue. Can we do enterprise architecture to these new structures ? Well, in France, we used the notion of urbanization, like in the building business. Architecture is perfect for an organization level. Urbanization is mandatory when you want to be closed to the real business and you want to improve efficiently an Information System serving the strategy and which can answer to the market.