What is Data Architecture? - Continued.....

Organize is the "heart" of the deck. The heart refers to logical data designs that define data elements, organize them into records and organize the relationships between records. In today's world, there are three broad categories of organizing approaches: flat files (often hardly organized at all), normalized and dimensional.

The data architect works through a series of design levels in determining how data should be organized for a production system. Various design levels include conceptual data models, logical data models and physical database designs. Key to the concepts behind normalizing data is a need to organize data in such a way that the data design will endure despite changes to business processes. However, today's emphasis on analytic systems is revealing the need for greater usability, which leads to dimensional designs.

Storage, symbolized by the spade, provides the underpinning for the architecture. It refers to physical data designs that define data location. This includes physical designs to address data distribution across replicated or partitioned data stores—as well as across geographical locations, multiple servers and multiple disk storage devices. It includes designs for archiving and retrieval of older data.

Access is the jewel of data architecture, thus represented by the diamond. It refers to process parts of operational systems that organize the way data is accessed. In the earliest days, every computer program accessed data directly. However, more complex applications introduced a need to isolate functional logic from technical logic. This allowed highly skilled programmers to focus on their areas of expertise, whether functional or technical, because it was impossible for individual programmers to be experts in all aspects of programming.

An access layer was introduced which was sometimes called I/O modules and sometimes called DBAMs (database access modules). Today this layer may be a component called information services or something to that effect. ODBC (open database connectivity), for example, can be considered an information service. Whatever you call it, the data architect must provide guidance as to whether the access layer of the architecture will be thick or thin, smart or dumb, functional or strictly technical, secure or accessible. This aspect of data architecture is also concerned with application performance and whether data accesses are appropriately designed for delivering the performance levels required for the application.

Move is the gathering of data into locations where it best serves the user community—represented by the club in this metaphor. "Move" is the aspect of data architecture that addresses processes and techniques for taking data that's in one place and putting it another place. This encompasses decisions regarding batch data movement and file transfer, data replication and/or synchronization, and EAI (enterprise application integration) versus ETL (extract, transform and load).

Significance for Today:

In today's information society, we all participate in the drive to turn knowledge into power. We want to turn data into information and then information into results. To do that effectively, it is not enough just to organize the data. We also need to store it, move it and access it in the most optimal ways possible.

In fact, in today's business solutions, any one of the four suits—organize, store, access and move—can be the distinctive and differentiating factor in bringing real value to the solution. Any one of the four can be the ultimate "trump" suit.

The data architect needs to be conversant with all four suits, ready to produce the trump suit of the day.


[Thanks to Anil Khatwad for submitting this useful article on Data Architecture and it's significance in today's business!]



Articles Index       Click here to submit your Article.