Information Mapping – Business Blueprints are an essential instrument in every business architect’s toolbox. The Guide to the Business Architecture Body of Knowledge (BIZBOK Guide®) defines four core business architecture domains: Value Streams, Capabilities, Organization and Information.
In previous blogs, we discussed Value mapping, Capability mapping and Organization mapping. Here, we will elaborate on the last core domain, Information, which has become central to the business model of many enterprises. For example, Big Data and Analytics approaches are used to understand the needs and desires of customers and to offer them tailored solutions. Thus, a business-oriented view on information is essential.
Information is the combination of data and a context for interpreting that data. The interpretation comes from associating the data with business capabilities, processes and decisions, and these associations provide the context for interpreting the data. Accurate, timely and relevant information is crucial for good decision-making and innovation. Knowledge results from the ability to apply information to solve a problem or create value.
“Both information and knowledge are key assets in the current knowledge worker-driven economy.”
While data is often considered an IT domain, business information is the baseline from which business knowledge evolves. Business architecture requires a way to talk about business information concepts unhindered by the restrictions of IT systems. For example, in business architecture it is appropriate to talk about Customer Motivation, a domain concept that is not realizable in an IT system because it is not (yet) possible to directly read the mind of a customer.
While knowledge and wisdom build on information, they often fall in the domain of management because they require judgment that interprets information in ways that allow executives to make highly informed decisions.
Business architecture seeks to map perspectives of the business. These perspectives are originally conceptual objects because they exist in the mind of the practitioner. When the conceptual objects that designate information are translated into a documented form, they become the information map.
In the information map, the information concepts represent the business vocabulary. Making concepts tangible in this way enables discussions and the creation of a consensus – a common understanding of what business objects and relationships are intended by the labeled shapes and lines. Indeed, information maps are an important foundation for business architecture work.
The BIZBOK Guide® provides three foundational information concepts to create a basic information map:
- Domain Concepts: These items represent categories of business objects such as
revenues, inventory, employees, and types of assets. Domain concepts should be the initial concepts collected for the information map, along with definitions and a starter list of synonyms.
- Relationships: These items represent connections between information concepts.
- Distinguished business objects: These are specific, identifiable business objects that belong to a domain. Many names or instances of distinguished business objects are determined by standards, such as the ISO standard abbreviations for the countries and jurisdictions of the world.
It is common to begin the construction of an information map by identifying and recording the domain concepts. The domain concepts represented in the basic information map should be of primary importance to the business.
Information mapping with ArchiMate®
We prefer using ArchiMate’s formal semantics for modeling direct relationships between each instance of a business architecture domain. Translating BIZBOK®’s foundational concepts to ArchiMate, we propose using the ‘Business Object’ concept to represent domain concepts as well as distinguished business objects. According to the ArchiMate 3 specification, “a business object could be used to represent information assets that are relevant from a business point of view”. The ArchiMate language in general focuses on the modeling of types, not instances, since this is the most relevant at the Enterprise Architecture level of description. Hence a business object typically models an object type of which multiple instances may exist in operations.
The following figure presents an information map in ArchiMate, using Business Objects:
As shown in the figure above, the ArchiMate language allows you to use several relationships between business objects. Because of its formal semantics, ArchiMate information maps provide a more thorough insight into the structure of your information landscape.
Next to these business objects, the ‘Meaning’ concept may come in handy. This represents “the knowledge or expertise present in, or the interpretation given to, a core element in a particular context”, which is useful if, for example, you want to represent different interpretations given to the same concepts or objects by different stakeholders.
Relating ArchiMate Information Maps to Other Techniques
Next to ArchiMate, other, more detailed techniques for modeling information can be used in Information Mapping as well. Two of the most common techniques are UML and Entity-Relationship Diagrams (ERD).
UML has its roots in object-oriented design. Its class diagrams are particularly useful for information mapping. In fact ArchiMate’s representation of business objects and their relationships owes a lot to UML, basically being a less detailed model omitting things like methods, attributes and relationship cardinalities.
ERDs have a long history in information systems design. They are typically used at three level of design: conceptual, for describing business entities as we did above; logical, for modeling the relationships and attributes of these entities in more detail; and physical, to describe the mapping to database structures. In the context of business architecture, conceptual and sometimes logical diagrams are the most useful.
Next to information maps by themselves, it is also useful to create cross-mappings with the other business architecture domains. For example, it is important to know which information is crucial for which business capabilities when (re)designing information systems. Similarly, responsibilities for and ownership of information can be modeled using a cross-mapping between the information and organization domains.
Creating a thorough, properly documented information map can enable many downstream
activities, including data requirements alignment, application service design, and data
architecture efforts with increased accuracy and efficiency. Therefore, information maps are an indispensable addition to the business architect’s toolbox!