“All is about money. No, all is about information” said one of ARIS clients opening his speech at one event. Even the primary goal of money itself is to carry an INFORMATION about their value.
If we consider a process, what happens in a typical process? Well, the purpose of a process is passing an INFORMATION between involved resources (human and IT) in order to create a value in form of goods or services either internally and\or externally.
If we consider IT, we like to speak very often about technologies; however the abbreviation stands for Information Technology that means a technology storing and exchanging INFORMATION.
Sometime ago I promised to write about the Information Architecture, the architecture domain that usually lives its own life and is not really integrated into Enterprise Architecture Management System. Enterprise Architects instead focuses on applications, underlying technologies and sometimes (sic!) their support of business on an enterprise. And there are a number of reasons why Information Architecture is often not covered at all or just touched very high-level in EA initiatives. In my opinion one of the main reasons is politics behind; data modeling and management established itself long, long time ago and there is a whole generation which started their mastering of data models of monolithic self-developed business applications and are not really keen to make that valuable enterprise asset enough transparent for other stakeholders. Data encapsulation by ERP providers should not be forgotten. And so on.
However the fact is that in the world of small-scale, flexible business apps built on modern BPM\SOA platforms, information plays a crucial role. Absence of common language between business units (information) and common language between IT systems (data) leads to complicated and delayed solution implementations, constant data conversions negatively impacting on performance and cumbersome change management with avalanche effect of operational systems.
Standardization of information definitions both unstructured and structured is the key stone for business processes, business rules, application integration, business datawarehouse deployments etc. However how should we structure information in an Enterprise Architecture Management System like ARIS? There is an approach we have elaborated some years ago which applies layers from Model Driven Architecture of OMG:
This approach splits the Information Architecture between:
- Computer Independent Model (CIM): Business Information Model, highly conceptual description and classification of both unstructured and structured information in form of Business Terms or Objects;
- Platform Independent Model (PIM): Common Data Model, logical definitions of structured data referenced (common) to all solutions within an organization or industry domain in either relational or object-oriented form. Shared Information Model (SID) from TMF (Telecom) and Common Information Model (CIM) from IEC (Electricity) both are good examples of such data models.
- Platform Specific Model (PSM): logical and physical data models specific either to:
- certain packaged applications (often only externally visible), self-developed applications (external or\and internal) ( Application Specific Data Models)
- certain integrating solutions (EAI\ESB or even WFMS\BPMS) (Integration Specific Data Models)
- certain database management systems (Database Specific Data Models)
- certain datawarehouses (Datawarehouse Specific Data Models)
Obviously everything that is computer-dependent cannot handle information in unstructured format (I am excluding document-oriented workflows) and therefore Data Architecture maps to the framework as shown below:
Data Architecture natively covers both Platform Independent Model and Platform Specific Models. As stated above Information Architecture encompasses both structured and unstructured data and that is why Information Architecture includes Data Architecture.
In the world of architectures we´ve used to speak about reference architecture(s) and architectures specific to certain solutions. Certainly such models as Business Information Model or Common Data Model cannot be physically implemented, so this content serves as a reference for solutions implementing the models each in their own way. Solution Architectures are specific and include one of more physically implemented data models. You may argue that Common Data Model is implemented by an ESB in your company. However if your company has a “two-vendor strategy” and next to ESB from webMethods standardize on ESB from SAP for SAP specific components, would both of them implement the same data model? Hardly. So you may need another layer on the top of these two Integration Specific Data Models (wM and SAP) – a pure logical Common Data Model.
Comprehensive Information Architecture requires comprehensive modeling support. This kind of support would simplify communication of current state of the architecture, future state and planned changes. Hardly a management of data models in form of XML files or Excel tables will be sufficient enough even for a small-scale shop. Brief overview of a metamodel for such a modeling support, focused solely on elements belonging to information architecture domain is shown on the next figure:
Business Terms\Objects are high-level concepts from Business Information Model which can be mapped to elements from Common Data Model. Data Object represents a part of object-oriented information modeling e.g. in form of UML classes and Data Entity corresponds to relational way to design data models. Certainly both include attributes and build up a Data Model. Data Views and subsequent Data Messages are scoped (restricted) views on a Data Model and a Data View, respectively. Data Model, including Data Objects\Entities, Data Views, Data Messages can be correspondingly represented in solutions, specific to certain applications or services or integration platforms or databases.
The metamodel above can be easily mapped to ARIS method concepts: Technical Term, Cluster\Datamodel Class, EntityType, Attribute, Table etc as shown below. Those, who are familiar with out-of-the-box ARIS modelling could easily recognize these concepts below:
Definitely the value of ARIS as Enterprise Architecture Management System is not in a pure process or application or information portfolio modeling, but in the ability to relate these different architecture domains to each other in their current and next states and being able to communicate these deliverables to stakeholders. Information architecture artefacts being properly aligned with business, service, application and technology architectures support such roles like Information and Data Architects or Business & IT Analysts as well as dozens of other roles benefiting from an access to a single integrated architecture and design repository.
