Saturday, August 3, 2013

Data Architecture Best Practices

Data is one of the most valuable assets in modern business today. Organization manages data and information from two perspectives. Operationally there are practices of information management that cover such things as Data/Information Quality, Data/Information Acquisition and Migration, Backup/Recovery, Maintenance and Data/Information, Security and Access Control. Architecturally there are three key areas that are considered: Meta Data Management (including providing business data design), Trusted Source Management (Looking to define master and reference data, systems of record and enterprise data warehousing) and Information Delivery (Defining the delivery of information via applications, integration, BI, analytics or reporting). More specifically, what are some data architecture practices?

  1. Both operational and architectural practices collaborate in defining business and technical meta data. This practice allows for a better foundation for enterprise business data design, and, subsequently, logical design (where systems haven't been purchased). 
  1. The logical model is best fit to the processes it needs to support, as data is the persisted state of company processes. To do so as an outside step introduces unfamiliar semantics, and constructs to the application developers in a company. Let the tech-leads and application architects handle the logical design; 
  1. Have an oversight on data sourcing, data model, and the applications using that data model. Data redundancy is one of the larger maintenance costs that a company can incur. The decoupling between architecture and operations actually masks the usage patterns and sources of data that are essential in resolving data sourcing issues. While storage is cheap, people to maintain servers, backup servers, servers that are purchased to support the cycles of retrieving that data is not cheap. So an architect should have oversight on data sourcing, data model, and the applications using that data model (at least at the application architect/tech lead level.)  
  1. Security, security, security. More and more emphasis is being put on Architects and Development leaders to protect the lineage of data in certain areas of a corporation. Security is a chief concern for the enterprise architect, and knowing the logical representations of data gives the EA the general view of what data originates from which sources, and then further, who has access to those sources needs to be controlled 
  1. Controlling the master data is very important The issue in whole world today because of so many home grown application uses their own data. It leads into data redundancy and inconsistency .There are three types of data: 1) Master data; 2) Reference data 3) Transaction data. In which Master data like can go across many application , Others might not. So controlling the master data is very important. Now the people won’t be knowing that , which source is having true copy of data. Who is the actual creator (source) of the data? Without an Enterprise data model it’s difficult understand the data movement and usage. You need to have meta-data management process since each department has different terminology to define an entity. You need to have data owners for each major entity and requires change control process in place 
  1. Domain Model: A domain covers a certain coherent part of the business. Each domain is governed by a model that shows entities and their attributes on a logical level.  Each domain is governed by a model that shows entities and their attributes on a logical level. Each service that is defined has input and output attributes, which all can be mapped to the exchange model of the domain the service belongs to. The service description has a technical translation into xml of the functional service description. This service must be used for exchange of data between domains. A service is provided by an application. This application has its own logical and technical data model, however in the service it needs to use the domain attributes. So architects work with a layering of data models that are spread out, interlaced and woven into each other..


Great article and just what I was looking for. Filled some gaps that I was toiling over. For a visual, do you have any architectural layouts or schemas to complement your analysis?

MEP F modelling

Post a Comment