Enterprise Information Architecture
In the book The Art of War for Executives, Donald G. Krause interprets the following: “Sun Tsu notes, superior commanders succeed in situations where ordinary people fail because they obtain more timely information and use it more quickly.” For metadata professionals, this observation is increasingly relevant as more and more of the business seeks integration and federation, alignment with business goals and strategies, and agility - the ability to respond both quickly and accurately to change. Industry analysts and IT professionals are less focused on solutions to problems where metadata management plays a role but rather look more to metadata management as an overall strategy for the benefits it provides to multiple aspects of the whole organization.
Metadata management is key to the future health of our database systems. Metadata management provides us with the information necessary for impact analysis to help reduce the time, cost and risk associated with change. Reducing the impact of change gives organizations the agility they need. Metadata management also provides the traceability needed to support regulatory compliance initiatives. By being able to trace all aspects of the information from source to transformation to destination to report, organizations can ensure no hidden pitfalls exist that can become punishable offences against the regulations. Additionally, in the case of an audit, organizations can have the auditor in, out and out of the way with a minimum impact on business continuity because the documentation available is complete and accurate. Metadata management has been proven to be a mandatory element of modern architectures, including service-oriented architectures (SOA), by providing a repository of assets aligned to process, making it easy to track what, where, when, how and who is responsible for fulfilling service level agreements (SLAs) to the overall organization’s method of operation.
Data models drive metadata collection, definition and maintenance. Taking an analogy from business intelligence (BI), models are the transactional systems for our metadata management, while the metadata repository acts as the warehouse. Models provide the user interface for the day-to-day transactions, the inserts, updates and deletions of metadata elements from the data dictionary to the physical implementation design details. Modeling aligned with repositories ensures that the most up-to-date, accurate metadata is known and provides the basis for the analytics we will perform. Questions around the impact of a proposed change, the number of instances of a given data concept, what publications and subscriptions of data exist and more are answered by querying the repository in much the same way we would query an analytics server about the knowledge of our business transactions.
Shifting from Modeling to Architecture
Alignment, agility and architecture are the goals. Metadata is the key, and models feed the metadata repositories used to achieve the goals. However, models also provide abstraction to simplify complexity, increase understanding through visual representations and provide governance to increase consistency and reusability throughout the organization. As the need to align business and IT increases, the need for more levels of abstraction increases. A greater need to establish standard practices, procedures and tooling results from the fundamental shift from workgroup opportunistic physical data modeling into departmental and enterprise-wide strategic information engineering.
Enterprise information architecture starts with the high-level business definitions and descriptions, setting standards for data throughout the organization. Standard, common metadata definitions are key to establishing proper communication, including the concept of standard formats for messages between processes. Conceptual data models and canonical data models are the standard representation of this highest level of abstraction, while business process and process orchestration language models provide the context for data. From there, designers add detail to the architectural elements aligned with relational concepts in logical data models and final refinements are made in relational database management system (RDBMS)-specific physical data models, representing the instances of data. While the conceptual and logical data models can be used to define the data heritage from standard definition to implementation definition, answering questions like “where used,” data used in practice also comes from transformation and movement from one or more sources to one or more destinations. It is here that data lineage comes into play - the mapping between source elements together with the definition of any transformation, simple or complex, that make up the path of physical data through an integration, federation or replication server.
Conceptual Data Models
Be the first to comment on this post using the section below.