By Christine Denney

Welcome to the third installment of the “Figure 8” series!   In last month’s post, we reviewed essentials 2-4 and discussed guidance for conducting the current state assessment and inventory.  With essentials 5-7, we move past the analysis (understanding the “what”) and into building the architecture (the “how”).

You might be wondering why self stick notes (a.k.a. “sticky notes”) are featured in the graphic and what they have to do with the essentials.  Mostly, I featured them because I have an unhealthy obsession with those gluey little darlings and their electronic siblings.  I have them everywhere and I love using them in the analysis and design phases because they are easily moved around or removed completely when an item is no longer relevant.  To me, they serve as a reminder that as we work through the essentials, we continue to experiment and adjust as new information arises.  Grab your self-adhesive notes and let’s explore the next three essentials!

Essential #5:  Figure out storage and sharing

Where, oh where, should our data be?  Since we already figured out “what” we want to manage and took an inventory of existing solutions, some key questions arise during this step.  If we already have the data stored somewhere electronically, is it accessible? (not just via one method, but a variety of methods?)  Is it on a platform that will be supported in the future?   Is the data stored in a single location (or will it be)?  Does it need to be?  In addition to all the questions swirling around, the terms hub, data store, replication, service, and virtualization may be on your mind at this point.  Since there are several articles that contrast the various types of hubs, I won’t delve deeper into that topic within this blog.

Another thing to determine is the scope of the master data store.  Defining the key, sharable attributes can help you clarify scope, determine estimates for sizing, and frame the security needs.  If the proposed solution spans multiple business areas, be clear on the boundaries of what the central store will include.  Some business areas may want to include attributes that are not applicable to the wider audience.  Consider implementing the business area-specific attributes within a local application.

A key principle for this essential is that a repository without an integration plan adds little value.  Don’t lock up your master data.  There may be occasions where governance, rather than technology, is the main factor in limiting access to the master data.  Understanding what the governing bodies will be willing to share with others can influence the direction for both the storage and access mechanisms.  Because the ability to access information impacts the value of our master data, making this information readily available rises to the top of our priority list.

Essential #6:  Figure out what you can solve

Looking realistically at what can be done is tough, but necessary.  Although the end goal may be to implement something company-wide, there may be barriers that require a smaller scale implementation to prove value more rapidly.  In a previous blog, I contrasted “little e” and “Big E” MDM.  Either one can add value to the business – it’s just a matter of scale.  Figure out which one your stakeholders will support.

The interview notes also play an important role in defining what you can solve.  A combination of a difficult pain point, engaged stakeholders, and a clear problem to solve are master data program nirvana.  (assuming that time, money, and resources are available, of course!)  Although a particular group may have been vocal about their needs during the interview process, that doesn’t guarantee support when money or resources are requested.

Essential #7:  Figure out what you need

MDM, like other complex programs, requires a wide breadth of skills.  Data expertise is at the heart, but both business process and technology experience are necessary for a successful implementation.  You may need to bring in outside consultants either for their guidance or to validate your proposed architecture.  If MDM is new territory for your organization, expect some skepticism and requests for external validation.

Although there are many promises made by tools in the MDM space, you need to consider whether they cover your use case and requirements for a variety of components, including:  infrastructure, governance, data sharing, meta data management, identity resolution, syndicated data, and data quality.

Recap

In essentials 5-7, we have moved from the assessment stage through the architecture and determined the “how” for managing the data.  With that, we wrap up the “what” and “how” phases of the essentials.  Stay tuned for the fourth and final installment of the series.

NOTE: Thoughts expressed in this article are those of the author and not her employer (or probably anyone else, for that matter).

Welcome to the second installment of the “Figure 8” series!  Yes, I know it has been a little while since we looked at essential #1.  In this blog, we look at essentials 2-4.  These build on the vision, or goal, which was discussed in the first essential.

Note that working through these essentials doesn’t imply a complete waterfall approach – you may go back and rethink decisions or rework deliverables as you progress through the essentials. Just be cognizant that if it feels like you are caught in a spiral of revisiting issues that were thought to be closed, you probably need to make sure the end goal is clear, and is first and foremost in the minds of the team.

One pet peeve that I want to address before diving into the next three essentials is the misconception that MDM is just a technology or an implementation method.  The first blog  in the series spoke to why that wasn’t correct, so I will just supplement with:

MDM <> ERP

MDM <> RDB

MDM <> Repository

MDM <> Ontology

MDM <> Data Integration

Clear enough?  Those techniques can be used as part of the  architecture and implementation, but they do not equal MDM.  Off soapbox, now on to the essentials.

Essential #2: Figure Out Who Cares

Essential two plays a key role in gaining sponsorship and establishing governance.  At this point, you are looking for people who are engaged and, in many cases, are impacted by issues that MDM can solve.  The primary goal here is to gain an understanding of the business processes, roles, and entities that are key to the success of the business.  Through surveys, interviews, and workshops, you gather the pain points and stories that will prove valuable for a business case.  Open ended questions or inquiries, that encourage discussion, provide the most information.  Asking the interviewees to describe their interactions with other groups results in more information than asking a yes/no question like “Do you interact with other groups?”

As you collect responses, start to look for synergies and common themes.  Are there certain groups that have similar issues or activities?

Essential #3:  Figure Out What “It” Is

As you learned about the processes and stakeholders, information about the key entities to be managed should have emerged.  The goal at this stage is to gain clarity on how each business group defines the entities.  Definitions do matter – is it department? division? something else?  Did all of the groups have the same understanding and definition?

