Abstract
Data architecture is a blueprint for how data is stored and flows across the enterprise over its life cycle. This sounds pretty simple. However, it is more intricate than it sounds. The focus of data architecture goes beyond individual systems to understand how data flows across systems; it goes beyond individual data stores to understand where the data is created, where it is maintained, how it is shared, and how it is changed across data stores. The focus of data architecture is also not on the hardware infrastructure, but rather on how the infrastructure network works to deliver trusted information.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Notes
- 1.
Views on where in a data management framework to place a business glossary vary. It is equally useful as part of other domains, such as metadata management, master data management, data governance, and others.
- 2.
Fryman, L., “What Is a Business Glossary,” BeyeNETWORK, September 13, 2012, http://www.b-eye-network.com/view/16371.
- 3.
A business glossary is a useful foundational artifact across many data management areas, such as data governance, metadata management, master data management, data quality, records management, and additional domains.
- 4.
Such standards are particularly important for sharing data with entities outside the organization. Data architecture can extend to sharing data with entities outside the organization. Many data exchange standards continue to be developed to foster such exchanges. See the Data Architecture References section in Appendix C for a brief discussion.
- 5.
Vendor-based software tools such as extraction, transformation, and load (ETL) tools use proprietary metadata to track data. This presents some limits on the ability to standardize metadata. This type of metadata is typically technical in nature. An organization should still be able to standardize its business metadata to suit its needs.
- 6.
For a more detailed discussion of relational data modeling, see “The DAMA Guide to The Data Management Body of Knowledge (DAMA-DMBOK,” Technics Publications, LLC, 2009. For a discussion on other types of data models, see the Data Analytics References section in Appendix C.
- 7.
High-level grouping terms vary. The DMBOK considers a subject area model the highest level model. Subject areas (as few as 10–12 total) are useful for developing an initial understanding environmental complexity, addressing questions such as how many systems have customer data? Categories (about 5–7 per subject area) are often useful to begin discussions of authoritative sources, data quality, and data stewardship domains.
- 8.
A business glossary can be a useful tool when defining subject areas.
- 9.
There are multiple notations used to denote relationships in data modeling. This diagram uses the Crow’s Foot notation. One source for additional details on data modeling notation is https://en.wikipedia.org/wiki/Entity–relationship_model.
- 10.
In some cases, detailed logical and physical data models exist but conceptual models do not. Thus the terminology applied across multiple logical and physical data models may differ. For example, an event in one data model may be called an incident in a second data model. It is therefore sometimes useful to create a conceptual data model retroactively in order to synchronize terminology.
- 11.
These include IDEF1X, Crow’s Foot, UML, and others.
- 12.
This is most likely if one or more conceptual level models already exist. It is also possible that an enterprise data model evolves from existing logical and physical data models.
- 13.
The term “data life cycle” in this context refers to the life cycle of data across a business use case rather than the life cycle of data from conception to purging.
- 14.
It is also possible to approach a data inventory by beginning with a system interface diagram and matrix. Together these two artifacts document one or more key organizational systems and their direct interfaces. This approach has the limitation that it is not business-process oriented and thus may be initially less understandable by the business user. However, it is a straightforward way to begin documenting where data is located and how it is shared, and the results can be leveraged when creating DLDs.
- 15.
Leganza, G., “Changing Your Approach to Information Strategy? You’re Not Alone,” Forrester Research, Inc., October 2, 2014.
- 16.
For example, TOGAF and DoDAF both employ separate techniques to document process models and logical/physical data models; process models are then aligned with data models to understand how data is used.
- 17.
DAMA, “The DAMA Guide to Data Management Body of Knowledge,” 1st Ed., Technics Publications, LLC, 2009, Chap. 4.
- 18.
CMMI Institute, “Data Management Maturity (DMD) Model,” Ver. 1.0, CMMI Institute, August 2014, Chapter “Data Lifecycle Management,” pp. 105–110.
- 19.
There are many other techniques to help manage data architecture. For example, the CRUD (create, read, update, delete) matrix is a useful tool to manage potential conflicts for creating, updating, or deleting data. Such tools are useful for specific purposes rather than universally.
Author information
Authors and Affiliations
Rights and permissions
Copyright information
© 2018 Springer International Publishing AG
About this chapter
Cite this chapter
Fleckenstein, M., Fellows, L. (2018). Data Architecture. In: Modern Data Strategy. Springer, Cham. https://doi.org/10.1007/978-3-319-68993-7_9
Download citation
DOI: https://doi.org/10.1007/978-3-319-68993-7_9
Published:
Publisher Name: Springer, Cham
Print ISBN: 978-3-319-68992-0
Online ISBN: 978-3-319-68993-7
eBook Packages: Computer ScienceComputer Science (R0)