1) Develop a clear and unambiguous understanding of the current state

2) Define the desired end state

3) Conduct a Gap Analysis exercise

4) Prioritize the findings from the Gap Analysis exercise into a series of gap closure strategies

5) Discover the optimum sequence of actions (recognizing predecessor – successor relationships)

6) Develop and Publish the Road Map

I have discussed a way to quickly complete step one (1) Define current State . This post will discuss how to craft a suitable desired End State definition so we can use the results from the Current State work and begin our gap analysis. Our intent is to identify the difference (delta) from where we are to what we aspire to become. I know this seems obvious (and maybe a little redundant). This baseline is critical to identify what needs to be accomplished to meet the challenge.

The reality of organizational dynamics and politics (we are human after all) can distort the reality we are seeking here and truly obscure the findings. I think this happens in our quest to preserve the preferred “optics”. This is especially so when trying to define our desired end state. The business will have a set of strategic goals and objectives that may not align with the individuals we are collaborating with to discover what the tactical interpretation of this end state really means. We are seeking a quick or structured way to define a desired end state that can be reviewed and approved by all stakeholders when this activity gets underway.  The tactical realization of the strategy (and objectives) is usually delegated (and rightly so) to the front line management. The real challenge is eliciting, compiling, and gaining agreement on what this desired end state means to each of the stakeholders. This is not an easy exercise and demands a true mastery of communication and facilitation skills many are not comfortable with or have exercised on a regular basis.  A clear understanding of the complex interaction of any organization (and their un-intended consequences) is critical to a clear understanding of the desired end state.

Define Desired End State

There are a couple of ways to do this. One interesting approach I have 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. 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).
• 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.

The preferred sequence in this design process is composed in the following order:

• strategy;
• structure;
• key processes;
• key people;
• roles and responsibilities;
• information systems (supporting and ancillary);
• performance measures and rewards;
• training and development; and
• career paths.

Strategy Model – Click to enlarge

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 further refine reward systems and policy. Beginning with Strategy we uncover a shared set of goals (and related objectives) to define the desired end state organized around the following categories:

• People/Organization considers the human side of Information Management, looking at how people are measured, motivated and supported in related activities.  Those organizations that motivate staff to think about information as a strategic asset tend to extract more value from their systems and overcome shortcomings in other categories.
• Policy considers the message to staff from leadership.  The assessment considers whether staff is required to administer and maintain information assets appropriately and whether there are consequences for inappropriate behaviors.  Without good policies and executive support it is difficult to promote good practices even with the right supporting tools.
• Process and Practice considers whether the organization has adopted standardized approaches to Information Management.  Even with the right tools, measurement approaches and policies, information assets cannot be sustained unless processes are consistently implemented.  Poor processes result in inconsistent data and a lack of trust by stakeholders.
• Technology covers the tools provided to staff to properly meet their Information Management duties.  While technology on its own cannot fill gaps in the information resources, a lack of technological support makes it impractical to establish good practices.

Goal Setting

Goal setting is a process of determining what the stakeholder’s goals are, working towards them and measuring progress to plan. A generally accepted process for setting goals uses the SMART acronym (Specific, Measurable, Achievable, Realistic, and Timely). Each of these attributes related to the goal setting exercise is described below.

• Specific: A specific goal has a much greater chance of being accomplished than a general goal.  Don’t “boil the ocean” and try to remain as focused as possible. Provide enough detail so that there is little or no confusion as to what exactly the stakeholder should be doing.
• Measurable: Goals should be measurable so we can measure progress to plan as it occurs. A measurable goal has an outcome that can be assessed either on a sliding scale (1-10), or as a hit or miss, success or failure. Without measurement, it is impossible to sustain and manage the other aspects of the framework.
• Achievable: An achievable goal has an outcome that is realistic given the organization’s capability to deliver given the necessary resources and time. Goal achievement may be more of a “stretch” if the outcome is more difficult to begin with. Is what we are asking the organization possible?
• Realistic: Start small and remain sharply focused with what the organization can and will do and let the stakeholder’s experience the joys of meeting their goals.  Gradually increase the intensity of the goal after having a discussion with the stakeholder’s to redefine the goal.  Is our goal realistic given the budget and timing constraints?  If not, then we might want to redefine the goal.
• Time Bound: Set a timeframe for the goal: for next quarter, in six months, by one year. Setting an end point for the goal gives the stakeholders a clear target to achieve.  Planning follow-up should occur within the 6-month period (best practice) but may occur within one year period or prior based on progress to plan.

Defining the desired end state is accomplished through a set of questions used to draw participants into the process to meet our SMART objectives.  This set of questions is compiled, evaluated, and presented in a way that is easy to understand. Our goal here is to help everyone participating in the work to immediately grasp where the true gaps or shortcomings exist and why this is occurring when we get to step three (3) in the gap analysis phase.  This is true if we are evaluating Information Strategy, our readiness to embrace a SOA initiative, or launching a new business initiative. We can complete the design process by 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). Whatever tools you elect to use, they should effectively communicate intent and used to validate changes with the stakeholders who must be engaged in this process.

