Information plays an increasingly important role in successful businesses and agencies. Accurate, timely, and relevant information is crucial for good decision-making and innovation. Knowledge results from the ability to apply information in a particular way to solve a problem or create value. It is therefore necessary for architects to understand what information matters most to a business before developing or proposing solutions. An Information Map provides a framework to give rise to that understanding.

Businesses acquire, use, store, and manipulate many types of information in the process of their operations. As businesses become more focused on using information as a strategic resource, it becomes critical to understand what information they will be manipulating.

In Business Architecture terms, information is considered to be an intangible, conceptual representation of things that exist in the real world. “Information concepts” are the basis of the architectural elements that are used to make those intangible things explicit. Information concepts are used to model a business rather than an IT system. Defining the core information concepts that support a particular enterprise provides the core of the Information Mapping view in Business Architecture, which then enables analysis of the relationship between information and other Business Architecture concepts such as business capabilities and value streams.

Information Mapping provides the architect with a means to articulate, characterize, and visually represent the information that is critical to the business, and to shape its representation in ways that enable a more detailed analysis of how the business operates today – or how it should operate at some future point in time.

An Information Map is a collection of information concepts and their relationships to one another. Information concepts, in effect, reflect the business’ vocabulary; e.g., client, account, or product. Mapping information in Business Architecture starts with listing those elements that matter most to the business as well as how they are described in business terms.

A useful way to discern an information concept is to listen for the nouns that are used when talking about the business. Every noun is potentially an information concept. By using a noun-challenge process, it is possible to determine if the noun represents an item of information that the business cares about. In other words, does anyone in the business need to know, store, or manipulate the thing that the noun represents?

A simple, high-level example of an Information Map is shown in Figure 1. This illustrates some key information concepts and inter-relationships that might be found at a financial company. Appendix A provides more detailed examples and techniques for modeling information than this simple representation and includes the use of specific modeling languages.

Figure 1: Simple Information Map for a Financial Institution

An important objective of Business Architecture is to clarify and obtain consensus on the terms and concepts of business information. This is accomplished with Business Architecture through Information Mapping.

When used within the context of Enterprise Architecture, Information Mapping establishes the vocabulary used to articulate strategy and build key Business Architecture artifacts such as capability maps and value stream maps.

There may be an existing glossary of business terms, which can provide the start for key information concepts and business capabilities, to be developed sequentially or in parallel. Information Maps are a part of the core set of artifacts that provide a powerful representation of the business. Information Maps are also a high-level description of the informational requirements of a business and are a key input into its Information Systems Architecture design.

Historically, many organizations have taken a fragmented approach to managing their vocabularies. Managers define key business terms in policies, librarians/administrators maintain corporate glossaries, and IT defines conceptual schemas or data models. These disparate sources of vocabularies constrain an organization’s ability to deploy their strategy and integrate their operations. Because Information Mapping describes information from the perspective of the whole organization, it is ideally suited to enable the management of business information throughout its lifecycle across the organization.

When used within a comprehensive enterprise information management discipline, Information Mapping can improve an organization’s ability to structure, describe, integrate, and govern information assets across the boundaries it operates. This elevates the transparency and value of information and improves the overall organizational effectiveness.

The benefits of using Information Mapping include:

• More effective deployment of business strategy (information critical to strategy is articulated, related to value and capabilities, then linked to execution)
• Improved ability to consume, process, and deliver information (one set of definitions and relationships for key information is flowed to impacted roles, processes, and technologies)
• More effective collaboration (creates alignment across stakeholders and one of the links back to intended value)
• Improved business integration (spans across the impacted organization to break down barriers, improve solution efficiency, and enhance customer experience)
• More accurate financial and regulatory reporting (understand information relationships between external and internal entities)
• Provide the definitive and approved source of business terms across stakeholders

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 possible to directly read the mind of a customer.

As covered above, there are multiple acceptable methods to initially develop the Information Map. When relating the concepts to other aspects of Business Architecture, however, the first step is generally linking information to business capabilities. The Information Map is most closely tied to the business capability map, where information concepts are used by business capabilities when designing future-state Business Architectures as well as subsequent information systems. Business capabilities typically establish information concepts.

