Data Architecture

Introduction

I perceive, Business, Data and IT as three sisters growing up in single a household. Business being eldest dominates other two. IT is the youngest, most outspoken of the lot. Data being the middle sister, tries to be the bridge between other two sisters. She knows what makes Business happy. She know knows how to gel well with IT. Whenever there is a conflict between Business and IT, Data steps forward to resolve the conflict.?

Being siblings, it is natural there will have similarities in their looks. But will it be fair not to recognize their uniqueness as person? I believe, the peaceful coexistence of these three sisters, Business, Data and IT, with freedom to radiate their unique values will bring harmony into the household, the Organization.

The fact that people are comfortably using the terms system architecture and data architecture interchangeably amaze me. To some people it’s a common practice use one term and mean another. In my understanding, this clumsy ways of dealing with different layers of architectures ultimately hinders organization agility.

In this article I would like to pen down the way I identify the Data Architecture separately from Business and System Architecture. I will not go deeper into the technicalities of architectural aspects. The purpose of the article is to bring the subtle uniqueness of the Data Architecture.

Are you ready to dive into my world of imagination?

illustration

In my ‘world of imagination', you and I have been made responsible to create a report on the water composition. We grabbed the world map to discover all sources of water. We found a lot of them, waterfalls, rivers, canals, seas and oceans etc. We studied the map thoroughly to understand how these sources or water are the connected with one another. It gave us pretty good foundation to make a plan of approach on how to analyze water composition. As per our plan, we started travelling different parts of the world to collect the water samples from difference sources. In the end of our expedition, we came back to our lab and started analyzing water samples.

Here we are imagining my imagination. So for the sake of unity, let's accept we both agreed to this approach.

In the lab we observed that every water molecule is composed of 2 hydrogen and 1 oxygen atom. We kept analyzing further to understand why the sample collected from river tastes sweet but the sample collected from sea tastes salty? We discovered 3.5 percent dissolved salt in sea water whereas river water has only 0.012 percent. We incorporated all these findings into our report on water composition.

Don't ask me how long did we continued analysing water samples to create the perfect report. Instead with this memory let us get back to reality and connect this analogy with our topic of the day.

Data Architecture

An organization where business is well supported by IT, we will always find system architecture documents that describe systems and their interconnections. It provides a helicopter view on how business processes are expected to progress.

In our story, the map that was used to find sources of water in the ‘world of imagination’ can be compared with the 'system architecture'. The map and the System Architecture both helps us to understand the boundaries of each component, their interconnectedness and the overall outer boundaries.

?

In the scope of the system architecture when business process progresses, the data gets generated. From the system of origination the Data flows across multiple systems. In this journey, the structure of data evolves to stay tuned with the business.

????????????? The way water flows within the boundaries of the canals, rivers, seas etc Data flows within the boundary of the systems. To witness how Data structure is evolving from source to destination one must pay an attention throughout its journey across the systems.

?

Irrespective of the systems where the data is residing at any given point in time, it will always retain its unique distinct structure. Paying close attention, one can distinctly identify this structure.

For example, say an organization has two business process, (i) onboard customer and (ii) offboard customers. They have two different systems which implements these process. Irrespective of the business processes and systems that automate these processes, the customer data always will have a fixed basic structure.

For sake of illustration, consider a customer entity has attributes Customer-Name, Customer-Status, Customer-Onboarding-Date, Customer-Offboarding-Date. During the onboarding business process one customer data instance generates with Customer-Name = ‘George’, Customer-Status = ‘Active Customer’, Customer-Onboarding-Date = ‘1st January 2015’. During offboarding business process, the Customer-Status changes to = ‘Inactive Customer’, Customer-Offboarding-Date = ‘31st December 2025’.

Irrespective of its containers, the water is always two part of hydrogen and one part of oxygen. It accumulates salts along the way from river to sea. Do you see the analogy?

This is the essence of Data Architecture. It describes?the data and how data is (or should be or would be) managed from collection through to transformation, distribution, and consumption.????????????

Importance of Data Architecture

One may question, when we know enough the business that we are pursuing and the system that is enabling the business ( in other words, when the business and system architecture is clear ), why shall one spend additional time on Data Architecture?

Data ties the Business and IT together. Well-managed data sets the context right for the business, which in turn helps organization to navigate better. Good management starts with understanding. Data Architecture plays the crucial role here. Hence it is worth spending time to create and maintain Data Architecture besides Business and System architectures.

Disclaimer : This is my humble attempt to give you a starting point. If my article could intrigues you, please don’t stop here. Keep exploring!