Data Architecture: How to build the castle?

“Architecture is frozen music.” This famous quote is from 18th-century writer Johann Wolfgang von Goethe. The statement reveals a quality of architecture as a creative discipline. Both architecture and music are wide open to interpretations; however, they intrinsically bind things in harmony. Data architecture is a symphony of data that is collected, stored, arranged, integrated, and put to use in corporations. We dealt with the data architecture definitions and its need with house analogy in my last blog “Data Architecture – What is it and why should we care?”. In the current article, we will recount how to put together the fortress of data architecture.

Architecture frameworks such as TOGAF, Zachman, DoDAF offer us a method to think about systems and architecture. Although plenty of consortia developed, proprietary, defense industry, government and open source frameworks are available, one should use them judiciously because one might overdo things than necessary. There are many research papers available that show that EA frameworks are theoretical and impossible to carry out. With this in mind, experts agree that foundational artifacts are needed to document data architecture. Organizations decide these foundational set of artifacts based on the potential value they provide and the investment they have to make in creating them. These artifacts are integrated set of specifications to define data requirements, to guide integration and control of data assets, and to align with business’ information needs and strategy. An Architect must make sure the coherency and integrity between the artifacts created whether a diagram, data models, and other documents.

DAMA DMBOK divides Enterprise data architecture artifacts into three broad categories of specifications –

1. The enterprise data model: The heart and soul of enterprise data architecture,
2. The information value chain analysis: Aligns data with business processes and other enterprise architecture components, and
3. Related data delivery architecture: Including database architecture, data integration architecture, data warehousing/business intelligence architecture, document content architecture, and meta-data architecture.

Enterprise architecture includes data, process, application, technology and business architecture in practice. The business architecture may include goals, strategies, principles, projects, roles and organizational structures. Process architecture has processes (functions, activities, tasks, steps, flow, products) and events (triggers, cycles). Application architecture has macro-level and micro-level application component architecture across the entire application portfolio governing the design of components and interfaces, such as a service-oriented architecture (SOA). Enterprise architecture includes these aspects.

To create the data architecture, one has to define business information needs. The core of any enterprise data architecture is an enterprise data model (EDM). The EDM is an integrated subject oriented data model defining the essential data created and consumed across the enterprise. Building enterprise data model is the first mark in establishing that need and data requirement. Organizations cannot build EDM overnight. Each strategic, and enhancement project should contribute to building it piece by piece. Every project that touches data assets of the organization with its limited scope classifies the inputs and outputs required. These details should list data entities, data attributes, and business rules. One can thus organize these by business units and subject areas. Proper categorization and completeness is key to building the enterprise data model.

Planner View (Scope Contexts): A list of subject areas and business entities.

Owner View (Business Concepts): Conceptual data models showing the relationships between entities.

Designer View (System Logic): Fully attributed and normalized logical data models.

Builder View (Technology Physics): Physical data models optimized for constraining technology.

Implementer View (Component Assemblies): Detailed representations of data structures, typically in SQL Data Definition Language (DDL).

Functioning Enterprise: Implemented instances.

The enterprise data model by itself is not enough. The data model is part of the overall enterprise architecture. It is important to understand how data relates to business strategy, organization, process, application systems, and technology infrastructure. In forthcoming articles, we will go over EDM, information value chain analysis, data delivery architecture and some additional aspects of data architecture.