For example, the Investment Management capability can be defined as the “ability to identify, develop, analyze, valuate, exchange, acquire, dispose of, and report on any type of monetary asset purchased with the idea that the asset will provide income in the future or will be sold at a higher price for a profit”. While the primary information concept for this capability is Investment, additional information concepts are used by Investment Management and, conversely, Investment information is used by other capabilities. A subset of capability-to-information cross-mappings involved in framing an Investment are represented in Figure 2. A more comprehensive mapping would include Agreement, Partner, and other capabilities and information concepts.

Figure 2: Business Capabilities and Information Concepts

Each capability in Figure 2 requires and modifies information concepts directly related to that capability, such as Investment Management, which modifies Investment information. In addition, Investment Management requires Financial Instrument information as well as information on the Financial Transaction marking the execution of the trade. Similarly, Payment Management requires Investment Information, and Financial Transaction Management requires Investment and Payment information. Notice that in each of these examples the business artifacts can be characterized and related without assuming specific implementations, such as data repositories and business systems. This mapping allows many approaches for assigning roles to execute processes, more powerful architectural assessments, and a broader array of solutions.

The relationship of information to value streams is subtler and more indirect. The use of information concepts is through the business capabilities that modify information content through outcomes. This is a key distinction since using value streams directly to drive usage of information probably indicates the architect is really modeling the implemented business process, not the value-delivering activities at a more abstract level. Value streams, however, do provide the value measurement that drives the assessment of business capability gaps,[1] which in turn are assessed through business information (as well as roles, processes, and resources such as technologies).

Finally, Information Maps have a relationship to stakeholder maps. If your business already has a stakeholder map, it can be used to help define information concepts in the Information Map. In order to derive the most value from the Information Map, it is important to maintain independence from the organization map. Relationships of information to business unit, partner, or collaborative team (in the organization map) are discoverable by tracing to business capabilities. Then the architect traces usage of information concepts to those business capabilities as part of building a framework (the Business Architecture foundation) or as part of solving a specific set of business problems.

To provide examples with familiar content, Figure 1 and Figure 2 are limited to information that could be broken into conceptual data types and, given appropriate Data Architecture practices, resolved into a data schema that can be communicated, used, and stored. Limiting key information concepts only to those captured in data models, however, could lead to significant gaps and wasted investments trying to solve the wrong problem. The data architect will want to use business-focused Information Maps as a source to map into conceptual data, but should understand they are not the same.

For example, a critical type of customer information may be Customer Perception; a characterization of their viewpoint in relation to a specific topic. Another critical type of information for your business may be Product Offering, which has a relationship to Customer Perception where your business needs to know that perception of that product to inform internal planning. A Sales Lead (stakeholder) has the ability to assess customer needs (Customer Analysis – a business capability), which includes the subjective ability (not in a form reducible to a data field), through experience, to assess Customer Perception. The Sales Lead, armed with stored data such as previous sales volume in a customer relationship management system and product characteristics in a product data management system, makes a final recommendation on product development based on their subjective view of Customer Perception. A sample of this relationship is shown in Figure 3.

Figure 3: Sample Relationship between Multiple Business Concepts

Usually, however, many types of business information lend themselves to being characterized as data, as long as the reason that the information matters to the business and the relevant relationships are understood first. This includes structured data that lends itself to conventional Data Architecture methods, and unstructured data that modern technologies can consume to provide actionable input if based on sound architecture and well-understood business logic.

The role of Information Mapping for the Enterprise Architect applying the TOGAF Architecture Development Method (ADM) builds from the sections above, with a similar objective as other Business Architecture artifacts:

• Phase A introduces the subject and alerts the architect to find existing Information Maps in the context of critical business terms, as well as existing relationships between information and other core artifacts such as business capability maps
• Phase B puts the approach in this Guide into action, building additional information concepts, relationships, and linkage to elements in other business artifacts as needed for the scope of the Enterprise Architecture effort
• Phases C and D translate information, where possible, into data models and capture information tied to other critical elements, such as technology services, applications, and logical attributes driving design
• Phase E may involve updating the Business Architecture, which could mean updating the Information Map

To assist the reader in the development of an initial Information Map, a tabular example of common information concepts and linkages between them is provided in Table 1.[2] In the Information Concept Category column, the Secondary terms belong under the Primary term above. The architect can start with this basic reference, then with business and corporate leaders to:

