Business Data Architecture for Business Analysts

A business data architecture comprises definitions and models of an organisation’s data, its business concepts. These concepts are necessarily defined using the language of the business.

Models of business data architectures provide a picture of the business in terms of its data. They help everyone understand the concepts that the organisation is based on. Once identified, they can be used as building blocks to develop agile systems and an agile organisation.

Identifying, developing and exploiting the business data architecture should be a key skill of a business analyst.

Estimated reading time: 7 minutes

Advantages of establishing a business data architecture

The essential concepts of an organisation do not change often. Therefore a business data architecture provides a view of the business that is static and stable. It provides an organisation with valuable insights into its underlying structures. Such insights can lead to greater business agility.

Although static in itself, a robust data architecture can support the development of,

Dynamic processes
Robust and flexible software systems
Responsive information facilities
Artificial intelligence capabilities (AI)

The stable base provided by a business data architecture helps to separate the stable business concepts from the more volatile things that change frequently. This provides a background for making such changes, whilst reducing the risk of compromising the underlying quality and integrity of the overall system.

Potential extensions and changes to the data concepts and their inter-relationships can be discussed at a business level. Following such discussions, you can determine the implications for IT, the organisation’s data bases and the technical architectures.

Such a business oriented approach supports business agility, the ability to rapidly but safely make adjustments in response to a changing business environment.

Data for business agility

Data provides transparency to processes; it shows the current state of any particular transaction and the cumulative results of multiple transactions.

Data can be interpreted to support decisions that affect the future of the organisation. The data resource can be harnessed to improve the performance and agility of any organisation.

To harness this resource, it is essential to organise and understand it. The Zachman framework can help achieve this.

The Zachman framework

Zachman provides a framework for an enterprise architecture; this includes a data architecture.

Data analysts can use the Zachman framework to view the data through different lenses. Each lens captures the perspective of a particular group of stakeholders. There are 3 lenses that are relevant to business stakeholders. The other three lenses are relevant to more technical groups.

These six lenses are shown as rows in a table. They collectively describe the enterprise data architecture.

Top 3 rows of Zachman

The top three rows of the Zachman framework provide the business lenses. These collectively define the business data architecture. We define these rows below.

Row 1: Contextual

This layer represents a catalogue of the organisation’s data. This is the start point for a. business data architecture and includes:

‘Business concepts’, such as Customer, Supplier and Product
‘Attribute types’, that define the detail of the concepts; e.g. customer name, product description, unit price and account status
Business associations between the concepts, e.g. an association between a customer and a sale of a product

All identified data should have a description created and owned by business stakeholders, not IT.

Synonyms and homonyms in the data architecture

A data architecture must identify homonyms and synonyms.

Synonyms

Synonyms, also known as aliases, are different terms for the same thing. For example, people in the marketing department may refer to ‘customers’, whereas finance team members may refer to ‘accounts’. It might not be obvious that both parties are referring to exactly the same thing. This can be confusing and can cause misunderstandings.

Homonyms

A homonym refers to the use of the same term for different things. For example, the word, ‘event’ is likely to mean different things to different people.

Business analysts might not immediately spot a homonym; this obviously causes confusion. Identify them and bring them to everyone’s attention.

Row 2: Conceptual

The conceptual row refers to models of the items in the data catalogue, i.e. the

Business concepts
Attributes of the concepts
Associations, or relationships, between the concepts

The bulleted items above can be represented graphically as what are referred to as ‘conceptual models’. They are an essential element of a business data architecture.

Forms of conceptual model

There are various standard notations for representing conceptual models, e.g.

Entity relationship models
UML class diagrams

Attribute types in a business data architecture

At the conceptual level, associate all attribute types with one, and only one, concept. The precision of naming the attribute types can help to achieve this, e.g. ‘customer name’ rather than simply, ‘name’.

Identifying attributes

Most significant concepts will have an attribute type that allows the business to distinguish between different instances of the concept. E.g., a unique ‘product number’ allows the distinction between different products. These are the ’identifying attributes’.

Associations in a business data architecture

The conceptual level models also show the ‘associations’ or ‘relationships’ between the concepts. Examples of associations include,

Supplier and the products that they can provide
Employee and the sales they have made
Customers and the bookings they have made

Associations are a core part of a business data architecture.

We can qualify associations in various ways, e.g. by labeling them. For example, two concepts of an insurance company are likely to be ‘Customer’ and ‘Policy’. An association between these two concepts might be labelled ‘purchases’, as in, ‘A customer purchases a policy’.

At the conceptual level, we do not have to say how such an association might be represented on a database.

Business rules in a business data architecture

The conceptual level of a data architecture also defines business rules such as the minimum number of purchases that someone has to make to meet the organisation’s criteria for being a customer. E.g., does the concept of customer include people who have never made a purchase?

Defining a business concept

Define your business concepts with the items below.

Definition
Attribute types
Associations to other concepts
Associated business rules

The business concepts at this level might also be referred to as Entity Types or Entity Classes.

Row 3 – Logical

The logical level of the Zachman framework represents the concepts, attribute types, and associations as tables. Business and data analysts can create graphic models from these tables.

Foreign keys

At this level, the model can demonstrate the logic of an association. For example, to show, logically, the association between a customer and a product they have purchased, modellers can include the identifying attribute, ‘customer number’ in the set of product attributes. This is an example of a ‘foreign key’.

Foreign keys are not attributes of a concept. They are included simply to provide a logical link between concepts.

Logical or physical?

Some people refer to this logical view as the physical view. We reserve the idea of physical views to describe views that demonstrate where data physically resides on the storage medium.

The lower 3 rows of Zachman for the data column

The lower three levels of the data column of the Zachman framework describe increasingly more technical, or ‘physical’ views. Such views comprise, for example, ‘maps’ and ‘pointers’ that describe where data resides on the storage media.

These lower layers are of particular concern to data base designers and administrators, data architects, the suppliers of databases and information systems, and so on.

The business analyst should at least be aware that these layers exist and are important to the performance of the data bases.

To improve system performance, data designers may, for example,

Split, combine or duplicate the groups of data that the business analyst views as concepts
Introduce additional links between data classes
Create additional copies of data

Adequate performance is vital to meeting the needs and expectations of the organisation.

The business analyst must work closely with the technical teams to ensure that business stakeholders get timely access to high quality data, when they need it and where they need it.

Databases

Here are some questions to ask about your business data architecture.

Do you know where the business concepts and their attributes appear as records (data tables) on the organisation’s databases?
Does the definition of the database table and each of its data items match the agreed business definitions of the business concepts and attribute types?
Alternatively, do the data base tables appear to have been arbitrarily designed over the years (decades?); e.g.
- has someone in the past created a database table and populated it, seemingly randomly, with data items, assigning arbitrary, inconsistent and non standard names to the tables and their items?
Are there multiple copies of a particular concept or its attributes on the database(s)?
- If so, do you know which copy is the ‘master’, i.e. if the copies get out of sync, do you know which one is correct?
Are your organisation’s data definitions created solely by IT,
- i.e. Without involving the business representatives?
If your organisation uses package software, are your business concepts, in effect, defined by your software supplier?
Do you have a model of the data at the business concept level that can be used in discussions with the business
- Or do you only have database schemas?
Does the business really understand its own data?