Now this is where many of us come up short.  Where do I find the questions to help drive SMART goals? How to I make sure they are relevant? What is this engine I need to compile the results? And how do I quickly compile the results dynamically and publish for comment every time I need to?

One of the answers for me came a few years ago when I first saw the MIKE 2.0 quick assessment engine for Information Maturity. The Information Maturity (IM) Quick Scan is the MIKE 2.0 tool used to assess current and desired Information Maturity levels within an organization. This survey instrument is broad in scope and is intended to assess enterprise capabilities as opposed to focusing on a single subject area. Although this instrument focuses on Information Maturity I realized quickly I had been doing something similar for years across many other domains. The real value here is in the open source resource you can use to kick start your own efforts.  I think it is also a good idea to become familiar with the benchmarks and process classification framework the American Productivity and Quality Center (APQC) has made available for a variety of industries. The APQC is a terrific source for discovering measures and quantifiable metrics useful for meeting the need for specific, measurable objectives to support the end state definition.

How it Works

The questions in the quick scan are organized around six (6) key groups in this domain to include Organization, Policy, Technology, Compliance, Measurement, and Process/Practice.  The results are tabulated based on responses (in the case of the MIKE 2.0 template) ranging from zero (0 – Never) to five (5 – Always).  Of course you can customize response the real point here is we want to quantify the responses received.  The engine component takes the results builds a summary, and produces accompanying tabs where radar graphs plots present the Framework, Topic, Lookup, # Questions, Total Score, Average Score, and Optimum within each grouping.  The MS Word document template then links to this worksheet and grabs the values and radar charts produced to assemble the final document. If all this sounds confusing, please grab the templates and try them for yourself.

Define Desired End State Model – Click to Enlarge

The groupings (and related sub-topics) are organized out of the box like this to include the following perspectives:

• Compliance
• Measurement
• People/organization
• Policy
• Process/Practice
• Technology

Each of these perspectives is summarized and combined into a MS Word document to present to the stakeholders.  The best part of this tool is it can be used periodically augment quantitative measures (captured in a dashboard for example) to assess progress to plan and improvement realized over time. Quantifying improvement quickly is vital to continued adoption of change. Communicating the results is stakeholders in quick, easy-to-understand format they are already familiar with is just as important using the same consistent, repeatable tool we used to define current state with.

Results

I think you can see this is valuable way to reduce complexity and gather, compile, and present a fairly comprehensive view of the desired end state of the domain in question. Armed with this view we can now proceed to step three (3) and begin to conduct the Gap Analysis exercise. The difference (delta) between these two (current and desired end state) becomes the basis for our road map development.  I hope this has answered many of the questions about step two (2) Define End State. This is not the only way to do this, but has become the most consistent and repeatable methods I’m aware of to define a desired end state quickly in my practice.  Understandings the gaps between the current and the desired end-state across the business, information, application, and technical architecture make development of a robust solution delivery road map possible.

In an earlier post (How to Build a Roadmap) I discussed the specific steps required to develop a defensible, well thought out road map to identify specific actions using an overall pattern all roadmaps should follow. The steps required to complete this work:

• Develop a clear and unambiguous understanding of the current state
• Define the desired end state
• Conduct a Gap Analysis exercise
• Prioritize the findings from the Gap Analysis exercise into a series of gap closure strategies
• Discover the optimum sequence of actions (recognizing predecessor – successor relationships)
• Develop the Road Map

I have received a lot of questions about step one (1) which is understandable given the lack of details about just how to quickly gather real quantifiable objectives and potential functional gaps. In the interest of simplicity and my attempt  to keep the length of the prior post manageable specific details about how to do this were omitted.

This post will provide a little more exposition and insight into one method I have found useful in practice. Done well, it can provide an honest and objective look in the mirror to successfully understand where we truly are as an organization and face the uncomfortable truth in some cases where we need to improve.  The reality of the organizational dynamic and politics (we are human after all) can distort the reality we are seeking here and truly obscure the findings. I think this happens in our quest to preserve the preferred “optics” without an objective and shared method all stakeholders are aware of and approve before embarking down this path. In the worst case, if left to the hands of outside consultants alone or in the hands of an unskilled practitioner we risk creating more harm than good before even starting. This is why I will present a quick, structured way to gather and evaluate current state that can be reviewed and approved by all stakeholders before the activity even gets underway.  Our objective is to develop a clear and unambiguous understanding of the current state. We should have a formal, well understood way to gather and evaluate the results.

Define Current State

First, we need to have a shared, coherent set of questions we can use to draw participants into the process that are relevant and can be quantified.  This set of questions should be able to be compiled, evaluated, and presented in a way which is easy to understand. Everyone participating in the work should be able to immediately grasp where the true gaps or shortcomings exist and why this is occurring.  This is true if we are evaluating Information Strategy, our readiness to embrace a SOA initiative, or launching a new business initiative. So, we need just a few key components.

A pool or set of relevant questions that can be answered quickly by the participants and results quantified An engine to compile the results A quick way to compile and summarize the results for distribution to the stakeholders

