CHAPTER 13
Project Initiation
In the previous chapter we showed the approaches to building a robust and compelling business case for the MDM initiative, and also demonstrated the value and the scope of the MDM roadmap. At this point, let’s assume that the business case, the initial definition of the MDM roadmap, and the business drivers, objectives, and value propositions for the overall MDM program or specific MDM projects have been established and agreed upon within the organization. This agreement should result in senior management’s issuing marching orders to the Information Technology organization to proceed with the project.
Senior management will want to know how the project is to be organized and planned and the major project or program milestones. Senior management will also want to know how much this project would cost to develop and deploy. What should the IT organization do to translate business objectives and the roadmap into IT vision, strategy, and resource-loaded project plans, in order to successfully implement the project? Senior management will want to see the end-state vision across all business and technology domains, and will ask a number of key questions, such as how the currently ongoing projects should be modified, aligned, and prioritized in the context of the MDM project. Many of the questions have been answered to some extent by the business case and MDM roadmap definitional activities. In this chapter we concentrate on the further details and specifics of starting and running an already approved MDM project.
Implementation Begins
As we stated in Chapter 12, one of the key management challenges of MDM projects is the need to define the project’s success criteria. When asked informally, IT executives may provide very different answers to the question of how to decide if the project is successful, including answers such as “Have better quality data,” “Improve application functionality,” “Achieve regulatory compliance faster,” and “Keep the end users happy.” In practice, MDM projects should be based on a compelling, business strategy–driven and/or IT strategy–driven, agreed-upon and approved business case, and follow an MDM capabilities roadmap with a sound release strategy that defines what will be implemented and deployed, and when. Key components of this roadmap are clearly defined short-term and long-term success criteria that need to be understood and agreed upon by all stakeholders.
Of course, the tasks of defining the road map and success criteria would be so much easier to accomplish if there were a single strategy and solution architecture that works for all MDM implementations. Unfortunately, that is not the case. As we mentioned earlier, MDM projects address multiple, often diverse business requirements, involve a broad spectrum of technical disciplines, and can be extremely complex.
Addressing the Complexity of MDM Projects
At a high level all MDM projects are quite similar. For example, all MDM projects that focus on Customer domain have common goals of delivering an authoritative system of record for customer data that represents a complete, 360-degree view of customer including the totality of the relationships the customer has with the organization. At this high level, project management and all key stakeholders are enthusiastic and are in “violent” agreement about the capabilities and opportunities offered by the MDM Customer system.
The devil is in the details. And there are many details to consider. At the beginning and in the course of an MDM project, the wide variety of questions, issues, and dependencies may appear so overwhelming that the initiative’s stakeholders feel like the fishermen in the movie The Perfect Storm. The characters of the film were practically helpless before the fury of the ocean. The situation may seem similarly unmanageable for the participants of some MDM projects. Many large MDM projects failed with dire consequences for the company and people who worked on the project. We will discuss risks and reasons for project failure in Chapter 19.
To illustrate the diversity and criticality of the expectations of the MDM project stakeholders, let’s briefly recap key questions and concerns of senior management relevant to the MDM:
• How will the equity value and market capitalization of the company change as a result of the MDM project?
• What is the first set of applications and business functions that would become the early adopters and beneficiaries of the MDM project?
• What are the phase-by-phase and total project costs, ROI, and/or NPV?
• How will the new business processes be different?
• What will it take to accomplish the transition to the new business processes?
• What additional skills, both business and technology, will the organization’s staff members have to acquire and how?
• Will the organizational structure be affected, and to what extent?
• What legacy systems and functions will be affected and how?
• How will the project be organized and planned?
• What are the major milestones and releases?
• Does the technology organization have adequate knowledge, resources, and understanding of industry best practices in order to translate business objectives into IT vision, strategy, actionable road map and project plans, and successfully implement the project?
• What are the investment and delivery risks and mitigation strategies?
• What is the end-state vision that would impact business and technology domains?
• How should the current in-flight initiatives be modified, aligned, and prioritized in light of starting an MDM project?
• What are the success criteria for each phase and for the project overall?
MDM Ecosystem
From the overall program/project management perspective, it becomes increasingly clear that due to the variety of conditions and the complexity of MDM projects, it is difficult to define a single one-size-fits-all set of recommendations. Moreover, we showed in the previous chapter that a comprehensive MDM project roadmap includes at least 20 roadmap domains:
1. Business Benefits
2. Systems and Applications in Scope of MDM
3. Data Domains, Entities, and High-Level Data Model
4. Relationships, Hierarchies, and Metadata
5. Third-Party Data Sources
6. Systems Decommissioning Strategy
7. Data Hub Usage Style
8. Data Hub Architecture and Ownership Style
9. Data Volume, Performance, and Scalability Considerations
10. Reference Data Management
11. Deployment Strategies and User Groups
12. Related Initiatives
13. Master Data Governance Maturity
14. Master Data Quality Processes, Metrics, and Technology Support
15. Integration with Unstructured Data
16. Multilingual Requirements
17. Complexity of Cross-Domain Information Sharing
18. Complexity of Data Security and Visibility Requirements
19. People Resources and Skills
20. Data Quality Technologies: ETL, SOA, and ESB
All these factors and considerations contribute to the overall complexity of any MDM project. Experience shows that an effective working approach to manage this complexity and address broadly diverse problems such as the ones presented by MDM is to define a comprehensive solution framework that is designed around sound problem-solving design patterns and architecture principles, including separation of concerns, layered architecture, federation, and service orientation (please see Part II for more details on the architecture framework and design principles). Such a framework allows us to use industry best practices for particular areas of concern, and to break down the problem domain into smaller and more manageable pieces. At a more granular level the tasks and decision-making points are much more common and manageable across MDM projects. We will follow this approach and break down the MDM problem domain into work streams and components that support and are supported by what we define as the MDM “ecosystem.” The areas of concerns and key components that constitute a general MDM “ecosystem” are shown in Figure 13-1. We discuss most of them throughout this book in more detail.
The MDM “ecosystem” is a layered construct that includes business processes and technical domains of change. In the case of MDM for Customer domain, the core MDM functional area includes:
• Customer identification, matching, correlation, hierarchies, relationships, and grouping
• Information quality
• External data providers
FIGURE 13-1 MDM “ecosystem”: high-level areas of the solution
Note The first area in this list is specific to the MDM for Customer domain. It is easy to see that this focus on the customer can be substituted or complemented by other domains such as Products, Organizations, Locations, and so on.
The layer immediately surrounding the MDM core is a key part of the MDM “ecosystem” even though it includes some components that support both MDM and non-MDM environments. We discuss various aspects of these components throughout the book.
As we continue to “peel” the layers of the MDM “ecosystem,” we can see the components and services that do not necessarily represent “pure” MDM functionality, but are affected and/or required by the MDM system to function. For example, the legacy layer demonstrates these dual properties—it is usually the source of MDM data and is a key consumer of new functionality enabled by the MDM platform.
Similarly, the outer layers of the MDM “ecosystem” cover Infrastructure, Project/Program Management, and Change Control. These areas of concern are vital for any successful project, including MDM implementations. Indeed, it is hard to imagine a project of MDM magnitude that can be successful without considering infrastructure issues or providing adequate program management and change control.
MDM-related areas of the “ecosystem” contain components that have to be acquired or built. Thus, the MDM “ecosystem” also provides a framework for “buy vs. build” decisions. These decisions are not easy to make, especially considering that many vendor products in the MDM space provide similar, often overlapping capabilities, and the resulting market focus and positioning of many MDM vendors continues to change. For example, ETL and data synchronization vendors are moving into the Information Quality space, and Information Quality vendors are extending their capabilities toward MDM Data Hubs. A discussion of the vendor landscape and their product features can be found in Chapter 18.
Socializing the MDM Project with the Stakeholders
The complexity of the MDM problem space requires the participation of multiple stakeholders. This, in turn, creates a formidable socialization problem. The idea of bringing all people onto the same page on all issues can easily paralyze any initiative. While consensus building is a good strategy, we need to remember that both unlimited democracy and military-style Command and Control decision making can cause large initiatives to fail. Best practices suggest to set up a small leadership group that can successfully combine principles of strong management control and decision making with principles of sharing information and keeping all participants on common ground in key areas.
It is a good idea to start an MDM project with a well-structured workshop where the business vision and technology approach will be discussed. Two or three days spent as a team can be very beneficial to jump-starting the project by getting high-level agreement on a number of key issues.
Using a multi-phased approach to an MDM project is clearly a good strategy. The outcome of the first phase (first release of the MDM solution) should be thought of as a trade-off between what the business and executive management ultimately need and what is achievable in a single release. A practical rule of thumb is that each phase should not exceed six to eight months and should deliver tangible, business-recognizable benefits. Credibility of the project will be at stake if a year has gone by and no changes have been implemented. Enterprise-level planning should be in place to ensure successful cross-departmental delivery.
When an MDM project is initiated, the IT group should have access to business-sponsored documents that define the business case by business function and line of business. This set of business requirements documents should include the following:
• Formulation of business problems as they relate to MDM
• Definition of the business scope, including articulations of the new business processes
• Strategic business vision and objectives
• Business drivers and priorities
• ROI or Economic Value estimation for MDM implementation
Considering the complexity and potential breadth of the impact an MDM solution may have on the organization, defining the scope is one of the key factors that determines the actual or perceived success or failure of the MDM project.
Scope Definition
When we discuss MDM projects, we should realize that the scope of these projects is a multidimensional matter. The most important dimensions are shown in Figure 13-2 and discussed in this section.
FIGURE 13-2 Domains of scope
Business Processes
It is critically important to understand what business processes need to be improved. Without a clear understanding of what business processes will be improved and how, the entire effort may turn into a costly and most likely useless endeavor. Starting from the business objectives, drivers, and value propositions, the technology group should work with the business team to document the current state of the business processes that need to be improved. There are many methodologies on how to define and document business processes. The Rational Unified Process (RUP) is one of the better-known methodologies used for this purpose. RUP uses a concept of use cases as the core of business process analysis and definition. There are a number of excellent tutorials and references describing RUP, such as Philippe Kruchten’s book.1
Once the current state of the business processes and their weaknesses are defined and documented, the target-state business processes need to be determined. There are many techniques and methodologies on business process improvement and reengineering.2
What level of granularity in the business process definition is sufficient? If you need to describe the process of lawn mowing, you can do it at a high level, for example, get the lawn mower, turn it on, mow the lawn, clean the lawn mower, and put it back. Alternatively, you can describe this process with more granularity and show decision points, for example, what happens if you do not have enough gas, or what you do if the tool breaks, or how do you trim corners that cannot be reached by the lawnmower. The required granularity of the business process should be at the level of detail that is sufficient to define the logical data model of the MDM solution. This brings us to an important point. The data modelers should work closely with the business process development team to provide input and pose questions driving the depth of the business process coverage. Refer to the discussion on data modeling aspects of the MDM solution in Chapter 7 of this book.
Lines of Business and Functions
One of the outcomes of the creation and analysis of the business requirements for the project is the determination of new and impacted legacy business processes. At the same time, the requirements should specify the needs of key lines of business and business functions that drive the change. At that point, the requirements analysis should determine whether there are other lines of business that can benefit from the MDM-driven change. The perspective of these other lines of business is important for the enterprise in order to understand that additional benefits can be realized from implementing the MDM project. These additional requirements and benefits should be included in the MDM business case and may strengthen its value proposition.
In addition, a comprehensive view presented by all lines of business and functions early in the project life cycle can help understand constraints that otherwise would be revealed at later phases of the project with additional risks and costs always accompanying late changes in project planning and execution.
An understanding of all impacted lines of business should also help in building a project team that adequately represents all interested parties.
Customer Touch Points, Product Types, and Account Types
Modern enterprises frequently use multiple channels that support various customer touch points, where the customer could be an individual, an institutional customer, a partner, a supplier, and so on. For instance, individual customers can interact with a hotel chain by phone, personally in the hotel lobby, online over e-mail and the Internet, by mail, and so on. The same channels may provide additional touch points for customers who participate in hotel membership clubs or are hotel credit card holders; alternatively, the same channels can be used by travel agencies or the company’s travel department. Similar variety in the touch points exists in the financial services and other industries.
Analyzing the channel and touch point requirements helps bring into focus additional perspectives and questions that can impact the scope of the MDM project. Specifically, the customer data presented at different touch points may vary significantly, and as a result may impact the identification and matching process, data visibility, and security approaches. More generally, the channel and touch point properties have an impact on any master data entities that are available and accessible via these channels. We will discuss entity identification and matching in more detail in Chapter 14. Visibility and security are discussed in depth in Part III of the book.
A typical enterprise normally offers and serves many product types to its customers. In the financial services industry, for example, products are often linked to or represented by account types such as Wealth Management Account, Cash Management Account, 401K Retirement Account, and so on. Other industries also have a strong emphasis on products. For example, a telecommunications company can offer and provide local, long distance, and international phone service; Internet connectivity; wireless connectivity services; satellite or cable TV services; and so on. They may also offer their private label credit card and other financial instruments.
As industries define their specific portfolios of products and services, this view is very important to adequately define the scope and priorities of the planned MDM effort. This understanding can help bring a valuable perspective from the groups of existing or new stakeholders of the MDM project.
Levels of Aggregation and Relationship Types
This dimension of scope defines how the data should be aggregated. Typically data aggregation is an area discussed within data warehousing projects. If a data warehouse has already been built, the MDM project scope should answer the question of whether the MDM Data Hub will feed the data warehouse in the future and how the existing processes will be impacted. If the data warehouse is not yet available, we do not recommend mixing the MDM Data Hub project and a data warehousing effort, even though interdependencies between the two efforts should be well understood.
Although the creation of multiple data aggregation layers is not the primary focus of the MDM Data Hub, we should consider a data aggregation view that is directly associated with MDM Data Hubs. This particular data aggregation view is also known as a “single version of truth” for master data. We defined this new, MDM-inspired and -managed data aggregation view in Parts I and II of the book.
Indeed, a typical enterprise does not want to get rid of all of its customer records, even though some of them may exist in multiple versions. Thus, customer data aggregation enabled by an MDM Data Hub may reveal an enterprise’s intent to preserve and maintain the existing redundant customer records along with the new single version of truth for customer data. This is true for other data domains as well, so we’ll try to generalize these discussions by referring to master data entities throughout this chapter, and will revert to specific data domains such as Customer or Product only when the differences between the domain-related concerns warrant such specificity. Because by definition an MDM platform integrates all available data about the master entities into the authoritative system of record, this single version of truth represents an aggregated data view. We discuss MDM data aggregation in more detail in Chapter 14.
A discussion of relationship types that have to be supported and managed by the MDM platform is another important dimension of scope. MDM and entity relationships are discussed in Chapter 15.
Entities and Attributes
As the MDM project is initiated, an initial logical/canonical data model of the integrated solution should include all entities, key attributes, and other attributes (to the extent possible at this early project stage) required by the integrated solution regardless of which systems these data elements reside in at present. The canonical data model, described in Chapter 7, defines the entities in scope, and the relationships between the entities and data attributes in scope no matter where they physically reside.
Clearly, to enable proper MDM functionality, the data attributes used for entity resolution should be included in the model. However, some of the data attributes and entity types may not be available in any of the existing systems at all. Such a logical data model provides the organization with a technique to abstract their analysis from the complexities of the existing data structures and develop a desired consolidated data model that represents the business vision correctly.
It is not always easy to conceptualize the enterprise vision and abstract it from the organizational realities. Therefore, we highly recommend finding the right external partners specializing in logical data modeling, preferably with deep expertise in an appropriate subject area domain (that is, customer, product, subscriber, and so on.). Some domain-specific data models are published by their owners or vendors. As an example, see The Data Model Resource Book by Len Silverston.3,4,5 If you feel that the data models recommended by your partners do not entirely fit your organizational needs, which is not uncommon, your organization would still benefit from the experience of data modelers who have built proven industry-specific models. It is also very useful for project direction to get a clear understanding of why the industry model does not fit your organization’s business model. Whether you buy a data model from an external source or decide to develop it internally, discussions about the choices you need to consider in developing and deploying the data model for the MDM platform will enable the organization to establish a logical data model that defines the scope of the solution from the data attributes’ perspective.
There are other considerations that drive the scope of the canonical model. In addition to the initial scope, the team should determine the scope of the incremental data model changes as the MDM platform evolves from one release to the next.
Systems and Applications in Scope
Systems and applications are another important dimension of scope. Specifically, in a typical MDM Data Hub the data is sourced from multiple systems. A key question to answer is, when the MDM Data Hub is in production, how will the current systems be affected? Some applications and systems may have to be phased out, which is a significant scope issue that also determines the end-state of the solution and the work in the legacy system areas that must be planned.
Alternatively, existing legacy systems may have to coexist with the Data Hub. The discussion of what such a coexistence means will lead us to the topic of the next section about the MDM Data Hub solution architecture.
MDM Data Hub Solution Architecture
As the process of the project scope definition reaches a point where the team gains a consensus about entities, data attributes, products/account types, and other business requirements, the MDM project can move into the next phase to decide upon architectural choices for the MDM Data Hub. MDM products and solutions known as MDM Data Hubs are designed to support data structures, functions, and services that enable rationalization, integration, and delivery of master data across multiple data domains. A conceptual MDM Data Hub architecture, described in detail in Part II of the book, recognizes a number of options that can be used to solve master data creation and continuous integration problems in the context of the business requirements of a given enterprise. Let’s review these architecture options as they have been defined by several industry analysts, most notably by the industry research firm The Gartner Group. Although the extensive discussion on the MDM architecture viewpoints, and specifically on the Design and Deployment architecture dimension (sometimes referred to as MDM data ownership and architecture styles) has been provided in Part II of this book, the follow-on section in this chapter provides an implementation analysis of the MDM architecture styles and offers some insights into and variations of the architecture options for these styles, which are based on the authors’ practical experience implementing MDM solutions.
Data Hub Architecture Styles
Using the architecture framework approach introduced in Part II of the book, we can recognize some generally accepted architecture “styles” as the architecture viewpoints that determine the way the MDM system is intended to be used and kept reliably in sync with its data providers (data sources) and data consumers. These viewpoints represent an intersection of the functional and data dimensions of the enterprise architecture framework at the logical, conceptual, and contextual levels. Specifically, let’s review the three most popular MDM architecture styles.
Registry Hub
The Registry-style Data Hub uses a metadata repository, or a stand-alone Data Attribute directory that points to the locations of the data attributes using specialized Data Hub services called the Attribute Locator service and the Metadata service (see Chapters 4–6 for more details on the Data Hub services). Figure 13-3 illustrates the way the Registry-style Hub operates. For instance, the metadata repository should store the rules about the retrieval of the “best” entity attributes (for example, a customer name), the “best” (that is, authoritative) source for entity type (for example, account type), and so on. The rules can be complex enough to take into account multiple conditions and scenarios. The Data Hub of this style stores only key identifiers and links them to the fragments of master data in source systems. In addition, the Registry-style Data Hub supports data transformations necessary to achieve semantic consistency and reconciliation. The Registry-style Data Hub provides a real-time reference by dynamically assembling an integrated but read-only master data view from the source systems.
FIGURE 13-3 Registry Hub
The Registry Hub is the right choice if the company’s strategy is to preserve the existing systems and invest their development funds to fix and enhance legacy systems over time. Considerations for and against a Registry-style Data Hub are shown in the following list.
Pros:
• The lowest-cost master data integration solution.
• The data flow changes are limited and implementation risks are minimized.
• Only limited data reconciliation between the legacy and the new Data Hub systems is required.
Cons:
• If the Data Hub has to support complex business rules including data survivorship, the data access (query) performance of the Hub can be an issue. The term “data survivorship” refers to the rules defining how to assemble a single record from two or more records with overlapping attributes that may contain conflicting values. In this case the attributes “compete” for survivorship to resolve the conflicts.
• Query performance represents an even bigger concern when multiple systems must be accessed to retrieve the data.
Coexistence Hub
The Coexistence Hub architecture style of the Data Hub (see Figure 13-4) physically stores some master data along with referencing some other data in the source systems. This Data Hub style is not used to directly originate transactions, but is updated from the source systems that initiate transactions. The Data Hub is used as a central reference point for master data. In addition to the master entities, this style of MDM Data Hub can also store relationship data, entity grouping, and so on, with specifics dependent on the industry and organizational needs.
The Coexistence Hub bridges some gaps in the existing systems. It is the right choice if the company’s strategy is to partially preserve the existing systems and decommission at least some of the legacy systems. The Coexistence Hub style is sometimes used as a step toward a Transaction Hub. Its advantages and disadvantages are summarized in the following list.
Pros:
• The Coexistence Data Hub solution cost is relatively low.
• Data flow is limited to unidirectional synchronization.
• Data retrieval performance issues are resolved by storing certain data attributes in the Data Hub. The complexity of data transformation is moved to ETL.
Cons:
• ETL transformations that are required to maintain Data Hub content can be fairly complex.
• Since the Coexistence-style Data Hub assumes some data redundancy, its design should provide for synchronization and reconciliation of data changes between the source systems and the Data Hub.
FIGURE 13-4 Coexistence Hub
Transaction Hub
This Data Hub style physically stores the master entities and is used as the authoritative system of record for master data, as shown in Figure 13-5. This style of Data Hub supports services that apply data access transactions directly to the Data Hub and generate messages or batch files that publish the results of the transactions to the systems external to the Data Hub. The Transaction Hub is the right choice when the organization does not intend to invest additional money and resources in the source systems for the data domains where the Data Hub must become the master. In this case, a prudent approach is to prepare to support significant data flow changes in the existing system structure, including the decommissioning of some of the legacy systems. Transaction Hub advantages and disadvantages are shown in the following list.
Pros:
• This is a comprehensive solution that can be used to phase out obsolete legacy systems.
• This architecture style of the Data Hub allows organizations to achieve at least one of the major MDM goals—the creation of an accurate, timely, and complete system of record that maintains just-in-time data accuracy and integrity.
FIGURE 13-5 Transaction Hub
Cons:
• This architecture style of the Data Hub results in the highest complexity of ETL implementation.
• This style requires complex real-time synchronization and reconciliation. Therefore, it usually demands the highest cost and implementation risk. The complexity of data synchronization is discussed in Chapter 16.
• This style requires that careful attention is paid to the extensibility and scalability aspects of the Data Hub design by including MDM services and components such as a robust metadata repository and Record and Attributor Location services so that on-boarding new systems and data sources does not require a significant or complete overhaul of the MDM system.
The taxonomy of the three architecture styles illustrates an interesting pattern: The richness of the Data Hub functionality and the complexity and the associated risks of MDM implementations increase as the Hub stores and manages more and more entities and attributes of master data. Therefore, MDM projects need to carefully evaluate the benefits and risks associated with each approach and decide on the appropriate balance of these factors for implementing an MDM solution in a phased, risk-managed fashion.
Phased Implementation of Customer Data Hub
Even if an ultimate goal of the MDM project is to develop a Transaction Hub solution, in order to achieve this goal and to manage the risks and impact of implementing a Transaction Hub, an MDM project typically begins with a “slim” Data Hub implementation. The plan should be to evolve the Data Hub by increasing the number of data attributes for which it acts as a master. As the Data Hub data scope grows, so does the value that the Data Hub provides to the organization. From the project management point of view, this evolutionary change should be organized into well-defined project phases, starting with the Project Initiation phase, which is the subject of this chapter.
Using this approach as a guide, we recommend a somewhat different categorization of the MDM Data Hub styles that are more aligned with phased implementation as shown in Figure 13-6.
FIGURE 13-6 Data Hub phased implementation
Artifacts That Should Be Produced in the Project Initiation Phase
Typical artifacts that are to be produced at the end of the Project Initiation phase are shown in the following list:
• Business process analysis (current state)
• Requirements for business process improvement and re-engineering (desired target state of the business processes)
• Incremental business process changes by release
• Incremental benefits by business function and line of business
• State of the solution architecture by release
• Conceptual and logical data model of the integrated solution and how it ties back to the business processes
• Scope and priority definitions in terms of data attributes, entity/products/account evolves with the implementation releases
• Vendor product evaluation criteria, buy vs. build decision, and tool recommendation/selection for the key areas of MDM Data Hub functionality
Project Work Streams
In the beginning of this chapter we mentioned that an effective methodology to managing complex projects such as a MDM Data Hub is to use a phased approach and organize the work and resources into a number of interconnected and interdependent work streams. The following work streams typically represent the body of work that needs to be planned and executed:
• Entity resolution—Entity (for example, customer/account, legal entities) groups and relationships
• Data governance, standards, quality, and compliance
• Data architecture
• Metadata and related services, including Record Locator service, Attribute Locator service, and Metadata Repository service
• Initial data load
• Inbound data processing (batch and real-time)
• Outbound data processing (batch and real-time)
• Changes to legacy systems and applications
• Visibility and security
• Exception processing
• Infrastructure
• Testing
• Release management
• Deployment
• Training
• Project management
To sum up, if you are planning to embark on an MDM effort, this list can be used as a guide to build a detailed project plan including appropriate resources and the project team composition. Each of these work streams should have clearly defined deliverables that have to be aligned at the entire project level in order to produce a cohesive and comprehensive solution. Although these work streams define different interdependent efforts that prevent the work streams from being executed in a totally parallel fashion, many of these work streams can be structured so that their dependency on each other is minimized and the overall project timeline is optimized to parallelize as much work as possible. We will cover the areas addressed by these work streams in the chapters that follow.
References
1. Kruchten, Philippe. The Rational Unified Process: An Introduction, Third Edition. Addison-Wesley (2003).
2. Jeston, John and Johan Nelis. Business Process Management: Practical Guidelines to Successful Implementations. Butterworth-Heinemann (2006).
3. Silverston, Len. The Data Model Resource Book, Vol. 1: A Library of Universal Data Models for All Enterprises. Wiley Computer Publishing (March 2001).
4. Silverston, Len. The Data Model Resource Book, Revised Edition, Vol. 2: A Library of Universal Data Models For Specific Industries. Wiley Computer Publishing (March 2001).
5. Silverston, Len and Angew, Paul. The Data Model Resource Book, Vol. 3: Universal Patterns for Data Modeling. Wiley Computer Publishing (January 2009).