As you dig into the entities, you start to get a feel for requirements, potential scope, and the probability of success in making changes.  (were the groups resistant or open to change?)  You may also gain a sense for how “good” the data needs to be in order to be considered high quality.

A number of artifact techniques are helpful for documenting and understanding the entities of interest.  These include, but are not limited to, data models, matrices, life-cycle maps, and process flows.

One thing that I’ve found helpful is an archetype matrix.  This is somewhat similar to what Bill Inmon describes for mapping out conformed dimensions in data warehousing.  Put the business areas or interview groups on the left, list the entities across the top, and then check off where an entity is relevant.  From this, you can cluster together similar themes.

Essential #4:  Figure Out What You Have

Now is the time (if you haven’t already) to take inventory of the resources that you have available.  As you are looking at what “it” is (essential 2), you may have looked at where “it” is documented and/or implemented.  You don’t want to model from a blank page if you already have existing, relevant models.

Another thing you want to highlight are the “pockets of brilliance” – places where things are going well.  Is there an existing governance group that could mentor others?  Are there existing solutions that you can leverage?  You might be able to reuse the architecture pattern even if the complete solution doesn’t fit the current case.

Depending on how difficult it is to find models, applications, databases, etc., you may find that this is a great time for a spin-off business case to create an inventory application (but that’s a blog for another day).

Recap

In essentials 2-4, we have moved from the vision stage through the assessment stage.  We have a goal in mind, data collected from business areas, definitions of the key entities, and an inventory of potential resources.  In the next installment, we’ll move from assessment to architecture components.

 To view the recording of this webinar, click HERE.

About the Presentation

World Vision is a Christian relief, development, and advocacy organization dedicated to working with children, families and communities to overcome poverty and injustice. World Vision recently built a global program management information system and created a data governance function to support managing competing requirements across an organization with a highly federated authority structure.

Its original vision for data governance was to move as quickly as possible to an enterprise program based on an initial business-case, strategy, and five-year roadmap. Severe budget cuts in 2008 forced the program to focus more narrowly on a single line of business, child sponsorship, but that accounts for more than 40% of World Vision’s work. The case study will explore how to shift focus to adding value quickly and embedding governance into business teams and governing data within a culture of federated authority.

About the Speaker

Mark is the Data Governance Manager for World Vision International. In this position he has created their data governance program from scratch with the administrative function of Data Governance Office, Working Groups, Governance Council and Executive Sponsor. Key deliverables have been providing data governance inputs to project teams designing and implementing global information management systems, communicating key data governance concepts and raising awareness of risks to the organization concerning data privacy and protection, and developing business rules and controls for Personally Identified (PII) data moving, stored and accessed in more than 95 countries.

Before his role in Data Governance, Mark was the Knowledge Management Team Leader, in World Vision’s International Programs Group heading a team in the development of a document management business process workflow solution for grants and matching funds (required for US Governance grants). Prior to World Vision, Mark spent two years as a Project Director for the US Chamber of Commerce, a year as the Director of Academic Affairs for Embassy of the United Arab Emirates (UAE), a Lead Research Analyst at Sterling Commerce and was the Assistant Executive Director of the Midwest Consortium for International Activities, Inc. (MUCIA).

Mark has a Ph.D. in Political Science from Ohio State University and a Bachelor of Arts in Political Science from Ohio Wesleyan University.

 To view just the slides from this presentation, click HERE.

About the Presentation

World Vision is a Christian relief, development, and advocacy organization dedicated to working with children, families and communities to overcome poverty and injustice. World Vision recently built a global program management information system and created a data governance function to support managing competing requirements across an organization with a highly federated authority structure.

Its original vision for data governance was to move as quickly as possible to an enterprise program based on an initial business-case, strategy, and five-year roadmap. Severe budget cuts in 2008 forced the program to focus more narrowly on a single line of business, child sponsorship, but that accounts for more than 40% of World Vision’s work. The case study will explore how to shift focus to adding value quickly and embedding governance into business teams and governing data within a culture of federated authority.

About the Speaker

Mark is the Data Governance Manager for World Vision International. In this position he has created their data governance program from scratch with the administrative function of Data Governance Office, Working Groups, Governance Council and Executive Sponsor. Key deliverables have been providing data governance inputs to project teams designing and implementing global information management systems, communicating key data governance concepts and raising awareness of risks to the organization concerning data privacy and protection, and developing business rules and controls for Personally Identified (PII) data moving, stored and accessed in more than 95 countries.

Before his role in Data Governance, Mark was the Knowledge Management Team Leader, in World Vision’s International Programs Group heading a team in the development of a document management business process workflow solution for grants and matching funds (required for US Governance grants). Prior to World Vision, Mark spent two years as a Project Director for the US Chamber of Commerce, a year as the Director of Academic Affairs for Embassy of the United Arab Emirates (UAE), a Lead Research Analyst at Sterling Commerce and was the Assistant Executive Director of the Midwest Consortium for International Activities, Inc. (MUCIA).

Mark has a Ph.D. in Political Science from Ohio State University and a Bachelor of Arts in Political Science from Ohio Wesleyan University.

About the Presentation

This presentation demonstrates how NoSQL technologies were used to solve a difficult analytical problem that traditional SQL databases could not. PDF malware has been on the rise for the past few years and has become one of the most successful methods for attackers to gain unauthorized access into a network. The standard way to do malware analysis in PDF documents has been very independent in nature. Commercial entities do not share their data so researchers must fend for themselves and more often than not, researchers analyze a PDF file independent of other malicious PDF files. I found this static approach to be highly inefficient, but storing multiple PDF documents in a database was a problem in itself. Traditional SQL databases didn’t seem like the right fit given their forced constraints and true relational models.

