Modeling the MDM Blueprint – Part 5

In this series, we’ve discussed developing the MDM blueprint by creating the Common Information (Part 2), Canonical (Part 3), and Operating (Part 4) models in our work streams. We’ve introduced the Operating Model into the mix to communicate with the business how the solution will be adopted and used to realize the expected benefits. And hopefully we’ve set reasonable expectations with our business partners as to what this solution will look like when deployed.

Now, it’s time to model and apply the technical infrastructure or patterns we plan on using. The blueprint now moves from being computation and platform independent to one of expressing intent through the use of more concrete platform-specific models.

Reference Architecture

After the initial (CIM, Canonical, and Operating models) work is completed, then, and only then, are we ready to move on to the computation and platform specific models. We know how to do this – for example see Information ServicePatterns, Part 4: Master Data Management architecture patterns.

At this point, we now have enough information to create the reference architecture. One way (there are several) to organize this content is to use the Rozanski and Woods extensions to the classic 4+1 view model introduced by Philippe Kruchten. The views are used to describe the system in the viewpoint of different stakeholders (end-users, developers and project managers). The four views of the model are logical, development, process and physical view. In addition, selected use cases or scenarios are used to demonstrate or show the architecture’s intent. Which is why the model contains 4+1 views (the +1 being the selected scenarios).

Rozanski and Woods extended this idea by introducing a catalog of six core viewpoints for information systems architecture: the Functional, Information, Concurrency, Development, Deployment, and Operational viewpoints and related perspectives. This is elaborated in detail in their book titled “Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives”.  There is much to learn from their work, I encourage you to visit the book’s web site for more information.

What we are describing here is how MDM leadership within very large-scale organizations can eventually realize the five key “markers” or characteristics in the reference architecture to include:

• Shared services architecture evolving to process hubs;
• Sophisticated hierarchy management;
• High-performance identity management;
• Data governance-ready framework; and
• Registry, persisted or hybrid design options in the selected architecture.

This is an exceptional way to tie the technical models back to the stakeholders needs, as reflected in the viewpoints, perspectives, guidelines, principles, and template models used in the reference architecture. Grady Booch said “… the 4+1 view model has proven to be both necessary and sufficient for most interesting systems”, and there is no doubt that MDM is interesting. Once this work has been accomplished and agreed to as part of a common vision, we have several different options to proceed with. One interesting approach is leveraging this effort into a Service Orientated Modeling Framework introduced by Michael Bell at Methodologies Corporation.

Service-Oriented Modeling

The service-oriented modeling framework (SOMF) is a development life cycle methodology. It offers a number of modeling practices and disciplines that contribute to a successful service-oriented life cycle management and modeling. It illustrates the major elements that identify the “what to do” aspects of a service development scheme.

These are the modeling pillars that will enable practitioners to craft an effective project plan and to identify the milestones of a service-oriented initiative—in this case crafting an effective MDM solution.  SOMF provides four major SOA modeling styles that are useful throughout a service life cycle (conceptualization, discovery and analysis, business integration, logical design, conceptual and logical architecture).

These modeling styles: Circular, Hierarchical, Network, and Star, can assist us with the following modeling aspects:

• Identify service relationships: contextual and technological affiliations
• Establish message routes between consumers and services
• Provide efficient service orchestration and choreography methods
• Create powerful service transaction and behavioral patterns
• Offer valuable service packaging solutions

SOMF Modeling Styles

SOMF offers four major service-oriented modeling styles. Each pattern identifies the various approaches and strategies that one should consider employing when modeling MDM services in a SOA environment.

Circular Modeling Style: enables message exchange in a circular fashion, rather than employing a controller to carry out the distribution of messages. The Circular Style also offers a way to affiliate services.

Hierarchical Modeling Style: offers a relationship pattern between services for the purpose of establishing transactions and message exchange routes between consumers and services. The Hierarchical pattern enforces parent/child associations between services and lends itself to a well known taxonomy.