Now this is where many of us come up short.  Where do I find the questions and how to I make sure they are relevant? What is this engine I need to compile the results? And how do I quickly compile the results dynamically and publish for comment every time I need to? One of the answers for me came a few years ago when I first saw the MIKE 2.0 quick assessment engine for Information Maturity .

The Information Maturity (IM) Quick Scan is the MIKE 2.0 tool used to assess current and desired Information Maturity levels within an organization. This survey instrument is broad in scope and is intended to assess enterprise capabilities as opposed to focusing on a single subject area.  Although this instrument focuses on Information Maturity I realized quickly I had been doing something similar for years across many other domains. The real value here is in the open source resource you can use to kick start your own efforts.

So what does this do?

I’m going to focus on the Mike 2.0 tools here because they are readily available to you. The MS Office templates you need can be found at http://mike2.openmethodology.org/wiki/QuickScan_MS_Office_survey.

Extending these templates into other subject areas is pretty simple once you understand how they work. The basic premise remains the same it really is just a matter of injecting your own subject matter expertise and organizing the results in a way that makes sense to you and your organization.  So here is what you will find there.

First a set of questions organized around the following categories:

• People/Organization considers the human side of Information Management, looking at how people are measured, motivated and supported in related activities.  Those organizations that motivate staff to think about information as a strategic asset tend to extract more value from their systems and overcome shortcomings in other categories.
• Policy considers the message to staff from leadership.  The assessment considers whether staffs are required to administer and maintain information assets appropriately and whether there consequences for inappropriate behaviours.  Without good policies and executive support it is difficult to promote good practices even with the right supporting tools.
• Technology covers the tools that are provided to staff to properly meet their Information Management duties.  While technology on its own cannot fill gaps in the information resources, a lack of technological support makes it impractical to establish good practices.
• Compliance surveys the external Information Management obligations of the organization.  A low compliance score indicates that the organization is relying on luck rather than good practice to avoid regulatory and legal issues.
• Measurement looks at how the organization identifies information issues and analyses its data.  Without measurement, it is impossible to sustainably manage the other aspects of the framework.
• Process and Practice considers whether the organization has adopted standardized approaches to Information Management.  Even with the right tools, measurement approaches and policies, information assets cannot be sustained unless processes are consistently implemented.  Poor processes result in inconsistent data and a lack of trust by stakeholders.

The templates include an engine to compile the results and a MS Word document template to render and present the results. Because it is based on MS Office the Assessment_Questions.xlsx, Assessment_Engine.xlsx, and Assessment_Report.docx are linked (rather than relative, they use MS’s way –really hardcoded to find linked files in the c:\assessment folder – yikes!) so that you open and score the Assessment_Questions first, then the Assessment_Engine picks these values and creates a nice tabbed interface and charts across all six subject areas. The Word document picks this up further and creates the customized report.

You can extend this basic model to include your own relevant questions in other domains (for example ESB or SOA related, Business Intelligence).  We are going to stick with the Information Maturity quick scan for now. Note I have extended a similar model to include SOA Readiness, BI/.DW, and Business Strategy Assessments.

How it Works

The questions in the quick scan are organized around six (6) key groups in this domain to include Organization, Policy, Technology, Compliance, Measurement, and Process/Practice.  The results are tabulated based on responses (in the case of the MIKE 2.0 template) ranging from zero (0 – Never) to five (5 – Always).  Of course you can customize response the real point here is we want to quantify the responses received.

The engine component takes the results builds a summary, and produces accompanying tabs where radar graphs plots present the Framework, Topic, Lookup, # Questions, Total Score, Average Score, and Optimum within each grouping.  The MS Word document template then links to this worksheet and grabs the values and radar charts produced to assemble the final document. If all this sounds confusing, please grab the templates and try them for yourself.

Define Current State Model

Each of these six (6) perspectives is then summarized and combined into a MS Word document to present to the stakeholders.

Results

I think you can see this is valuable way to reduce complexity and gather, compile, and present a fairly comprehensive view of the current state of the domain (in this case Information Management Maturity) in question. Armed with this quantified information we can now proceed to step 3 and conduct a Gap Analysis exercise based on our understanding of what is the desired end state. The delta between these two (current and desired end state) becomes the basis for our road map development.  I hope this has answered many of the questions about step one (1) Define Current State. This is not the only way to do this, but has become the most consistent and repeatable methods I’m aware of to quickly define current state in my practice.

I’m no genius, just believe I have been blessed to come into the industry at a time when the large management consulting firms actually invested in intellectual property and shared this with the “new hires” and up-and-coming staff like me. Investing in structured thinking, communication skills, or just plain good old analytic skills makes sense.  Why there is not more of this kind of investment is truly troubling.

What I’m going to share works well across most transformation programs. You will struggle to find this in textbooks, class rooms, or in your local book store (I have looked, maybe not hard enough). This method I will share is based loosely on the SEI-CM IDEAL model used to guide development of longe-range integrated planning for managing software process improvement programs. You will most likely find something similar to this in the best and brightest organizations who have adopted an optimized way to think about how to guide their organizations to perform as expected (some of us call this experience). Now on to the summary of what I want to share, the balance will be revealed in an upcoming series using the adoption of Master Data Management as an example.