PDF files also contain a lot of dynamic data that make them a tough fit in a traditional SQL model. PDF A could contain 40 objects where as PDF B could contain 3,000 objects. Scaling this out becomes quite difficult and messy. When looking at this problem, I ideally wanted to solve a number of issues at once. I needed a good way to share a PDF samples, an easy way to query on a corpus of documents and the ability to efficiently get my data back out so I could display it elsewhere.

With all my samples in a JSON format, MongoDB just made sense as it could take in these objects and allow me to query on them as a whole or independently. MongoDB also provided me with a rich tool-set to further answer questions that had never been posed before. By using single and multi-step map/reduce jobs, I was able to aggregate PDF characteristics and apply simple averaging to identify shared commonalities between malicious documents.

Though I have had great outcomes and successes with MongoDB, there have also been annoyances and the unexplained details. These issues pinned me against a wall for days and sometimes had me wondering if I had picked the wrong model for tackling this problem. At the end of the day though I was able to overcome these issues and account for them without hassle.

This talk covers new research methods and tools created using NoSQL technologies to analyze PDF documents in a more efficient manner that promotes collaboration among the community. It also serves as a step forward in detecting malicious PDFs by looking at them from a statistical standpoint. When I look back on the choice to use MongoDB, I think I made a great decision. I can’t begin to think how I would have handled processing thousands of unique named function calls with multiple attributes for each PDF or running multi-step map/reduce jobs against a Mongo document instead of a blob in a SQL database. MongoDB provided me with a rich functionality that easily led me to success on my project.

In its current state, my PDF malware collection contains over 10,000 documents with over 100,000 objects. By using Map/Reduce, complex queries and a bit of math I am now able to compare uploaded PDF documents with the thousands of malicious files in my collection in less then 20 seconds. Using this tool and MongoDB, I have been able to accurately identify shared resources among malware that can help identify future variants that get introduced online.

I believe my approach is truly unique and I have yet to find anything else like it. Though it was unorthodox, it has produced a new way of sharing malicious PDF samples and identifying future attacks. Parts of my tool have been released open source allowing other users to build their own corpus of malicious PDF documents or perform their own research. Also, a web version of the tool currently exists in beta form where users can upload samples and have them compared among the malicious collection to identify suspicious components in their uploaded document.

About the Speaker

Brandon is a security researcher for 9b+ where he spends his time identifying malicious attacks and thinking of better ways to detect/stop them. His research on various security topics has gotten him attention from companies such as Adobe, Verizon, Sprint, and Cisco. He has discovered several exploits and flaws based on vulnerabilities found in commercial products, web applications and messaging technologies.

About the Presentation

Wordnik’s technical co-founder Tony Tam described the reason for going NoSQL. During his talk Tony discussed the selection criteria, testing + evaluation and successful, zero-downtime migration to MongoDB. Additionally details on Wordnik’s speed and stability was covered as well as how NoSQL technologies have changed the way Wordnik scales.

About the Speaker

Tony Tam

VP Engineering and Technical Co-Founder
Wordnik

Tony is a San Francisco Bay Area native. He received his undergraduate degree in Mechanical Engineering from UC Santa Barbara and his MBA from Santa Clara University. He was the founding engineer and SVP of Engineering at Think Passenger, the leading provider of customer collaboration software. Prior to joining Passenger, he was lead engineer at Composite Software of San Mateo, California. At Composite Software he helped developed the company’s first- and second-generation query processing engines and led the research and implementation of their cost-based federated query optimizer. Prior to that he led software development in the bioinformatics group at Galileo Labs, a drug-discovery company based in the Silicon Valley. Before Galileo Tony was a mechanical design engineer at Composite Optics and worked on spacecraft and satellite stable structures. He can be reached at tony@wordnik.com.

To view the recording of the webinar, click HERE.

One of my favorite songs from a musical has the line ”525,600 minutes; How do you measure, measure a year?” And how many songs have been written about the “measure of a man”? These are all catchy tunes, but after a recent remodeling experience, I was starting to question the “measure of a measure”. 

It sounds like a bizarre statement or a flashback to something related to 1990′s function points… measuring a measure? Even more bizarre was the reason that the thought kept running through my head. Normally, my personal and professional lives stay somewhat separate; however, the aforementioned remodeling caused these two worlds to collide in a way that I couldn’t have imagined.

In order to make amends with my remodeling company (guilt from making one too many change orders), I agreed to help out by ordering some of the materials myself. Little did I know that nothing I needed would be in stock at a local store and I would be at the mercy of websites.

 The mission: Order a tub.

The challenge: Maneuver a home improvement store’s web site and order the correct item – a 60×32 tub with right hand drain.

It sounds simple enough, right? It would have been, if the necessary metadata were in place.  

With specs in hand, I attacked the internet with gusto. After searching a home improvement store’s site for a while, I decided to use the site’s “compare” feature to narrow my choices. And that’s where it all went downhill. As I scanned the specs for each item, I could not believe my eyes. A 999 foot high shower wall? A 999 foot wide tub? Would this item really fit in anyone’s house? And why does a different field say it’s 60 inches wide? Why would somebody fill all of these fields with what seemed to be garbage data? Needing a rational answer (i.e. proof that the company didn’t have a master data management solution or data governance), I searched for information on the company.