Network Modeling Style: this pattern establishes “many to many” relationship between services, their peer services, and consumers similar to RDF. The Network pattern accentuates on distributed environments and interoperable computing networks.

Star Modeling Style: the Star pattern advocates arranging services in a star formation, in which the central service passes messages to its extending arms. The Star modeling style is often used in “multi casting” or “publish and subscribe” instances, where “solicitation” or “fire and forget” message styles are involved.

There is much more to this method, so I encourage you to visit the Methodologies Corporation site and download the tools, power point presentations, and articles they’ve shared.

Summary

Based on my experience, we have to get this modeling effort completed to improve the probability we’ll be successful. MDM is really just another set of tools and processes for modeling and managing business knowledge of data in a sustainable way. Take the time to develop a robust blueprint to include the Common Information (semantic, pragmatic and logical modeling), Canonical (business rules and format specifications), and Operating Models to ensure completeness. Use these models to drive a suitable Reference Architecture to guide design choices in the technical implementation.

This is hard, difficult work. Anything worthwhile usually is. Why put the business at risk to solve this important and urgent need without our stakeholders understanding and real enthusiasm for shared success? A key differentiator and the difference between success and failure on an MDM journey is taking the time to model the blueprint and share this early and often with the business. This is after all a business project, not an elegant technical exercise. Creating and sharing a common vision through our modeling efforts helps ensure success from inception through adoption by communicating clearly the business and technical intent of each element of the MDM program.

In the last part of the series, I’ll discuss where all this fits into the larger MDM program and how to plan, organize, and complete this work.

Modeling the MDM Blueprint – Part 4

In Part 2 and Part 3 of this series, we discussed the Common Information and Canonical Models. Because MDM is a business project, we need to establish of a common set of models that can be referenced independently of the technical infrastructure or patterns we plan on using. Now it is time to introduce the Operating Model to communicate how the solution will actually be deployed and used to realize the expected benefits.

This is the most important set of models you will undertake. And sadly, not widely accounted for “in the wild”, meaning rarely seen, much less achieved. This effort describes how the organization will govern, create, maintain, use, and analyze consistent, complete, contextual, and accurate data values for all stakeholders.

There are a couple of ways to do this. One interesting approach I’ve seen is to use the Galbraith Star Model as an organizational design framework. The model is developed within this framework to understand what design policies and guidelines will be needed to align organizational decision making and behavior within the MDM initiative.

The Star model includes the following five categories:

Strategy: Determine direction through goals, objectives, values and mission. It defines the criteria for selecting an organizational structure (for example functional or balanced matrix). The strategy defines the ways of making the best trade-off between alternatives.

Structure: Determines the location of decision making power. Structure policies can be subdivided into:
- specialization: type and number of job specialties;
- shape: the span of control at each level in the hierarchy;
- distribution of power: the level of centralization versus decentralization;
- departmentalization: the basis to form departments (function, product, process, market or geography).

In our case, this will really help when it comes time to designing the entitlement and data steward functions.

Processes: The flow of information and decision processes across the proposed organization’s structure. Processes can be either vertical through planning and budgeting, or horizontal through lateral relationships (matrix).

Reward Systems: Influence the motivation of organization members to align employee goals with the organization’s objectives.

People and Policies: Influence and define employee’s mindsets and skills through recruitment, promotion, rotation, training and development.

Now before your eyes glaze over, I’m only suggesting this be used as a starting point. We’re not originating much of this thought capital, only examining the impact the adoption of MDM will have on the operating model within this framework. And more importantly, identifying how any gaps uncovered will be addressed to ensure this model remains internally consistent. After all, we do want to enable the kind of behavior we expect in order to be effective, right?

A typical design sequence starts with an understanding of the strategy as defined. This in turns drives the organizational structure. Processes are based on the organization’s structure. Structure and Processes define the implementation of reward systems and people policies.