The Overall Pattern

At the risk of over-simplifying things, here is the overall pattern ALL roadmaps follow:

Click to enlarge

1) Develop a clear and unambiguous understanding of the current state

- Business Objectives (not just strategy or goals, real quantifiable objectives)
- Functional needs
- High impact business processes or cycles
- Organization (current operating model)
- Cost and complexity drivers
- Business and technical assets (some call these artifacts)

2) Define desired end state
First, (know this is obvious) what are trying to accomplish? Is there an existing goal-driven strategy clearly articulated into quantifiable objectives? Sounds silly doesn’t it, and if this exists and a no one knows about it or cannot clearly communicate what the end game is we have a problem. This could be a well guarded secret. Or, what is more common the line of sight from executive leadership down to the mail room is broken, where no one knows what the true goals are or cares (it’s just a job after all) becomes a annual charade of MBO objectives with no real understanding.  Some better examples I would expect include:

- Performance targets (Cash flow, Profitability, Velocity (cycle or PCE), Growth, Customer intimacy)
- Operating Model Improvements
- Guiding principals

3) Conduct Gap Analysis
Okay, now this is where the true fun starts. Once here we can begin to evaluate the DELTA between who we really are, and what we truly want to become.  Armed with a clear understanding of where we are and where we want to be, the actionable activities begin to fall out and become evident. Gap closure strategies can then begin to be discussed, shared, and resolved into any number of possibilities usually involving the following initiatives:

- Organizational
- Functional
- Architectural (technology)
- Process
- Reward or economic incentives

For the enterprise architect the following diagram illustrates a sample index or collection of your findings to this point focused across the four architecture domains (Business, Information, Application, and Technology) related to the architecture.  Note how this is aligned into the enterprise architecture meta-model you can see over at the Essential project. The DELTA in this case represents the recommended Gap Closure Strategy between current and desired end states. Or put simply, the actionable things we need to do to close the gap between where are, and where we want to be.

Click to enlarge

4) Prioritize
Now that we have the list of actionable items it is time to prioritize what is front of us. This is usually driven (in a technology road map) by evaluating the relative business value AND the technical complexity, plotting the results in a quadrant graph of some kind. It is critical here that the stakeholders are engaged in the collection of the data points and they are keenly aware of what they are scoring. At the end of the day, what we are doing here is IDENTIFYING what is feasible and what has the highest business value. I know, I know this sounds obvious, and you would be astonished by how often this does not occur.

5) Discover the Optimum Sequence
Okay, now we have the initiatives, the prioritization, how about sequence? In other words are there things we have to get accomplished first, before others? Are there dependencies we have identified that need to be satisfied before moving forward? This sounds foolish as well, and we sometimes we need to learn how to crawl, walk, run, ride a bike, and then drive a motor vehicle. And what about the capacity for any organization to absorb change? Hmmm… Not to be overlooked, this where a clear understanding of the organizational dynamics is critical (see step number 1, this is why we need to truly understand where we are).

6) Develop the Road Map
Now we are ready to develop the road map. Armed with the DELTA (current vs. desired end state), the prioritization effort (what should be done), and the optimum sequence (in what order) we can begin to assemble a sensible, defensible road map describing what should be done in what order.  How this is communicated is critical now. We have the facts, we have the path outlined, and we have a defensible position to share with our peers. We have the details readily available to support our position. Now the really difficult exercise rears its ugly head. Somehow, we need to distill and simply our message to what I call the “Duckies and Goats” view of the world.  In other words we need to distill all of this work into a simplified yet compelling vision of how we transform an organization, or enabling technology to accomplish what is needed.  Do not underestimate this task, after all the hard work put into an exercise like this, the last thing we need to do is to confuse our stakeholders with mind-numbing detail. Yes, we need this for ourselves to exhaust any possibility we have missed something. And to ensure we haven’t overlooked the obvious – not sure who said this but “when something is obvious, it may be obviously wrong”.  Here is another example of a visual diagram depicting an adoption of Master Data Management platform in its first year.

Click to enlarge

So, this is the basic pattern describing how a robust roadmap should be developed for any organization across any discipline (business or technology) to ensure an effective planning effort. Wanted to share this with you to help you with your own work, this is usually not an exercise to be taken lightly. We are after all discussing some real world impacts to many, all the while understanding the laws of unintended consequences, to come up with a set of actionable steps to take along the way that just make sense. This method has worked for me time after time. I think this may just work for you as well. More on this later…

First, how about a little context?  I believe (and I think you will too) that architecture is a comprehensive framework of well understood processes used to manage and align an organization’s IS assets with:

• People and Organization (Structure)
• Processes, and
• Technology used to meet specific, actionable strategic business goals.

For example, reference the Galbraith Star Model.
A typical design sequence (in my world) starts with an understanding of the strategy as defined by the business. 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 policy.