After a few minutes, I found an article talking about how the company had reached its goal for product master data quality – a metric related to the percent completion of product metadata. Ready to wave a judgemental finger, I was all set to send some unsolicited advise to the company. Luckily, a little voice just wouldn’t let me push the send button. “What about YOUR measures?” Wow, what a reality check! 

I started to think about how we can select measures that make sense and truly assess progress toward the goal that we want to meet. If the goal was to provide a positive experience to the customer (ideally, a “compare” utility would have been a great way to entice customers), shouldn’t the measure of data quality be something that supports that goal? While measuring completeness can be a good thing, in this case, correctness was probably at least, if not more, important. It left me wondering if the chosen metric was a factor in the decision to fill fields with incorrect values.  

So I was left asking myself a few questions:

• Are my metrics aligned with my goal – the true goal- or are they just something I can easily calculate and show on a dashboard?
• Could my metrics encourage behaviour that would conflict with my goal?

Who knew that an experience in home improvement could have invaded my professional life and made such an impact? I guess that sometimes you get more than a nice room from a remodel!

NOTE: Thoughts expressed in this blog are those of the author and not her employer.

Master Data and its Management

The common master data elements that people think of in the context of master data are customer, supplier or product. Financial master data is equally important, is highly shared across the entire supply chain and is foundational for the operation of any enterprise.   The figure 1 below describes the scope and relationship of master data in any organization.

Figure 1 – Scope of Master Data Management

Master data management (MDM) comprises a set of processes and tools that consistently defines and manages the non-transactional data entities of an organization which may include reference data.