The preferred sequence in this design process is composed in the following order: (a) strategy; (b) structure;  (c) key processes; (d) key people; (e) roles and responsibilities; (f) information systems (supporting and ancillary); (g) performance measures and rewards; (h) training and development; (i) career paths.

The design process can be accomplished using a variety of tools and techniques. I have used IDEF, BPMN or other process management methods and tools (including RASIC charts describing roles and responsibilities, for example). What ever tools you elect to use, they should effectively communicate intent and be used to validate changes with the stakeholders, who must be engaged in this process.

Armed with a clear understanding of how the Star model works we can turn our attention to specific MDM model elements to include:

Master Data Life Cycle Management processes
- Process used to standardize the way the asset (data) is used across an enterprise
- Process to coordinate and manage the lifecycle of master data
- How to understand and model the lifecycle of each business object using state machines (UML)
- Process to externalize business rules locked in proprietary applications (ERP) for use with Business Rules Management Systems (BRMS) (if you’re lucky enough to have one )
- Operating Unit interaction
- Stewardship (Governance Model)
- Version and variant management, permission management, approval processes
- Context (languages, countries, channels, organizations, etc.) and inheritance of reference data values between contexts
- Hierarchy management
- Lineage (historical), auditability, traceability

I know this seems like a lot of work. Ensuring success and widespread adoption of Master Data Management mandates this kind of clear understanding and shared vision among all stakeholders. We do this to communicate how the solution will actually be deployed and used to realize the benefits we expect.

In many respects, this is the business equivalent to the Technical Debt concept Ward Cunningham developed (we’ll address this in the next part on Reference Architecture) to help us think about this problem. Recall this metaphor means doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort we have to do in future development because of the quick and dirty design choices we have made. The same concept applies to this effort. The most elegant technical design may be the worst possible fit for the business. The interest due in a case like this is, well, unthinkable.

Take the time to get this right. You will be rewarded with enthusiastic and supportive sponsors who will welcome your efforts to achieve success within an operating model they understand.

Modeling the MDM Blueprint – Part 5

digg this | del.icio.us | Reddit | Stumble It!

In this series, we’ve discussed developing the MDM blueprint by creating the Common Information (Part 2), Canonical (Part 3), and Operating (Part 4) models in our work streams. We’ve introduced the Operating Model into the mix to communicate with the business how the solution will be adopted and used to realize the expected benefits. And hopefully we’ve set reasonable expectations with our business partners as to what this solution will look like when deployed.

Now, it’s time to model and apply the technical infrastructure or patterns we plan on using. The blueprint now moves from being computation and platform independent to one of expressing intent through the use of more concrete platform-specific models.

Reference Architecture

After the initial (CIM, Canonical, and Operating models) work is completed, then, and only then, are we ready to move on to the computation and platform specific models. We know how to do this – for example see Information ServicePatterns, Part 4: Master Data Management architecture patterns.

At this point, we now have enough information to create the reference architecture. One way (there are several) to organize this content is to use the Rozanski and Woods extensions to the classic 4+1 view model introduced by Philippe Kruchten. The views are used to describe the system in the viewpoint of different stakeholders (end-users, developers and project managers). The four views of the model are logical, development, process and physical view. In addition, selected use cases or scenarios are used to demonstrate or show the architecture’s intent. Which is why the model contains 4+1 views (the +1 being the selected scenarios).

Rozanski and Woods extended this idea by introducing a catalog of six core viewpoints for information systems architecture: the Functional, Information, Concurrency, Development, Deployment, and Operational viewpoints and related perspectives. This is elaborated in detail in their book titled “Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives”.  There is much to learn from their work, I encourage you to visit the book’s web site for more information.

What we are describing here is how MDM leadership within very large-scale organizations can eventually realize the five key “markers” or characteristics in the reference architecture to include:

• Shared services architecture evolving to process hubs;
• Sophisticated hierarchy management;
• High-performance identity management;
• Data governance-ready framework; and
• Registry, persisted or hybrid design options in the selected architecture.