This is one way to understand our true role in architecture management is to ensure technology investment and widespread adoption within the organization occurs because:

• The investment has value,
• The program (projects) will be properly managed,
• The organization has the capability to deliver the benefits,
• Dedicated resources are working on the highest value opportunities,
• Projects with inter-dependencies are undertaken in the optimum sequence.

Actionable objectives this function (architecture) enables include:

• Driving costs (not shifting them) from the business processes meta-cycles and improve value-added efficiency across operating models
  • Cycle time reduction
  • Error reduction
  • Resource liberation
  • Cost reduction
  • Cost avoidance
• Turning service portfolio investment into an operational variable cost which can relate directly to business volume
  • The business should only pay for what they use…
  • Can budget for services on a per usage basis
  • Use Strategic decision-making framework to:
    • manage cascading goals to evaluate corporate or shared goals along a vertical and horizontal axis to mitigate alignment issues
    • use functional views to focus IS investment choices
  • Realizing economic value through business process improvement as a:
    • Vehicle to drive measurable performance improvement:
      • Reduces defects embedded at the design stage of lifecycle by applying architectural principals
      • Uses problem solving approach upstream, reducing operational rework costs.
  • Enable process optimization through continuous, complimentary investment in reengineering and organizational development.

Our work then is to develop and promote management’s use of architecture to drive costs out of the organization and continue to meet stakeholder demands for distinctive, quality products and services.  The value proposition we bring should include detailed findings and quantitative methods to uncover how to accomplish this to meet the following objectives:

• Improved planning helps to make more informed decisions. Ensures project plans are complete and consistent with business priorities and addresses the impact of changes (alignment) as needed.
• Technology investments can be managed using consistent, repeatable processes to effectively build (acquire), maintain, and retire these assets over their useful life.
• We can enable cost efficiencies through elimination or consolidation of redundant or obsolete resources.
• Delivering quality information, designed and architected for the enterprise as a whole, has proven time and time again to be faster and less expensive by:
  • Reducing complexity
  • Encouraging component reuse
  • Improving communications within the organization
  • Providing a standardized, easy-to-use reference models and templates.
• We can significantly improve IT and business alignment by encouraging the rapid adoption of technology to meet changing business needs in an effective manner. Improved service levels to key constituents — customers, employees, partners.
• Encourage less expensive development and delivery by reusing and leveraging previously-developed shared services and products. Results in lower maintenance and integration costs. Provide a logical construction blueprint for defining and controlling the integration of systems and components by combining organizational, data, and business processes.
• Communicate using common terminology, standard descriptions, and generally accepted industry standards between the business and technology providers.

Delivering Value

The following section represents the majority of the business value I have helped other organizations uncover and exploit through the architecture function. We should be able to quickly discover and describe each of the opportunities we encounter within technology management alone (forget about the business for now) to include:

• Plan to Manage (Lifecycle),
• Manage to Availability (Protect),
• Request to Resolve (Support), and
• Develop to Deploy (Develop).

We should be able to tie service orientation for example, to its impact on one or more target metrics – use short-term tactical focus to start with and describe its impact (i.e., quantify its value, examples are included) in terms of:

• Process Cycle Efficiency (reduce the time to close a defect by 40% within three months)
• Time (Reduce system testing time by three weeks on the next project)
• Accuracy (Improve schedule estimation accuracy to within 10% of actual)
• Resources (Reduce maintenance costs by 50% within one year)
  • People
  • Money
  • Physical (e.g., physical plant, infrastructure)

The following themes represent the significant elements we should examine and evaluate for the size and relative scale of the respective opportunity that can be realized.

Communications

• Communicate effective alignment of IS strategy
  • Clear understanding of the current and future direction
  • Ensure business focus is on the highest priority and mission critical efforts.
  • Make more informed decisions
    • Control Strategic Scope and economic intent
    • Enhance investment decision-making by providing ready access to the business to information about the people, processes, and technology.
    • Assess the impact and mitigate risks associated with tactical decisions.
• Improve Service levels
• Produce Higher Quality Products
  • Improved reliability
  • Predictability (variance reduction). Methods to deliver services and information in a consistent and structured manner.
• Increase project success rates
• Meet operational goals and objectives
  • Process control objectives
  • Professional staff is accountable for compliance with policy and management direction.
  • Optimize activity objectives

Efficiency

• Shorten work cycles
  • Improve Process Cycle Efficiency
    • Shift focus to value-added activities
    • Minimize Non-Value-Added activity
    • Eliminate obsolete non-value added practices
    • Optimize Essential Non-Value-Added-But-Necessary activity
  • Schedules
  • Maintenance costs
  • Development time
• Reduce costly rework
• Leverage Economies of Scale – Consolidation
  • Leverage existing IS assets
  • Shared knowledge base
  • Infrastructure and Shared Services
  • Skills and resources
• Reduce or eliminate redundant investment
• Promote Interoperability
  • Identify opportunities for vertical and horizontal interoperability between business units.  Improve or reuse existing IS assets.
• Improve developer productivity
  • Leverage strengths of different types of developers.
  • Preserves business logic by isolating significant changes to “plumbing”