(Source: http://en.wikipedia.org/wiki/Master_data_management).

The foundation of MDM is a governance mechanism (workflows) by which data policies and definitions can be enforced on an enterprise scale. Tools and processes exist to facilitate the management of master data, and setting up an MDM system entails more than installing software and running a two year transition project. Successful master data management requires governance. It requires collaboration between IT and business to monitor, adjust, and improve data management.

Intel’s evolution with MDM

Over the past seven years Intel has been building out its master data management systems.  The finance subject area has had a central master data solution since 1990’s and the other core master data areas were engaged in the mid-2000’s.

The roadmap

It wasn’t until the company initiated an organizational realignment in 2003 that it came around to the idea that the integration and management of master data would be core to the success of the entire organization. The master data areas core to supporting Intel’s business were prioritized first for delivery.  The subject areas were customer, supplier, item, worker, location, and finance.

In 2004, the MDM program was created that included a program team, product owners and data architects. The mission of the central master data management team was to align and consolidate people, processes, and technologies. This was followed by the establishment of governance boards for each of the core master data areas in 2006. With one central team managing master data delivery across IT projects, there were efficiency improvements, better decision making and elimination of rework.

By 2007, the need to extend MDM to off the shelf products was realized as the master data management applications then in place did not meet the needs. The MDM teams started engaging with the members of vendor influence councils to drive the delivery of solutions that meet manufacturing business needs.

Implementations of mature MDM solutions were started in 2009 and today these applications are maturing at different rates. Some master data areas are more mature than others- and Intel is continuing to make refinements as the MDM solutions integrate with the ERP platform.

General Master Data Management Best practices

A shift in Thinking: From a reactive to a proactive approach

In the early stages of the process (pre 2004) the master data management teams were reactive to problems came up with the MDM applications. Through the years there has been a gradual shift in the approach – IT product owners have become proactive. Besides engaging with users to identify emerging requirements, they collaborate with the MDM applications product support groups to drive issue resolution with before the issue is brought to attention through IT service desk tickets by the business user. Today each business area has funded its MDM project separately, which means we there are multiple MDM capabilities. The goal state is to drive consolidation into a few key products.

Usage of Enterprise Architecture

An aspect of the Master data management architecture that has had industry focus is the usage of enterprise architecture practices to coordinate business, data, application, and technology domains and formalize the approach to solution design and delivery. Usage of enterprise architecture practices ensures agility in IT responding to business needs and a decrease the total cost of ownership of the MDM product.

Today Intel IT utilizes an enterprise architecture framework to implement solutions. Figure 2 shows a sample set of artifacts and roadmaps that combine the processes, data models, applications and technology domains to form the “Enterprise Model.” These artifacts drive solution architecture that addresses the complete needs of an MDM solution.

Figure 2- The Enterprise Model

The enterprise architecture artifact that has driven success in MDM has been the creation of data blueprints. Data blueprints address data design and business process design. Their creation involves subject matter experts and business experts from across IT and business units. The blueprints go through constant revision and improvement under the supervision of a change control board.

The governance board ensures that the structure, quality, and workflow of data meet the business needs. The board also drives the compliance of various downstream applications   and programs that are not in compliance, and guides them through the change management process.

Financial Master Data Management

Managing finance master data poses distinct challenges compared with other types of master data because accounting controls, regulations, and reporting standards change over time and organizations have to accommodate it in their processes and applications. Finance was one of the initial master data subject area where Intel implemented MDM. Finance master data management (FMDM) has a two fold scope: organizational master data and finance master data. Organization master data broadly refers to profit centers, or business units that generate revenue, cost centers, which are synonymous with departments, and other conceptual entities. Finance master data refers to different types of currencies, general ledger accounts, and the fiscal calendar. FMDM has come a long way at Intel the past 20 years.

• In 1990 there were no global standards and lack of a common fiscal calendar.
• In 1994, a single fiscal calendar for all of Intel’s business units and subsidiaries around the world though each subsidiary had a separate chart of account.
• During the years 1995 to 1998 Intel implemented ERP in seven areas of the supply chain and the business was introduced to concepts like profit centers, cost centers, and a centralized account maintenance process.
• Most of the supply chain processing was integrated into the ERP platform in 2003, which drove the consolidation of records of origin for key finance master data. In tandem with that, finance began using a home-grown application for workflow and life cycle management. For example, creating a general ledger account was managed as a workflow. The workflow process began with the request for a new account. The account councils would make sure it mapped properly to the global accounting standards, followed by an approval by the relevant business or operational unit. Attributes would be added on once an account was approved for creation.

IT Best Practices for Financial Master Data Management at Intel

• Governance is a major factor in maintaining data quality. Today cleansing is achieved through a central finance data maintenance group in lieu of an automated system. The central finance data maintenance group is responsible for adds changes, and in-activations to company code configuration, synchronization of the operations and business hierarchies, configuration of bank master data and electronic bank statements, currency code configuration and rate validation and security profile maintenance. They also conduct internal audits on data owners to determine who uses finance master data and who approved access to it. While a centralized maintenance group gives better control of data, the business process is not ideal because multiple business teams remain involved with approving maintenance decisions. This fragmentation is an issue if a data quality problem occurs that affects multiple teams. Governance in FMDM is still maturing.
• Life cycle management is another key concept. In addition to creation, maintenance, and updates, the FMDM team proactively manages deletions or in-activations. For example, if a cost center or department hasn’t been active for 12 months, and finance operations agrees to discontinue the usage, the cost center is inactivated instead of being deleted from the system. This enables reuse of the cost center in the future if required and need to keep it for auditing reasons. The need for an alerts capability to assess the downstream impact of a data management decision, such as inactivating a cost center is a need that is not met by the current application. .
• An intuitive and friendly user interface is important for business operations to use the MDM application
• Changes to accounting standards and regulations implies impacts to the business rules in an FMDM application.  Currently in the finance business unit is in an evaluation mode for moving from US GAAP (US General ly Accepted Accounting Principles) to IFRS (International financial reporting standards). In order to avoid re-work, the architecture for finance master data applications needs to be flexible to changing standards. Today the home-grown FMDM application can handle only a single chart of accounts. One of the challenges ahead will be to integrate flexibility such as adding multiple chart of accounts to the application or evaluate products in the market to meet such needs.

Conclusion

Successful master data management requires extensive collaboration between IT and the business units. It takes years for organizations to implement an enterprise wide MDM strategy so planning for it is key to success.

Several products exist in the market and due diligence of requirements is essential in selecting the correct MDM product and a building a thorough understanding of the product so that it can be integrated into the existing environment.

Tools and processes exist to facilitate the management of master data; however governance is the key to continuing success.

To learn more IT @ Intel, visit us at www.intel.com/IT.

ABOUT THE AUTHOR

Vanitha Srinivasan, Enterprise Architect, Intel

Vanitha Srinivasan is an enterprise architect in the IT group at Intel, the world’s largest semiconductor manufacturer and leading manufacturer of computer, networking & communications products. She specializes in data and applications. This article explores the ongoing evolution and implementation of master data management (MDM) procedures at Intel.

Exchanging information between government parties requires a consistent, reusable and repeatable approach to specifying data exchanges as structured electronic business documents built from components. At the Ministry of Justice in The Netherlands, hereafter referred to as “The MoJ,” a new approach is underway to construct XML Schemas from OWL Ontology Models.

The MoJ is challenged to handle the complexity of electronic message exchange. With ten central information systems on a government level, specialized information systems for the criminal chain, juvenile chain, immigration services and over twenty organizations communication is a big undertaking. As a principal member of the Central Information Systems of the Dutch government, the MoJ is pioneering new approaches to business documents and message design with an emphasis on semantic checking, model-based generation of schemas and reuse of business components.

A good understanding of which language is used within the organization is crucial to both human and machine-to-machine communication. Strong motivation for the use of ontologies arose from the failure of traditional approaches to deliver a reusable component-based solution.  Approaches based on Object Models and XML Schemas have lacked sufficient semantic consistency for transformation to message building blocks. A conceptual model in OWL can represent the richness of the language spoken and capture the knowledge within a certain domain. In the world of electronic message exchange, where XML documents often have un-named hierarchical structures, this richness is lost. However, by using schemas that are based on OWL models, the richness can be recovered by translating XML back to OWL. For electronic messages, it is important to reconcile the rich semantics of the OWL world with the representational needs of documents (messages) in the XML world.

The MoJ, in collaboration with TopQuadrant Inc., has undertaken a project to implement new approaches to electronic message design. Inspired by the U.S. National Information Exchange Model (NIEM) and the NASA Constellation Program’s approach to Data Architecture, the MoJ wanted to take full advantage of OWL to express different conceptual models and relate them to each other.

Law is a complex world in its one right. To express law enforcement in electronic messages is even more difficult. Through a “Projection, Qualification and Transformation (PQT)” method the conceptual world and implementation world of electronic messaging has been bridged.

This new solution replaced a previous system which focused only on message implementation, ignoring the conceptual world on which the messages were based. Issues with the old approach stemmed from the bad design and misunderstandings of concepts. Duplication of concepts occurred with entities having the same name but different meanings. To prevent this semantic chaos, the new solution uses OWL models.

To bridge the conceptual world and the implementation-driven world of electronic messaging, an additional standard is needed to provide a foundation. The United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) “Core Component Technical Specification (CCTS)” standard was chosen. CCTS describes an electronic message in logical terms. The project also used the UN/CEFACT Naming and Design Rules (NDR) for XML documents.