This is an exceptional way to tie the technical models back to the stakeholders needs, as reflected in the viewpoints, perspectives, guidelines, principles, and template models used in the reference architecture. Grady Booch said “… the 4+1 view model has proven to be both necessary and sufficient for most interesting systems”, and there is no doubt that MDM is interesting. Once this work has been accomplished and agreed to as part of a common vision, we have several different options to proceed with. One interesting approach is leveraging this effort into a Service Orientated Modeling Framework introduced by Michael Bell at Methodologies Corporation.

Service-Oriented Modeling

The service-oriented modeling framework (SOMF) is a development life cycle methodology. It offers a number of modeling practices and disciplines that contribute to a successful service-oriented life cycle management and modeling. It illustrates the major elements that identify the “what to do” aspects of a service development scheme.

These are the modeling pillars that will enable practitioners to craft an effective project plan and to identify the milestones of a service-oriented initiative—in this case crafting an effective MDM solution.  SOMF provides four major SOA modeling styles that are useful throughout a service life cycle (conceptualization, discovery and analysis, business integration, logical design, conceptual and logical architecture).

These modeling styles: Circular, Hierarchical, Network, and Star, can assist us with the following modeling aspects:

• Identify service relationships: contextual and technological affiliations
• Establish message routes between consumers and services
• Provide efficient service orchestration and choreography methods
• Create powerful service transaction and behavioral patterns
• Offer valuable service packaging solutions

SOMF Modeling Styles

SOMF offers four major service-oriented modeling styles. Each pattern identifies the various approaches and strategies that one should consider employing when modeling MDM services in a SOA environment.

Circular Modeling Style: enables message exchange in a circular fashion, rather than employing a controller to carry out the distribution of messages. The Circular Style also offers a way to affiliate services.

Hierarchical Modeling Style: offers a relationship pattern between services for the purpose of establishing transactions and message exchange routes between consumers and services. The Hierarchical pattern enforces parent/child associations between services and lends itself to a well known taxonomy.

Network Modeling Style: this pattern establishes “many to many” relationship between services, their peer services, and consumers similar to RDF. The Network pattern accentuates on distributed environments and interoperable computing networks.

Star Modeling Style: the Star pattern advocates arranging services in a star formation, in which the central service passes messages to its extending arms. The Star modeling style is often used in “multi casting” or “publish and subscribe” instances, where “solicitation” or “fire and forget” message styles are involved.

There is much more to this method, so I encourage you to visit the Methodologies Corporation site and download the tools, power point presentations, and articles they’ve shared.

Summary

Based on my experience, we have to get this modeling effort completed to improve the probability we’ll be successful. MDM is really just another set of tools and processes for modeling and managing business knowledge of data in a sustainable way. Take the time to develop a robust blueprint to include the Common Information (semantic, pragmatic and logical modeling), Canonical (business rules and format specifications), and Operating Models to ensure completeness. Use these models to drive a suitable Reference Architecture to guide design choices in the technical implementation.

This is hard, difficult work. Anything worthwhile usually is. Why put the business at risk to solve this important and urgent need without our stakeholders understanding and real enthusiasm for shared success? A key differentiator and the difference between success and failure on an MDM journey is taking the time to model the blueprint and share this early and often with the business. This is after all a business project, not an elegant technical exercise. Creating and sharing a common vision through our modeling efforts helps ensure success from inception through adoption by communicating clearly the business and technical intent of each element of the MDM program.

In the last part of the series, I’ll discuss where all this fits into the larger MDM program and how to plan, organize, and complete this work.

Continue with Part 6 or go back to Part 4.

Modeling the MDM Blueprint – Part 4

digg this | del.icio.us | Reddit | Stumble It!

In Part 2 and Part 3 of this series, we discussed the Common Information and Canonical Models. Because MDM is a business project, we need to establish of a common set of models that can be referenced independently of the technical infrastructure or patterns we plan on using. Now it is time to introduce the Operating Model to communicate how the solution will actually be deployed and used to realize the expected benefits.