• Reduce Need for Customization
  • Lower labor costs and lower Total Cost of Ownership
• Enable vendor independence
• Leverage the benefits of Standardization
  • Use standard, reusable components and services
    • Proven – Based on field experience
    • Authoritative – Offer the best advice available
    • Accurate – Technically validated and tested
    • Actionable – Provide the steps to success
    • Relevant – Address real-world problems
  • Use common processes, methods and tools
    • Tooling
    • Wizards
    • Templates
    • Metadata, Code configuration generation

Agility

• Adapt quickly to changing business needs that require significant requirement changes
• Accommodate Emerging Technologies
• Engineering Life Cycle Support
  • Streamlined Governance and Stewardship
    • Meet Process control objectives
    • Optimize activity objectives
  • Guidance for tasks such as deployment and operations
• Prepare for New Opportunities
  • Off-shoring
  • Emerging technologies
• Improved Speed to Market
  • Increased productivity due to the need to develop and test only code that is related to business requirements.
• Higher levels of customer satisfaction
• Improve communications
• Illustrate and communicate the business of the enterprise to all stakeholders
• Common terminology and semantics
  • Standard descriptions
  • Generally accepted industry standards and models
  • Promote Global collaboration
• Improve Risk Mitigation Strategies
  • Leverage proven Business Reference Models
  • Identify Capacity Planning needs and impact
  • Reuse previously identified Solution Set patterns that link preferred Business, Information, and Technology Architecture Components.
  • Provide explicit linkage between stated business goals and the solution proposal (clear line-of-sight).
• Support Innovation
• Identify opportunities to employ innovative processes and technology.

Quality

• Drive one or more systems to common “use” or purpose
  • Shared information is more accurate. Information is collected once and used many times, avoiding the misunderstandings and keying errors associated with multiple collection points.
  • Shared information is more timely. Information can be made available instantly rather than waiting for a separate collection effort.
  • Shared information is more complete. Information from multiple sources can be assembled into a full description.
  • Shared information is less expensive. Information costs much less to store data and send it to another user than it does to collect it again.
• Work Product Impact
  • Less variance in work products
    • Provide atomic solutions to recurring problems (Solve problems once)
    • Application Frameworks standardize the way in which a class of problems is solved.
    • Set of classes which enforce the architecture
  • Teach developers how to use it
  • Support and evolve framework

This is how I have demonstrated real business value in my practice. Not sure why this is still questioned unless our role remains a mystery (poor communications) or maybe we have simply not executed (execution failure does happen).  So hopefully this has helped some of you to understand and place into “business terms” the kind of value we should be delivering to our business peers.  And more important to all of us in the profession is how we can define an effective value proposition to share benefits that can be realized in a sustained, consistent, and repeatable manner.  Thanks for listening…

That was a mouthful. You may want to read that last sentence again carefully. And think about what this means to you as a professional practitioner.  More importantly, how this may change the way you think about application platforms in general.

Before diving into this important concept, I think it is always good idea to express our stated design goals right up front – and use these to guide the inevitable trade-offs and decisions that will need to be made along this journey. So let’s get started with a few design goals I’m comfortable with. I’m sure there are more, but this represents a good start.

The platform’s ability to scale must be completely transparent

The architecture should be based on technology that can be deployed across a grid of commodity hardware nodes, providing a scalable and adaptable platform that supports high-volume, high-performance processing. The resulting platform should be tolerant of failure in individual nodes, can be matched to changing volumes easily by increasing (or decreasing) the number of processing nodes and, by virtue of its decoupled business logic, is extendible and adaptable to evolve as the business landscape changes.

Unlike conventional application server models, our elastic application platform should not require application developers to do anything different in their code in order to scale. The developer uses a simple API that provides a vast key-value data store that looks like a large shared memory space. Underneath the covers distributed caching features of the application platform spread the data across multiple servers (e.g. using a sophisticated hash algorithm). The application developer should remain unaware of the underlying implementation that distributes the data across the servers on his behalf. In brief, the goal of the grid-enabled middleware is designed to hide complexities of partitioning, distributing, and load balancing.

The platform provides resiliency by design

Applications must be available to customers and expected service level objectives must be met.  The business cannot afford a single point of failure to impact customer access to other features and functions of the customer applications suite otherwise available. The platform should operate continuously and needs to be highly resilient to avoid any interruption in processing. This means that the application suite cannot have any single point of failure in the software, hardware, or network. High Availability (HA) is a basic requirement.  Failing services and application components will continue on different backup servers, without service disruption.

Distributed data caches are resilient by design because they should automatically replicate data stored in the cache to one or more backup servers, guided by the policies defined by an administrator and executed in a consistent controlled manner. If one server fails, then another server provides the data (the more replicas, the more resilient the cache). Note, distributed data caches can be vulnerable to data center outages if all the compute servers are located in the same physical data center. To address this weakness, the distributed caching mechanism should offer special WAN features to replicate and recover data across multiple physical locations. The improvement in resilience reduces the risk of expensive system down-time due to hardware or software failure, allowing the business to continue operating albeit with reduced performance, during partial outages. An added benefit of this architecture composed of discrete units working together would enable rapid development and a controlled introduction of new features in response to changing requirements without the need for a big-bang rollout approach.

