An introduction to enterprise architecture framework and MDM patterns

In this excerpt from Master Data Management and Data Governance, readers will get a brief introduction to enterprise architecture framework concepts and MDM enterprise architecture patterns. Readers will also find an in-depth definition of service-oriented architecture (SOA).

Table of Contents

The evolution of MDM architecture
An introduction to enterprise architecture framework and MDM patterns
MDM and SOA: An introduction to SOA and the benefits of SOA
MDM design, MDM deployment options and MDM hierarchy

MDM Architectural Philosophy and Key Architecture Principles
MDM has evolved from and is a direct beneficiary of the variety of solutions and approaches described in the previous section. In this context, MDM enables an evolutionary approach to constructing a comprehensive architectural vision that allows us to define many different viewpoints, each of which represents a particular architecture type.

Moreover, we can create an MDM architecture view that addresses a variety of architectural and management concerns. Specifically, we can develop an architectural view that defines components responsible for the following functional capabilities:

• Creation and management of the core data stores
• Management of processes that implement data governance and data quality
• Metadata management
• Extraction, transformation, and loading of data from sources to target
• Backup and recovery
• Customer analytics
• Security and visibility
• Synchronization and persistence of data changes
• Transaction management
• Entity matching and generation of unique identifiers
• Resolution of entities and relationships

The complexity of the MDM architecture and the multitude of architectural components represent an interesting problem that is often difficult to solve: how to address such a wide variety of architectural and design concerns in a holistic, integrated fashion. One approach to solving this type of challenge is to use the classical notion of a top-down, abstracted representation of the MDM functionality as a stack of interdependent architecture layers, where a given layer of functionality uses services provided by the layers below and in turn provides services to the layers above.

Defining Service-Oriented Architecture

Service-oriented architecture (SOA) is the architecture in which software components can be exposed as loosely-coupled, fine-grained, or coarse-grained reusable services that can be integrated with each other and invoked by different applications for different purposes through a variety of platform-independent service interfaces available via standard network protocols.

We can further enhance the notion of the layered architecture by expressing the functional capabilities of each of the architecture layers in the stack as a set of abstracted services, with a degree of abstraction that varies from high (at the upper layers of the stack) to low (for the bottom layers of the stack). The notion of abstracted services is very powerful and provides architects, designers, and implementers with a number of tangible benefits. We discuss these benefits and the principles of service-oriented architecture (SOA) later in this chapter.

Applying the notion of service-level abstraction to the MDM architecture, we now define its key architecture principles as follows:

• An effective MDM solution should be architected as a metadata-driven SOA platform that provides and consumes services that allow the enterprise to resolve master entities and relationships and move from traditional account-centric legacy systems to a new entity-centric model rapidly and incrementally.
• We can define several key tenets of the information management aspects of the MDM architecture that have a profound impact on the design, implementation, and use of the MDM platform:
• Decouple information from applications and processes to enable its treatment as a strategic asset.
• Support the notion that the information content (master data) shall be captured once and validated at the source to the extent permissible by the context.
• Support propagation and synchronization of changes made by MDM system to key master attributes so the changes are available to the consuming downstream systems.
• Enable measurement, assessment, and management of data quality in accordance with information quality standards established by the organization and articulated as part of business needs and data governance.
• Ensure data security, integrity, and appropriate enterprise access.
• Support the retention of data at the appropriate level of granularity.
• Provide an effective vehicle for standardizing content and formats of sources, definitions, structures, and usage patterns.
• Enable consistent, metadata-driven definitions for all data under management.
• Preserve data ownership and support well-defined data governance rules and policies administered and enforced by an enterprise data governance group.

Although the notion of supporting these key information management tenets and using service-level abstraction is fundamental and even necessary in architecting enterprise-scale MDM solutions, it is not totally sufficient. Other aspects of the MDM architecture are better described using alternative architecture representations, or architecture viewpoints, that differ in the content, context, and levels of abstraction. In order to formalize the process of defining and using various architecture viewpoints, we need to introduce the notion of a multidimensional enterprise architecture framework. Readers already familiar with the principles and concepts of the architecture framework can skip the following section.

Enterprise Architecture Framework: A Brief Introduction

