Modeling the MDM Blueprint – Part 6

In this series, we’ve discussed developing the MDM blueprint by developing the Common Information (Part 2), Canonical (Part 3) , and Operating (Part 4) models in our work. Part 5 introduced the Reference Architecture model into the mix to apply the technical infrastructure or patterns we plan on using.

The blueprint has now moved from being computation and platform independent to one that expresses intent through the use of more concrete platform-specific models. The solution specification is now documented (independent of the functional Business Requirements) to provide shared insight into the overall design.

Now, it’s time to bring the modeling products together and incorporate them into a MDM solution specification we can use in many ways to communicate the intent of the project.

First, the MDM blueprint specification becomes the vehicle for communicating the system’s design to interested stakeholders at each stage of its evolution. The blueprint can be used by:

• Downstream designers and implementers to provide overall policy and design guidance. This establishes inviolable constraints (and a certain amount of freedom) on downstream development activities.
• Testers and integrators to dictate the correct black-box behavior of the pieces that must fit together.
• Technical managers as the basis for forming development teams corresponding to the work assignments identified.
• Project managers as the basis for a work breakdown structure, planning, allocation of project resources, and tracking of progress by the various teams.
• Designers of other systems with which this one must interoperate to define the set of operations provided and required, and the protocols for their operation, that allows the inter-operation to take place.

Second, the MDM blueprint specification provides a basis for performing up-front analysis to validate (or uncover deficiencies in) design decisions and refine or alter those decisions where necessary. The blueprint could be used by:

• Architects and requirements engineers who represent the customer. The MDM blueprint specification becomes the forum for negotiating and making trade-offs among competing requirements.
• Architects and component designers as a vehicle for arbitrating resource contention and establishing performance and other kinds of run-time resource consumption budgets.
• Development using vendor-provided products from the commercial marketplace to establish the possibilities for commercial off-the-shelf (COTS) component integration by setting system and component boundaries and establishing requirements for the required behavior and quality properties of those components.
• Architects to evaluate the ability of the design to meet the system’s quality objectives. The MDM blueprint specification serves as the input for architectural evaluation methods such as the Software Architecture Analysis Method [and the Architecture Tradeoff Analysis Method (ATAM-SM) and Software Performance Engineering (SPE) as well as less ambitious (and less effective) activities such as unfocused design walkthroughs.
• Performance engineers as the formal model that drives analytical tools such as rate schedulers, simulations, and simulation generators.
• Development product line managers to determine whether a potential new member of a product family is in or out of scope, and if out, by how much.

Third, the MDM blueprint becomes the first artifact used to achieve system understanding for:

• Technical managers, as the basis for conformance checking, for assurance that implementations have in fact been faithful to the architectural prescriptions.
• Maintainers, as a starting point for maintenance activities, revealing the areas a prospective change will affect.
• New project members, as the first artifact for familiarization with a system’s design.
• New architects, as the artifacts that (if properly documented) preserve and capture the previous incumbent’s knowledge and rationale.
• Re-engineers, as the first artifact recovered from a program understanding activity or (in the event that the architecture is known or has already been recovered) the artifact that drives program understanding activities at the appropriate level of component granularity.

Blueprint for MDM - Where this fits within a larger program

Developing and refining the MDM blueprint is typically associated with larger programs or strategic initiatives. In this last part of the series, I'll discuss where all this typically fits within a larger program and how to organize and plan this work within context.

The following diagram (click to enlarge and use your browser to magnify the png file) puts our modeling efforts within the context of a larger program taken from a mix of actual engagements with large, global customers. The key MDM blueprint components are highlighted with numbers representing:

1. Common Information Model
2. The Canonical Model
3. The Operating Model
4. The Reference Architecture

Click to enlarge

I have also assumed a business case exists (you have this right?) and the functional requirements are known. Taken together with the MDM blueprint, we now have a powerful arsenal of robust information products we can use to prepare a high quality solution specification that is relevant and can be used to meet a wide variety of needs.

Typically, use of the MDM blueprint may include:

• Identifying all necessary components and services
• Reviewing existing progress to validate (or uncover deficiencies in) design decisions; refine or alter those decisions where necessary
• Preparation of detailed planning products (Product, Organization, and Work Breakdown structures)
• Program planning and coordination of resources
• Facilitating prioritization of key requirements – technical and business
• Development of Request for Quotation, Request for Information products (make vs. buy)
• Preparing funding estimates (Capital and Operating Expense) and program budget preparation
• Understanding a vendor’s contribution to the solution and pricing accordingly (for example, repurpose as needed in contract and licensing activities and decouple supplier proprietary lock-in from the solution where appropriate)

We are also helping to ensure the business needs drive the solution by mitigating the impact of the dreaded Vendor Driven Architecture (VDA) in the MDM solution specification.

Summary

I hope you have enjoyed this brief journey through “Modeling the MDM Blueprint” and have gained something from my experience. I’m always interested in learning from others, so please let me know what you’ve encountered yourself, and maybe we can help others avoid the pitfalls and pain in this difficult demanding work.

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. In an early reference, I mentioned Ward Cunningham’s Technical Debt concept. 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 technical debt and resulting interest due in MDM initiative with this kind of far-reaching impact across the enterprise is, well, unthinkable.

Take the time to develop your MDM blueprint and use this product to ensure success by clearly communicating business and technical intent with your stakeholders.

Go back to Part 5.