The platform is prepared to meet demanding performance requirements

A performance characteristic of distributed caches is that they store data in fast-access memory rather than on disk, although backing store on disk may be an option. Since this data spans multiple servers, there is no bottleneck or single point of failure. Using this advanced elastic application platform provides a means to ensure that cached data will tend to be on the same server where application code is processing, reducing network latency. We can do this by implementing a “near-cache” concept that places data on the server running the application using that data or by directly managing application code execution in the platform, placing adjacent code and data in cache nodes that are on the same server.

The platform needs to support robust integratation with other data sources

Most distributed caching platforms offer read-through, write-through, and write-behind features to synchronize data in the cache with external data sources. Rather than the developer having to write the code that does this, an administrator configures the cache to automatically read or write to a database or other external data source whenever an application performs a data operation in the cache. Data is an asset that is valuable. Sharing this asset across the platform improves the ability to support better data enrichment, improve accuracy and meet business goals.

The platform’s application workload is by nature distributed

For elastic application platforms offering distributed code execution we should consider the nature of the workload the applications will present to servers. If we can divide the workload into units that naturally fit into the distribution schemes as offered then the greater sophistication of the distributed code execution capability can be just what’s needed to turn a troublesome, resource intensive application into one that performs well and meets expectations.

Specific application responsibilities that repeat (or are redundant) across the application architecture should be separated out in the application architecture.  Shared global or common use application functional solutions are sometimes referred to as “cross-cutting concerns” and forward the key principle of “separation of concerns”. The platform should support component designs which minimize coupling.  The law of Demeter (Principle of Least Knowledge or only know your neighbor applies). The platform should promote loose coupling by minimizing:

• dependency between modules (e.g. shared global variables)
• discouraging content coupling (one module relying on another’s content)
• protocol or format dependencies
• control based coupling where one program controls another’s behavior
• Non-traceable message coupling which can lead to a dynamic spaghetti-like results impossible to manage

There are other goals I have not addressed here which we should all be familiar with to include:

• Desire to BUY vs. Build and Maintain
• Remain Technology and Vendor Independent
• Promote Interoperability
• Meet security and privacy needs

So, now we have a better idea of the design goals we are going to try to achieve. I think it is always important to take these goals to the next step in the high-level specification in order to begin quantifying how we will meet these into actionable objectives. Remember our original strategy which has driven our design goals. The design goals now should be used to create quantifiable objectives we can plan and measure progress to.

Wide open spaces - Wyoming

Okay, okay – know I should keep this blog more up to date, just have been a little busy with my day job… and now after a much needed rest in last weeks in August I can now share a few things you may find especially interesting and timely.  It is no coincidence that the image accompanying this post is of wide open spaces. This is in fact where I spent most satisfying part of my “summer vacation”.  And spaces (Tuple Spaces) is what I intend to share with you in the coming weeks.           

As architects we have a professional responsibility to always remain on the look-out for new (and sometimes revisited) ideas about how to improve and adopt good ideas. Especially when our business needs to invest in some key technology changes to remain competitive and deliver value customers will continue to seek for its distinctive quality of service and value.            

I have been pretty busy in the last year engaged in a variety of industries where road map development and execution of next generation platforms and paradigm shifts were needed.  Many of the more difficult challenges were solved by adopting a Space-Based Architecture (SBA) architecture pattern. This is a demonstrated pattern used to achieve near linear scalability of stateful, high-performance applications using the tuple spaces. This is not a new idea; the tuple space model was developed by David Gelernter over thirty years ago at Yale University. Implementations of tuple spaces have also been developed for Smalltalk, Java (JavaSpaces), and the .NET framework). A tuple space is an implementation of the associative memory model for parallel (distributed) computing by providing a repository of tuples that can be accessed concurrently. I know, this is a mouthful and a little too academic for me too. What this really means is we can group processors that produce pieces of data and group processors that use the data. Producers post their data as tuples in the space, and the consumers then retrieve data from the space that match a certain pattern. This is also known as the blackboard metaphor. Tuple spaces may be thought as a form of distributed shared memory. The model is closely related to other patterns that have been proved successful in addressing the application scalability challenge used by Google and Amazon.com (EC2) for example. The model has also been applied by many firms in the securities industry for implementing scalable electronic securities trading applications for example.   

Before you think I have gone daft on you, I recommend you see a commercial implementation of this at Gigaspaces.  Review the site and developer documentation and you will see how this platform is used to embrace many of the principles of Representational State Transfer (REST), service-oriented architecture (SOA) and Event-driven architecture (EDA), as well as elements of grid computing.  The beauty of the space based architecture resides in its tandem of simplicity and power. Compared to other models for developing distributed applications, it offers simpler design, savings in development and debugging effort, and more robust results that are easier to maintain and integrate.          