CCTS is a standard for defining technology-independent building blocks to support electronic messaging. CCTS supplies a clear separation between reusable templates, Core Components and business specific implementations of them. CCTS works with a selection paradigm in contrast to one of addition and restriction. Elements are defined only once. For instance the concept person has several attributes, such as: first name, last name, birthday, hobby, religion, address, driver’s license, and social security number. Not all these attributes are necessary to report a traffic violation.

The CCTS standard bridges between the conceptual and the implementation-oriented world of electronic message exchange. To take full advantage of this bridge, an approach to transform an OWL model into CCTS and CCTS into XML Schema has been developed. In this new approach, the W3C Standard OWL is used both for the representation of the conceptual models of legal domains, UN/CEFACT core components, business documents (data exchange definitions) and controlled vocabularies.

From “Rich” Ontologies to “Precise” Messages

Ontology models are “rich” in the sense that they capture precise semantics about subject areas of interest. Electronic messages are, by necessity, concise descriptions about situations and affairs. Take the example of a vehicle crash. The phenomena of the crash and relevant legal domains of policies and procedures can be thought of as “ontologies of” the world. These kinds of ontologies can include policies and procedures that dictate what an electronic message needs to say as opposed to how it says it. In the MoJ project, ‘ontologies of’’ a world are referred to as “rich ontologies” – rich in the sense that they dive deep into the nature of what makes up a domain of discourse or state of affairs. On the other hand ‘ontologies about’ a subject area are shallow – they are concerned with documenting or reporting some aspects of a state of affairs.

Using the crash example, we move from “of-hood” to “about-hood” of the crash. The “ontologies of” a crash specify those aspects of a crash that ground and contextualize articles of law and legal statutes and obligations that pertain to conducting a legal case.  The “ontologies about” the crash are specifications of how for the electronic messages needed to conduct the legal case.  The crash example is used in Figure 1.

Figure 1: From Richness to Conciseness – the Crash Example

Through projections, selected aspects of OWL conceptual models become UN/CEFACT CCTS building blocks. Qualification of the projections adds metadata for the transformations and the attributes that will be required in the CCTS models. The “Rich” Ontologies of legal domains and contexts of law are transformed using SPARQL Inferencing Rules Notation (SPIN) into CCTS-based Ontologies. Details of SPIN can be found at http://www.spinrdf.org.

Using the CCTS Ontology Models, Information Analysts tailor and compose components to specify the business documents that make up the electronic messages. An Adobe Flex-based User Interface is used to construct the message exchange schemas. Ontologies are queried and updated using TopQuadrant’s TopBraid Live SDK.

The final step is a transformation to XML Schemas. This is done by first generating XML SchemaPlus (XSP) from the OWL Models.  Developed by the NASA AMES Research Center, XSP is a specification language for XML Schemas that ensures sufficient semantics are retained from OWL models in the XML world, and that XML Naming and Design Rules are enforced.  XSP captures the necessary semantics of the OWL model for round-tripping XML documents back into OWL models.

Figure 2 shows an overview of the workflow of the Ontology-Based CCTS Approach.

Figure 2: The Netherlands Ministry of Justice Ontology-Based Approach to Designing Business Documents

As an example of the MoJ Metadata Workbench, the screenshot in Figure 3 shows how a business document is being constructed from components.  Other screen layouts deal with the need for qualified datatypes, codelists, metadata properties and annotations.

Figure 3: Constructing a Business Document in the MoJ Metadata Workbench

A screenshot of XSP Generation in the Metadata Workbench is shown in Figure 4.

Figure 4: Generating XML SchemaPlus from the Metadata Workbench

Ontology-Driven Approach to XML Message Schemas

For effective use, ontologies need to be organized. A key decision for the MoJ solution was to have an Ontology Architecture that isolates OWL models that are used for inferencing from those used for transformations. Figure 5 depicts the relationships between the named graphs that comprise the OWL models. Note that the figure refers to “OWL DL” and “OWL FULL”. At the time of the project OWL-2 was not yet a standard.  The current models are now compliant with the relevant OWL-2 profiles.

Figure 5: Ontology Architecture of the MoJ Metadata Workbench

Bridging the OWL 2.0 and CCTS Worlds.

To fulfill the needs of canonical data models, electronic business documents, and business intelligence, a conceptual, logical and physical model must be in place. Such a three layer approach is common practice for the design of Information systems, and for electronic messaging, this is no different. Before the MoJ implemented an ontology-based approach, the bridge between the conceptual models and the implementation models was a tedious and error-prone manual task. Figure 6 illustrates the three levels of models.

Figure 6: The Three Layers of Models Need for Electronic Message Design

Reuse of the concepts in the implementation world is essential. For the purpose of maintainability and understanding, a concept is defined only once. In the conceptual world it is important to know which concepts live in the domain, what their meaning and purpose is, and which relations hold between concepts.

The conceptual model, partitioned also in several layers, is based on OWL, the W3C standard that is used to describe concepts and their relationships. OWL is used in a practical way to bridge the semantic gap between organizations. Each organization is free to define its own model but compliance with standard definitions that are common across organizations is required. Awareness of the existence of alternative definitions and the explicit description of the differences is needed for semantic interoperability.

