Modeling the MDM Blueprint – Part V

er_modelIn this series we have discussed developing the MDM blueprint by creating Common Information (part II), Canonical (part III), and Operating (part IV) models in our work streams. We have introduced the Operating Model into the mix to communicate how the solution will be adopted and used to realize the benefits we expect with the business in a meaningful way.  And hopefully set reasonable expectations with our business partners as to what this solution will look like when deployed.

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). 

41views1

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 somf_v_2_0service-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. somf_styles

– 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.

The Business Case for Enterprise Architecture

We have the frameworks. Plenty of them: Zachman, IEEE STD 610.12, FEAF (Federal Enterprise Architecture), and now an updated TOGAF (Open Group Architecture Framework) you can find more about at (http://www.opengroup.org/togaf).

We know what to do. All of us know what should be done and have a pretty good idea of how to do it. For example see what the GAO has institutionalized in their view of our profession in the publication labeled “A Practical Guide to CIO Council – Federal Enterprise Architecture. February 2001, Version 1.0 “.

Why do it?
Now comes the hard part. How about a business case for investing in this discipline? Expressed in terms ordinary business people can understand.  I have yet to find (I have looked) a really compelling piece of work that can express quickly what impact EA would have across five essential elements every business leader understands and manages to on a daily basis:

– cash flow
– margin (profitability)
– velocity
– growth
– customer (responsiveness, intimacy, and alignment)

I’m  guessing this is because we are all technicians at heart. I have also come to believe this is essential to having our peers in the business understand our value proposition. I remain convinced this discipline can (done properly) enable significant improvements in each of our organizations.  Any thoughts or suggestions are welcome, encourage all of us in this profession to evaluate and think carefully about what our real value is – as business people first, then as trusted advisors and partners to our business and IT colleagues alike.

Decentralized Enterprise Architecture: Can It Actually Work?

Interesting read over at Architecture & Governance Magazine (http://www.architectureandgovernance.com/) written by Raghavendra (Rao) Subbarao (Raghavendra.subbarao@gmail.com) as “Decentralized Enterprise Architecture: Can It Actually Work?”. Think there are some good points made here for the case for and against centralized versus de-centralized operating models. I have discovered through bitter experience that a Federated model probably works the best for a number of reasons, but this is usually not very comfortable for most corporate senior management to embrace. Use of balanced matrix organization is a little more complex than the classic command and control models most are familiar with. But it does put hands-on practitioners where they are needed the most (in the field solving for real problems) and enables the kind of business relationships and trust needed to ensure the sum of the parts is greater than the whole.  No one likes to live with Ivory Tower dictates no matter how compelling a case can be made for them. I think we all agree that collaboration among peers leads to widespread use and adoption. This is the magic. And the true difference between time consuming confrontations over who holds the power of decision or the energetic, creative empowerment of all contributors that really gets things done. There is much more to this, but the argument should be shifted to understanding how to make a Federated model work. The truth is the solution is not in selecting a centralized vs. decentralized model. It is neither.