The pattern represents a model that combines and integrates distributed caching (Data Grid), content-based distributed messaging (Messaging Grid), and parallel processing (Processing Grid) into a powerful service oriented architecture built on shared spaces within a grid computing framework. Research results and commercial use have shown that a large number of problems in parallel and distributed computing have been solved using this architecture. And the implications of its adoption beyond high performance On-Line Transaction Processing extend well into other uses (including Master Data Management, Complex Event Processing, and Rules Processing for example).           

And this is what I intend to share with you in the coming weeks. 
Wide open spaces…

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) 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 mangers 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 will now 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 vendors contribution to the solution and pricing accordingly (for example, repurpose as needed in contract and licensing activities and decouple supplier proprietary lock-in from 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, please let me know what you have encountered yourself, and maybe we can help others avoid the pitfalls and pain in this difficult demanding work.  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.  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 that 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.

Now it is 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 well – for example see Information service patterns, 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 organization 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 architecture selected.

Recommended, 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 Orientated Modeling
The service-oriented modeling framework (SOMF) is a service-oriented 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, encourage you to visit the Methodologies Corporation site (Michael is the founder) and download the tools, power point presentations, and articles they have shared with us.

Summary
So, based on my experience we have to get this modeling effort completed to improve the probability we will 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 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 will be discussing where all this fits into the larger MDM program and how to plan, organize, and complete this work.

This is the most important set of models you will undertake. And sadly not accounted for in practice “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 have 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 are 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 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 life-cycle 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 are 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 will 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 that 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.

- Common Information Model
- Canonical Model
- Operating Model, and
- Reference Architecture (e.g. 4+1 views, viewpoints and perspectives).

We will now turn our attention to the second element, the Canonical Model.

The Canonical Model (business rules and format specification) describes how the extraction of business rules from the software portfolio are managed and shared among other applications.  In addition to externalizing business rules locked in proprietary applications (for example ERP or CRM) we also use design patterns defined here to communicate between different data formats. Instead of writing translators between each and every format (with potential for a combinatorial explosion), use this in combination with the CIM to write a translator between each format and the canonical format using rules to guide the effort. See the Open Applications Group Integration Specification (OAGIS) as example of an integration architecture that is based on a canonical data model. Implicit (and emerging now as generally accepted practice) is the use of rules (rules engines like iLOG for example) to handle reference data that must be shared across systems beyond software packages in our portfolio.  OAGIS uses XML as the common protocol for defining business messages and processes (scenarios) to enable business applications to communicate among one another in a standard manner. Not only the most complete set of XML business messages currently available (there are others several others, see the eXtensible Business Reporting Language (XBRL) for example), it also accommodates the specific industries by collaborating with vertical industry groups to add and extend additional requirements as needed. For another real working example in the Product Information Management (PIM) space see GS1 Global Data Synchronization Network and the standards that make this possible. 

Nick Malik over at Inside Architecture  has written an exceptional post about this. We may not agree on all aspects (mostly semantics) but I think he has summed up well what this set of models should address in the blueprint. His post addresses the essential elements a complete modeling effort would produce. These products would typically include:

Canonical Message Schema - describes how when passing messages from one application to another we pass a set of data between applications where both the sender and the receiver have a shared understanding of what the values are:
(a) data type,
(b) range of values, and
(c) semantic meaning. 

Event Driven Perspective (Views) - a style of architecture characterized by a set of relatively independent actors who communicate events amongst themselves in order to achieve a coordinated goal.  This can be done at the application level, the distributed system level, the enterprise level, and the inter-enterprise level (B2B and EDI).  Although we disagree on where this effort belongs (see Part IV of this series on reference architecture development), the logical view will have its origins here. 

Business Event Ontology
This ontology includes a list of business events, usually in a hierarchy, that represents the points in the overall business process where two or more objects (entities) need to communicate or share the same data values and intent (semantics).  And this, as Nick states is “is not the same as a process step. An event may trigger a process step, but the event itself is strictly speaking simply a “notification of something that has occurred,” not the name of the process.  Ontology development is a pretty exciting technology I have watched mature from simple lab exercises (toys really), to something far more useful. For more on this see Part II (The Common Information Model) or my post at Essential Analytics about the Protege ontology editor.

Business Rules
The last remaining modeling effort is the collection (identification and grouping) of the rules used to define the behavior of the elements we have already referred to. Typically buried in application code, (if you are not lucky enough to have a Business Rules engine <g>), this model describes the business rules, protocol, and default behavior expected when the model elements interact with each other (especially useful when exceptions occur or logical constraints are violated).  Not a common artifact I find, wish more of us would take the time and effort to accomplish this task.  For another real world reference see the  GDSN Package Measurement Rules (issue 1.9.2) for the global definition of nominal measurement attributes of product packaging or the GDSN Validation Rules.

As I stated in Part II, this is hard challenging work. The key differentiator and difference between success and failure on your MDM journey will be taking the time to model the blueprint and sharing this work early and often with the business. We will be discussing the third (and most important element) of the MDM blueprint, the Operating model in part IV. I encourage you to participate and share your experience, we can all learn from each other.