A business data architecture comprises definitions and models of an organisation’s data. These definitions use the language of the business.
The models 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 data architecture is a key skill of a business analyst.
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 business 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, the implications for IT, the organisation’s data bases and the technical architectures can be determined.
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.
The Zachman framework allows data to be seen through different lenses. Each lens captures the perspective of a particular group of stakeholders. There are 3 lenses that are relevant to business stakeholders. Another 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
Homonyms and synonyms must be identified in any data architecture.
It can also be useful to identify all of the alternative names for concepts and attribute types. Different terms for the same thing are known as synonyms, or aliases. Synonyms can confusion, resulting in misunderstanding, with the various organisation units using a different term to refer to the same thing.
One form of synonym is the abbreviations, or codes, that are used for concepts and attributes
A homonym refers to the use of the same term for different things. This happens, for example, when one department calls a concept one thing but another department calls it something else.
Business analysts might not immediately spot a homonym; this obviously causes confusion. They need to be identified and brought 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 conceptual model
There are various standard notations for representing conceptual models, e.g.
- Entity relationship models
- UML class diagrams
At the conceptual level, all attribute types should be associated with one, and only one, concept. Precision of naming the attribute types can help to achieve this, e.g. ‘customer name’ rather than simply, ‘name’.
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. Such attribute types E may be referred to as ’identifying attributes’.
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.
The conceptual level 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 concept
A concept is defined by its:
- Attribute types
- Associations to other concepts
- Associated business rules
The concepts at this level might also be referred to as Entity Types or Entity Classes.
Row 3 – Logical
The logical level represents the concepts, attribute types and associations as tables. Graphic models can be created from these tables.
At the logical 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, we can include the identifying attribute, ‘customer number’ in the set of product attributes; see the diagram below for an example.
Such logical links are known in the terminology of relational databases as ‘foreign keys’. They are not attributes of a concept but are included simply to provide a link between concepts.
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.
Lower 3 rows of Zachman for data
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.
Do you know where these concepts and their attributes appear as records (data tables) on your databases? Does the definition of the table and each of its data items match the business agreed definitions of the business concepts and attribute types? Does the set of items in a database table match the set of attributes in the corresponding concept definition? Alternatively, do the data base tables appear to have be arbitrarily designed over the years (decades?); e.g. has someone in the past create a database table and seemingly randomly populated it with data items, assigning arbitrary, inconsistent and non standard names to the tables and their items?
How are the aliases handled on the databases?
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? If your organisation uses package software, are your business concept 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?