A journey to data architecture starts with Information Architecture.
Information Architecture (IA) is one of the most neglected and misunderstood practices within the software industry. Earlier this year, in a survey I conducted on LinkedIn, there was a 36%-64% split over “What comes first ‘Data Architecture’ or ‘Information Architecture’?”. I was concerned for two reasons:
The lack of consensus among Architects and Data SMEs.
While most respondents favored Information Architecture, to my knowledge there are very few projects that conduct Information Architecture ahead of Data Architecture.
IA is the art of modelling the domain information for which we intend to build software. As an example, if we are building a platform to record and track COVID-19 Immunization activities, it is vital to build an end-to-end Information Model (IM) surrounding immunization and vaccine concepts.
An IM helps us to create a visual representation of what we want to achieve including:
… to have?
… to capture?
… to create?
… to share?
… may be public?
… must be private?
… must be logged or audited?
… to see?
… to sell?
… is needed in the future?
… needs it?
… creates it?
… enters it?
People vs. Organizations:
What roles do they play? e.g., Provider vs. Patient?
Why do the need the information?
What is their authority?
Where does the information need to be
When does information need to be
How does the information need to be
Moreover, a Domain Information Model (DIM) is a valuable input for Data Architecture (DA), Business Process Modelling (BPM), UX design, reports and BI. This ensures a smooth and high-velocity experience throughout the development life cycle while keeping defects minimized to minor and cosmetic issues.
Likewise, it is important to distinguish between IA and DA, where IA focuses on input and output and DA on structure, storage, and access. A few years ago, a developer named James randomly came to me for direction regarding a system defect related to Blood Pressure. He originally used a Wikipedia page as input for his work; his design simply put included the entity “Blood Pressure” with Systolic, Diastolic, and date and time attributes. A Health Care Provider user created the defect and described the feature as “useless” without further elaboration.
The following is a conceptual DIM for Blood Pressure that I used to help James.
What James did not know before seeing the model:
Systolic and Diastolic values are useless independently and must be captured and referenced in a pair.
For the blood pressure measurement to be useful, it must contain additional key information at that “point in time” such as demonstrated in the IM above.
This is a perfect example of where knowing the Information Architecture is absolutely necessary to come up with the right Data Architecture. It is important that the IA is fully completed first, allowing agile teams to increase velocity and the quality of finished work. To bring this into context, let us go back to the Blood Pressure (BP) example. To make the BP measurement more useful, physicians may need additional information such as the Patient’s medical history, active problems, family history, procedures, and laboratory results to make better diagnosis decisions. As an example, a higher blood pressure reading for a diabetic patient may be expected and be less of a concern.
So having a wider view of domain information will help us build products that are more relative, realistic, and effective.
What are your thoughts? Do you have an Information Architecture practice in your project?