What is a business data architecture?
A business data architecture comprises definitions and models of an organisation’s concepts and data using the language of the business.
It forms a picture of the business in terms of the data. It helps us understand the fundamental concepts on which the whole business is based.
Advantages of a business data architecture
Because the essential concepts of the business are long lasting, a business data architecture provides an enduring view of the business.
This stable base supports business agility by separating those aspects that change frequently. Such changes can be made more easily, whilst retaining confidence in the quality and integrity of the overall system.
Potential extensions and changes to this data 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 reveals the current state of an organisation’s business.
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. It is a resource that 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.
Data can be considered at each of the levels defined on the Zachman framework.
Business analysts and architects are mainly interested in the top three rows. In the accompanying diagram we have identified each one of these.
The lower three rows are primarily of interest to technical staff. Because we will not cover these in detail, we have summarised them as ‘Technical views’.
Top 3 rows of Zachman
Row 1: Contextual – This layer lists all of the organisation’s data. This includes
- ‘Concepts’, such as Customer, Supplier and Product
- ‘Attributes’ that describe the concepts; e.g. customer name, product description, unit price and account status
All identified data should have a description created and owned by business stakeholders, not IT.
It can also be useful to identify all of the alternative names for concepts and attributes. These are different terms for the same thing, i.e. the synonyms. Different units of an organisation may use particular synonyms; this has the potential for confusion and imperfect communication.
One form on 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; homonyms can also result in confusion and should be identified.
Row 2: Conceptual – The conceptual row refers to models of the organisation’s concepts. Concepts might also be considered as ‘data classes’. The conceptual level model contains all the:
- Business concepts, such as Customer and Product
- Data items (attributes) of the concepts
- Associations, or relationships, between the concepts
The bulleted items above can be represented in graphic form. There are various standard notations for doing this. Forms of data model include:
- Entity relationship models
- UML class diagrams
At the conceptual level, all attributes should be associated with only one concept. Precision of naming the attributes can help to achieve this, e.g. ‘customer name’ rather than simply, ‘name’. Most significant concepts will have an attribute 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 attributes may be referred to as .’identifying attributes’.
The conceptual level models also show the ‘associations’ or ‘relationships’ between the concepts. At this level, we simply state that associations between concepts exist; we can qualify them in various ways such as 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 and maximum 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? A concept is defined by its:
- Definition
- AttributesAssociations to other concepts and the associated business rules
- Associations to other concepts associated business rules
- Associated business rules
The concepts at this level might also be referred to as Entity Types or Entity Classes.
Row 3: Logical. Logical level contains models of the data that appear similar to the conceptual models. 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 (WHAT) 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
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?