This is the most important set of models you will undertake. And sadly, not widely accounted for “in the wild”, meaning rarely seen, much less achieved. This effort describes how the organization will govern, create, maintain, use, and analyze consistent, complete, contextual, and accurate data values for all stakeholders.

There are a couple of ways to do this. One interesting approach I’ve seen is to use the Galbraith Star Model as an organizational design framework. The model is developed within this framework to understand what design policies and guidelines will be needed to align organizational decision making and behavior within the MDM initiative.

The Star model includes the following five categories:

Strategy: Determine direction through goals, objectives, values and mission. It defines the criteria for selecting an organizational structure (for example functional or balanced matrix). The strategy defines the ways of making the best trade-off between alternatives.

Structure: Determines the location of decision making power. Structure policies can be subdivided into:
- specialization: type and number of job specialties;
- shape: the span of control at each level in the hierarchy;
- distribution of power: the level of centralization versus decentralization;
- departmentalization: the basis to form departments (function, product, process, market or geography).

In our case, this will really help when it comes time to designing the entitlement and data steward functions.

Processes: The flow of information and decision processes across the proposed organization’s structure. Processes can be either vertical through planning and budgeting, or horizontal through lateral relationships (matrix).

Reward Systems: Influence the motivation of organization members to align employee goals with the organization’s objectives.

People and Policies: Influence and define employee’s mindsets and skills through recruitment, promotion, rotation, training and development.

Now before your eyes glaze over, I’m only suggesting this be used as a starting point. We’re not originating much of this thought capital, only examining the impact the adoption of MDM will have on the operating model within this framework. And more importantly, identifying how any gaps uncovered will be addressed to ensure this model remains internally consistent. After all, we do want to enable the kind of behavior we expect in order to be effective, right?

A typical design sequence starts with an understanding of the strategy as defined. This in turns drives the organizational structure. Processes are based on the organization’s structure. Structure and Processes define the implementation of reward systems and people policies.

The preferred sequence in this design process is composed in the following order: (a) strategy; (b) structure;  (c) key processes; (d) key people; (e) roles and responsibilities; (f) information systems (supporting and ancillary); (g) performance measures and rewards; (h) training and development; (i) career paths. 

The design process can be accomplished using a variety of tools and techniques. I have used IDEF, BPMN or other process management methods and tools (including RASIC charts describing roles and responsibilities, for example). What ever tools you elect to use, they should effectively communicate intent and be used to validate changes with the stakeholders, who must be engaged in this process.

Armed with a clear understanding of how the Star model works we can turn our attention to specific MDM model elements to include:

Master Data Life Cycle Management processes
- Process used to standardize the way the asset (data) is used across an enterprise
- Process to coordinate and manage the lifecycle of master data
- How to understand and model the lifecycle of each business object using state machines (UML)
- Process to externalize business rules locked in proprietary applications (ERP) for use with Business Rules Management Systems (BRMS) (if you’re lucky enough to have one )
- Operating Unit interaction
- Stewardship (Governance Model)
- Version and variant management, permission management, approval processes
- Context (languages, countries, channels, organizations, etc.) and inheritance of reference data values between contexts
- Hierarchy management
- Lineage (historical), auditability, traceability

I know this seems like a lot of work. Ensuring success and widespread adoption of Master Data Management mandates this kind of clear understanding and shared vision among all stakeholders. We do this to communicate how the solution will actually be deployed and used to realize the benefits we expect.

In many respects, this is the business equivalent to the Technical Debt concept Ward Cunningham developed (we’ll address this in the next part on Reference Architecture) to help us think about this problem. Recall this metaphor means doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort we have to do in future development because of the quick and dirty design choices we have made. The same concept applies to this effort. The most elegant technical design may be the worst possible fit for the business. The interest due in a case like this is, well, unthinkable.

Take the time to get this right. You will be rewarded with enthusiastic and supportive sponsors who will welcome your efforts to achieve success within an operating model they understand.

Continue with Part 5 or go back to Part 3.