• Extract and modify the information concepts that apply
• Add definitions that make the most sense in context (a business glossary)
• Build out areas such as products or customers (common taxonomy to guide decisions)
• Provide a reference for mapping business capability gaps (driven by ability to deliver value) to the key information needed as part of solving those gaps
• Act as the starting point for cross-mapping to stakeholders

Table 1: Reference Table for an Information Map

This Guide provides the architect with a means to articulate, characterize, and visually represent the information that is critical to the business, and to shape its representation in ways that enable a more detailed analysis of how the business does or should operate. The concept of describing and characterizing information at a Business Architecture level, joined with business capabilities, value streams, and organization maps, provides the Enterprise Architect and other practitioners with powerful methods to characterize business value and guidance for all later phases of the architecture effort.

This appendix includes examples of additional techniques for modeling information beyond those included in the main body of this Guide. It includes examples using the ArchiMate^® modeling language, Unified Modeling Language™ (UML^®) class diagrams, and Entity Relationship Diagrams (ERDs). The UML class diagrams and ERDs are used for more detailed analysis and design, and would normally be produced during ADM Phases C and D.

A.1 ArchiMate Language Example

As described in Chapter 2, an information concept should be viewed as an intangible notion that pertains only to humans. A business object, on the other hand, represents a tangible entity. There are two relationships between information concepts and business objects:

1. “Makes explicit”: this relationship links data-oriented business objects that make an information concept explicit; e.g., it links information about customers to customer information records.
2. “Is about”: this relationship links information concepts that are metadata about business objects to the corresponding business object; e.g., it links information about customers to those customers.

According to the ArchiMate Specification,[3] “a business object could be used to represent information assets that are relevant from a business point of view”. The ArchiMate Specification further states that: “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.”

Figure 4 presents an Information Map in the ArchiMate language using business object elements.

Figure 4: Information Map using the ArchiMate Language[4]

The ArchiMate language allows use of several relationships between business objects. Due to its formal semantics, ArchiMate Information Maps provide a more thorough insight into the structure of the 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.

The ArchiMate modeling notation can also be used to represent the relationships between information concepts and other Business Architecture concepts; e.g., between business capabilities and information concepts.

Figure 5: Information-to-Business Capability Cross-Mapping using the Archimate Language

A.2 Unified Modeling Language (UML)

UML has its roots in object-oriented design. Its class diagrams are particularly useful for Information Mapping. The ArchiMate Specification’s representation of business objects and their relationships owes a lot to UML, basically being a less detailed model and omitting things like methods, attributes, and relationship cardinalities.

Figure 6: Information Map in UML

In UML, cardinalities also allow the architect to constrain the number of objects of a certain class that can be related to a single object of the other class. For example, in Figure 7, the cardinality (1..*) means that a customer must have at least one account, but that there is no upper limit on the number of accounts they can have; the cardinality (1..2) means that an account must be related to at least one, but no more than two customers.

Figure 7: Relationship among Information Types

The attributes are logical units of information related to each of the business entities in the diagram. While it isn’t always necessary to show the attributes for every information concept on every diagram, it is necessary to define all the attributes for all the business entities somewhere. Tables, spreadsheets, and databases are all useful ways to store the related data for each information concept, as previously shown in Table 1.

A.3 Entity Relationship Diagrams (ERDs)

ERDs have a long history in information systems design. They are typically used at three levels of design:

1. Conceptual, for describing business entities as above

2. Logical, for modeling the relationships and attributes of these entities in more detail
3. Physical, to describe the mapping to database structures

In the context of Business Architecture, conceptual and sometimes logical diagrams are the most useful, but will likely contain information types that have not been realized in business systems and databases. There is no restriction on key business information only including structures that have been, or even can be, reduced to structured data.

Figure 8: Information Map in an Entity Relationship Diagram

[1] See the example in the referenced TOGAF Series Guide: Value Streams, page 13.

[2] Table 1 courtesy of the Business Architecture Guild^® (see the referenced BIZBOK^® Guide §2.5).

[3] ArchiMate 3.1 Specification, Section 8.4.1: Business Object.

[4] Figure adapted from the ArchiSurance Case Study, Version 2, Figure 24: Information Structure View Showing Main Business Objects.