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 organizations 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
Representing the business architects view and the business owners perspective, the conceptual data model is independent of both the storage architecture and the implementation technology. As such, it not only maps the core business concepts and relationships between them, it also serves as a single, enterprise-wide standard for the common data definitions and descriptions. It supplies the semantics for the business, the core language that can be mapped to the aliases and synonyms used at departmental, divisional levels. In principal, conceptual data models as a single construct for the enterprise provide a single source of truth that all instantiations will be based on, increasing the consistency of use for common data elements throughout systems easing integration and federation and increasing BI system success.
Canonical Data Models
Conceptual data models can map to any storage architecture, including hierarchical, relational and object-oriented. One practice that has been driven mainly from system integration projects that center on messaging is the development of a canonical data model based on XML. XML, hierarchical by nature, is also the format of choice for defining message construction. Canonical data models are meant to be exactly that - the single true core definition of data constructs so that everyone needing to use the data uses it in the same way. Conceptual data models and canonical data models are theoretically the same, while in practice we see canonical data models as abstractions of XML schemas. Either way, these models are only representing the core data definitions and key attributes.
Business Process Models
All Information Management articles are archived after 7 days. REGISTER NOW for unlimited access to all recently archived articles, as well as thousands of searchable stories. Registered Members also gain access to:
- Full access to information-management.com including all searchable archived content
- Exclusive E-Newsletters delivering the latest headlines to your inbox
- Access to White Papers, Web Seminars, and Blog Discussions
- Discounts to upcoming conferences & events
- Uninterrupted access to all sponsored content, and MORE!