With the use of atomic building blocks and a supporting syntax, conceptual models will be designed to stand the test of time. OWL brings flexibility and consistency where it is needed. Projections are needed because not all the information described in the conceptual world is needed in an electronic message. With simple transformation rules and annotations, the conceptual OWL model is transformed into a CCTS compliant model.

Within the conceptual world, an Ontologist is free to decide how to model the OWL ontology. However, the Ontologist must be aware of the implementation-driven world as well to make good design decisions. Clean and simple transformation rules are in place to guide the Ontologist, and the need for awareness of the CCTS model has been kept to a minimum. In most cases, existing OWL ontologies can be incorporated directly without the need to refactor them.  An important prerequisite is that the OWL ontology is in its canonical form before transformation to CCTS takes place.

Conceptual models are modular, maintainable and under version control. Several models can be combined together to form a base-lined Ontology. The base-lined ontology forms the input for the creation process of a CCTS ontology.

A conceptual model in OWL does not express implementation considerations.  In terms of modeling styles, the main difference between OWL and CCTS can be seen as similar to comparing object-oriented versus component-oriented software engineering. OWL has constructs for inheritance. In
CCTS this becomes composition of parent properties directly in the child.
CCTS is implementation-driven and reflects XML Schema in many ways. CCTS specifies business documents through the composition of reusable generic components.  From a template called a “Core Component,” an implementation building block, called a “Business Information Entity” is derived.

One of the strengths of OWL is the usage of namespaces. Each concept is uniquely identified by its namespace and local name. For clearer understanding, prefixes are used to distinguish namespaces.  Taking advantage of this strength is an aspect of our solution that does not change or violate the CCTS Standard. Naming and Design rules give flexibility over the usage of different namespaces. Considering the fact that many synonyms exists, namespaces are an essential architectural principle in the solution.

To bridge the gap between OWL and CCTS, a meta-model of CCTS was specified in OWL. The meta-model is implemented according to the Core Component Technical Specification CCTS V2.01 standard. For XML transformation the naming and design rules of the UN/CEFACT Naming and Design Rules are used. Essential enhancements are made to fit the specific needs of the Ministry of Justice. Naming and Design rules (NDR) are also important to the form of a structured XML Schema.

The metamodel supports reasoning over electronic messages. The CCTS model is realized as both DL-compliant and OWL FULL models. The OWL FULL part is needed to hold additional information important for the XML Schema generation process.

With the three layer approach, the MoJ has bridged conceptual OWL Models and implementation-level XML electronic message schema design. CCTS provided the standard to define business documents and OWL fulfilled the need for more expressive power than XML.

Looking to the Future

From the business perspective, the MoJ benefits are higher quality of messages and easier support for evolution and extensibility of the electronic messages. Reuse of concepts is guaranteed by the automated transformation from OWL to CCTS.

Looking to the future, when XML instances are available, translation to OWL enables the power of reasoning to be available. We envision applications that can infer new information, perform “smart” queries and generate comprehensive reports. Through workflow controls, sophisticated content-based routing of electronic messages becomes possible. These are the next steps that the MoJ will be considering.

In addition to developing web based user interfaces, we also extended the TopBraid Composer desktop modeling tool with plug-ins to support the creation of Core Components and Business Information Entities. TopBraid Composer is based on the open source Eclipse Integrated Development Environment, making it open to extensions and customizations..

References

1. CCTS, “Core Component Technical Specification”, UN/CEFACT,http://www.unece.org/cefact/codesfortrade/CCTS_index.htm
2. NIEM, “National Information Exchange Model”, http://www.niem.gov/
3. SPIN, “SPARQL Inferencing Notation”, http://www.spinrdf.org
4. TopBraid Live, http://www.topquadrant.com/products/TB_Live.html
5. XSP, “XML SchemaPlus”, http://www.xspl.us

In Part 1, Six Sigma and MDM, published earlier in Enterprise Data Journal, I discussed applying Six Sigma methodology and principles to Master Data Management (MDM) programs. Although we can never expect to achieve Six Sigma perfection in our master data we can still benefit from using the rigorous methodology and many of the tools like metrics, SIPOC and fishbone cause/effect diagrams to make our MDM projects successful.

In this Part 2, Framework for Integrating MDM into Enterprise Architecture (EA), I will examine a framework for MDM that includes architecture, process and governance tasks. As part of this framework I build a case for integrating MDM into your overall Enterprise Architecture. This article goes on to examine the processes of implementing MDM and concludes with some concrete suggestions for implementing master data governance.

Figure 1 shows the minimum required components and services of MDM.  These were analyzed in Part 1 but these critical MDM components are worth repeating.

The second layer, Unique ID Service, Attribute Management of Facts, Hierarchy Management and Data Quality Service are all implemented in the Master Data Registry. The MDM Registry gives the business the flexibility of comparing, cleansing and de-duplicating different sources of master records as the business becomes ready to deal with downstream issues. As multiple sources are merged the registry becomes the new hub for those downstream systems.

Governance: Master Data Governance is the authority that decides how master data is maintained, what it contains, how long it is kept and how changes are authorized and audited.

Consistent Unique ID Service: Each MDM system assigns a common Master ID that is mapped to every source master record. This cross-reference is maintained in the Master Data Registry.

Attribute Management of Factual Master Data: The consolidated master contains factual information that is common across all sources in the enterprise, including data values, relationships and hierarchies.

Hierarchy Management: MDM includes the capability to manage hierarchies or structures of master data; for example customers and their sub-units and sites and products and their component BOM’s.