As stated earlier in this chapter, the complex multifaceted nature of an MDM solution cannot be described using a single architecture view, but instead requires a number of architectural perspectives organized in a multidimensional architecture framework. Let’s illustrate this framework notion using an analogy of building a new community within existing city boundaries. In this case, the city planners and the architects need to create a scaled-down model of the new area, including buildings, streets, parks, and so on. Once this level of architecture is completed and approved, the building architects would start developing building blueprints. Similarly, the road engineers would start designing the streets and intersections. Utilities engineers would start planning for underground cabling, water, and sewerage. City planners would start estimating the number and types of schools and other public facilities required to support the new community. And this list goes on.

Clearly, before the work can get started, the city planners will have to create a number of architecture views, all of which are connected together to enable a cohesive and complete picture of what, when, where, and how the individual parts of the new city area will be built.

To state it differently, any complex system can be viewed from multiple angles, each of which can be represented by a different architecture perspective. To organize these various architecture perspectives into a holistic and connected picture, we will use the enterprise architecture framework first pioneered by John Zachman. This framework helps architects, designers, and engineers to develop a complex solution in a connected, cohesive, and comprehensive fashion.

Zachman’s principal insight is the way to solve the complexity of the enterprise architecture by decomposing the problem into two main dimensions, each of which consists of multiple subcategories. The first dimension defines the various levels of abstraction that represent business scope, conceptual level (business model), logical level (system model), and physical level (technology model). The second dimension consists of key decision-driving questions – what, how, where, who, when, and why. In the context of the enterprise architecture, these questions are considered at the different levels of the first dimension as follows:

• “What” answers the question about what data flows throughout the enterprise.
• “How” describes the functions and business processes performed by the different parts of the enterprise.
• “Where” defines the network that provides interprocess and intercomponent connectivity and information delivery.
• “Who” defines the people and organizational structures affected by the target architecture.
• “Why” represents business drivers for this architecture-based initiative.
• “When” defines the timing constraints and processing requirements.

Each question of the second dimension at every level of the first dimension represents a particular architecture viewpoint – for example, a logical data model view or a physical network architecture view. All these 30 viewpoints are organized together in the framework to comprise a complete enterprise architecture. Figure 4-2 shows a graphical representation of Zachman’s framework.

The representation in Figure 4-2 is based on the work published by Zachman’s Institute for Framework Advancement (ZIFA).

The value of such an architecture framework is its ability to act as a guide for organizing various design concerns into a set of separate but connected models. The framework benefits become apparent as the complexity and the heterogeneity of the system that is being designed increase. In the case of Master Data Management, this framework approach helps address the complexity of the individual functions and components; the integration of the new MDM environment with the legacy systems; and the need to implement an effective, efficient, secure, and manageable solution in a stepwise, controlled fashion.

Architecture Patterns

The other approach to solving complex system design and architecture challenges is the notion of architecture and design patterns. A pattern is a proven, successful, and reusable approach to solving a well-defined problem. Here are some specifics:

• A pattern is an approach to the solution that has been implemented successfully a number of times in the real world to solve a specific problem space.
• Typically, patterns are observed and documented in the course of successful real-life implementations.
• Patterns don’t solve every single aspect of every problem, and typically are focused on core, main aspects of the problem (following the law of the “trivial many and the critical few,” better known as Pareto’s Law, or the 80-20 Rule).
• When defined correctly, patterns are easy to apply to service-oriented architectures because they leverage object-oriented design principles, especially the notion of inheritance, by often inheriting components (objects) from already defined patterns.

Figure 4-2 Zachman’s enterprise architecture framework

 When we discuss architecture patterns, their primary benefit is in helping architects of complex systems such as MDM to identify various design options and understanding which options are most appropriate for a given problem domain. More often than not, individual patterns have to be combined with other patterns to define a solution to a particular business problem.

Patterns are different from architecture viewpoints. They tend to solve a well-defined, discrete problem space by providing proven, reusable choices. Architecture viewpoints, on the other hand, offer an opportunity to the architects and designers to view the problem from different angles to understand the interrelationships among the components, services, and other system objects and to formulate an approach to solve problems when the directional decisions have been made. In other words, a typical architecture viewpoint represents an aspect of the problem space that needs to be broken into a set of patterns that can be implemented with high confidence.

In MDM space, we use both architecture viewpoints and patterns, although patterns, by representing a more constraint problem domain, tend to provide a lower level of technical design.

 More about this book and others like it...

• Intrigued by this chapter excerpt? Download a free PDF of the entire chapter: MDM Architectural Considerations
• Read more excerpts and download more sample chapters from our Data Management bookshelf
• To purchase the book or similar titles, visit the McGraw-Hill website.