Data Quality Service: MDM includes the capability of measuring and improving the quality of master data specified by the data stewards and owners.

Master Data Registry: The MDM Registry is where the Common Master ID is assigned and maintained. The registry should have the capability to compare, merge & de-duplicate master records in order to normalize redundant data records.

Data Stewardship: Stewards are appointed by the owners of each master data source; they have knowledge of the current source data and the ability to recommend how to transform the source into the master data format.

Business Rules: Master Data Stewards establish common business rules for updating and maintaining master data in each domain.

Data Management Workflow: Master Data Stewards define a Workflow for creating and updating their master data according to the Business Rules for that domain.

Process Integration Services: Master data for each domain is integrated into the business processes of each business unit using a common workflow subscription.

Master Data Integration Services: Each Master Data domain exposes common data integration services for creating, updating and synchronizing master data for that domain with other operational and analytic systems.

Framework for Integrating MDM into EA

Integrating Master Data Management into an overall Enterprise Architecture consists of work in three broad areas:

1.) Architecture
2.) Process
3.) Governance

Although many of the tasks in each of these areas are often interrelated you could begin planning your MDM program using these three parallel threads.

Architecture

MDM has implications for your Enterprise Architecture because your MDM data models should be incorporated into your Enterprise data model.

First we position the MDM data architecture into the overall Enterprise Architecture.

Figure 2 shows how high level domain models should be integrated into the EA CRUD matrix.

While the typical EA data models may be at the conceptual (entity only) level it makes sense to take your MDM domain data models down to the logical level, showing business attributes and definitions. Master data is so central to the business that showing fully attributed data models and their definitions will help implementation and adoption.

Figure 3 shows a logical view of Customer based on Oracle’s Trading Community Architecture (TCA) and the Party entity.

Next, take the high level MDM data and process models and fit them into the appropriate places in the EA data and service function models. Your EA data, application and process models should reflect the same high level conceptual structures as your MDM models. Likewise, your MDM models should take advantage of your EA models to help with scope and integration project planning.

As you drill further down in your data and application models you should designate which systems will maintain your Master data and which systems will be slaves.

Process

Your MDM program should be a set of repeatable processes that can be reused for subsequent domains. In other words if you start with the Customer domain you should design repeatable MDM project tasks that can be reapplied to remaining domains like Product and Vendor/Supplier. The archetypical MDM processes are:

1. Develop plans to create Data Hubs for all master data domains within scope such as Customer, Product, Vendor/Supplier. If you are doing multiple domains at the same time each domain will have its own project plan.

2. Leverage Master Data Hubs for maintaining and propagating consistent identifiers and clean master attributes across operational and analytic applications.

3. Implement Business Process Management and workflow to ensure data integrity between operational systems <=> Master Data Hubs <=> Analytic application.

4. Leverage Data Quality metrics to ensure the effectiveness and continuous improvement of the MDM process.

Governance

The first step in MDM governance is to assess the current master domain control organizations. Look into the business organization and identify the business processes that create new master data records in the current environment. For example, the Accounts Receivables department probably creates new customer records after receiving a request from sales & marketing. They may have a defined work flow that involves routing the request to the Legal Dept before they create new Customers. This entire work flow needs to be documented. If there are multiple points where master records can be created, the appropriate business organizations must be brought together to create a new shared business process.

Once the new business process has been defined data governance must be established to manage the discovery and removal of duplicate master records. The Data Stewards on the Governance Board will define appropriate Data Quality metrics that can be automated by the MDM DQ service. Finally, the Governance Board must establish an escalation procedure for resolving conflicts when they occur.

Figure 4 shows a typical Data Governance organization structure.

It should be obvious that separate Data Governance organizations need to be setup for each MDM domain; one for Customer, another for Product, etc. This is because the business processes for each MDM domain are very different. The AR department doesn’t need to work on Product MDM de-duplication rules; likewise, the Product Configuration Management business people don’t need to participate in discussions around merging Customer master records.

Duplicate governance organizations need to be setup for each domain because the business personnel at the Strategic, Tactical and Operations level will be different in Customer Data Governance than the business people in Product Data Governance. However, the IT Technology Team should be shared across multiple data governance organizations to leverage MDM technical expertise and promote consistent MDM practice.

Conclusions for Applying Six Sigma Principles to MDM

Integrating Master Data Management into Enterprise Architecture helps to institutionalize your MDM program. If you already have an established Enterprise Architecture group it should be relatively straightforward to adopt this integration approach. If you don’t have an EA group this is your change to jump start your effort to build EA.

While Master Data may never approach Six Sigma quality due to our inherent tolerance for error, we can still benefit from using Six Sigma methodologies and tools to manage our MDM projects and programs. Data Governance establishes and enforces the data quality thresholds that are necessary to manage data as a strategic asset.

References

Callaos, N. & Callaos B. (2002).Toward a Systemic Notion of Information: Practical Consequences. Informing Science. Vol 5, No 1

LeBlanc, Andrew. (2008). Enterprise Data Management with SAP NetWeaver MDM. Boston, MA: SAP Press [ISBN 978-1-59229-115-1]

Oracle Trading Community Architecture. User Guide Release 11i Part No. B12310-02 August, 2004.

ABOUT THE AUTHOR

Joe Danielewicz

Joe Danielewicz spent 28 years at various business units of Motorola in IT data architecture and enterprise architecture. Mr. Danielewicz is now an independent consultant in Enterprise Architecture and ERP Integration Planning.