February 19, 2011

What is Master Data Management (MDM)?

*and why do I care?

By Denise Jeffries, CCP, CBIP, CDMP

submission for March 4, 2011

In the IT fields we have lots of acronyms, heck we don’t even say Information Technology anymore, it’s just IT. So it’s no surprise that Master Data Management is just MDM. Ask 10 people what MDM is and I’ll bet we get 20 difference answers, because everyone has more than one definition for it.

Gartner says “MDM effectively supports your organization’s post-recession growth strategy, operational efficiencies, customer service, compliance and risk management.” (1) I am not making this up, check out the link. Now I don’t know about you, but I sure don’t know what that means.

Microsoft has a better take when it states MDM is “lists of data that are shared and used by several of the applications that make up the system” and goes on to state “This master data is often one of the key assets of a company. It’s not unusual for a company to be acquired primarily for access to its Customer Master data.” (2) While I feel a bit better, I now see master data is shared data and can be a key asset. But, I’m not so sure about someone buying an entire company just for its data…. Think of everything else it’s throwing away if the purchase is only for lists of data….what about the intelligence behind using that data, or how it was compiled….

Our beloved (or hated – depends on your view) Wikipedia site states “In computing, 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). MDM has the objective of providing processes for collecting, aggregating, matching, consolidating, quality-assuring, persisting and distributing such data throughout an organization to ensure consistency and control in the ongoing maintenance and application use of this information.” (3) It goes on to say “The term recalls the concept of a master file from an earlier computing era. MDM is similar to, and some would say the same as, virtual or federated database management.” Now everyone under the age of 40 is confused again. Go back and read it through it and you find it has some good points (although I believe transactional data applies in today’s world, but that’s another topic).

We used to talk about data standards, meta data management, reference data, lookup data and data quality (this list can go on) — and how its needed to have information about your data before you can use your data for any type of real business intelligence solution. Now we say you have to have Master Data Management. MDM is the whole enchilada solution for data control and use for the enterprise.

What exactly is MDM you say? Let’s break it down by Merriman-Webster’s definitions (4) of the words:

Master “one having authority over another”

Data “factual information (as measurements or statistics) used as a basis for reasoning, discussion, or calculation”

Management “the act or art of managing: the conducting or supervising of something” Manage: “to handle or direct with a degree of skill”

Authoritive measurements for reasoning with a degree of skill. I kind of like that blurb… I’m going to use something with authority to give me something I can measure and it will be reasoned with skill. Sounds like a good way to get data to me.

With that little bit of background, let’s address our topic. Master data is the information needed in a common format for core business to be carried out. So we need to determine where to start. What areas are the most important in any company? Usually Customers and Products are the normal two common focus areas. So you need to start collecting information about your Customers and about your Products.

You’ll need this information for Sales, Marketing, Customer Service, etc. Now, you could have completely separate databases for Sales, Marketing and Customer Service, but you have the same Customers and Products and you want them to be consistent across all three systems. That’s where MDM comes in, you maintain your base ‘lists’ for Customers and Products and then share it with the 3 systems for Sales, Marketing and Customer Service (and Finance and Audit…) you get it….a lot of areas need the same information and you want it to be available for everyone and for it to be accurate and easy to maintain.

Why maintain the same data in all the different systems? Maintain it in one place and deliver it to the various systems from this central place. That’s what MDM is all about. Now don’t get me wrong, there are processes, tools, best practices, quality measures, standards, all kinds of IT ‘stuff’ around it and how you do it, but simply put – MDM is the practice of centrally taking care your data.

So now we have a basic understanding of what MDM is and how you might want to apply it. Hopefully this is of some help, who knows maybe one day you’ll work on an MDM project, or a project that could use MDM practices. You could be the one to help your company save money, talent and time by focusing on one central area to collect your data and ensure its accuracy and consistency.

February 3, 2011

TOGAF – The Open Group Architecture Framework

What is TOGAF?

TOGAF is an enterprise architecture framework. This framework provides a detailed approach to designing, planning, implementing and governing an enterprise information architecture. (2) Ok, so what does that really mean? Maybe we should start with – “What is an architecture framework?” The Open Group describes an “architecture framework” in the following way:

“An architecture framework is a tool which can be used for developing a broad range of different architectures. It should describe a method for designing an information system in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks.” (1)

So basically what I get from this is: an architecture framework is a structured model to facilitate enterprises with setting up their different architectures that are catered to their needs. It’s a blueprint. When I started my research the first thing that came to mind was the Zachman Framework (ZF), which we have discussed in class. During my research, I have found that the Zachman Framework has been the “industry standard”. With this being said, I have found that many have compared TOGAF to Zachman. One self-proclaimed enterprise architecture expert states, “Zachman not only demonstrates the concept, he implements it, and as a result, obscures the right of others to implement the same concept in a different way.”(3) He goes on to say, “The Zachman Framework can easily be viewed as one implementation within TOGAF.”

What architectures does TOGAF address?

So we keep throwing around this word “architecture”. What architectures are we talking about? There are four subsets of enterprise architecture that are commonly used. These are the architectures that TOGAF and many other frameworks address. The four subsets are: Business Architecture, Data Architecture, Application Architecture, and Technology Architecture.

Business Architecture

The Business Architecture subset defines the business strategy, governance, organization, and key business processes of the organization. (1)

Data Architecture

The Data Architecture describes the structure of an organization’s data assets and data management resources. (1)

Application Architecture

The Application Architecture provides a blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organization. (1)

Technology Architecture

The Technology Architecture describes the software and hardware capabilities that are required to support the other subsets, which includes applications critical to the enterprise. This includes IT infrastructure, middleware, networks, communications, processing standards, and etc. (1)(2)

What does TOGAF consist of?

TOGAF consists of the following three main parts:

TOGAF Architecture Development Method (ADM)

According to The Open Group, the key to TOGAF is the ADM (Architecture Development Method). The ADM is a proven method for developing IT enterprise architecture that meets the specific business needs of the adopter. It explains exactly how to develop custom requirement-centric enterprise architecture.

The Enterprise Continuum

The Enterprise Continuum is a repository of models, patterns, and architecture descriptions that exist in the IT industry. TOGAF includes two reference models for the architects consideration. The TOGAF Foundation Architecture and the Intergrated Information Infrastructure Reference Model (III-RM). The TOGAF Foundation Architecture is an architecture of generic services and functions that will provide an enterprise with a foundation. The III-RM is specifically geared toward enabling organization to implement Boudaryless Information Flow. The III-RM is based on the TOGAF Foundation Architecture.

The TOGAF Resource Base

The TOGAF Resource Base is set of guidelines and templates to assist an organization in the use of the ADM.

In conclusion, TOGAF is an architecture framework that allows an organization to design, evaluate, and build the right requirements-centric architecture for their organization. Typically an organization implements systems and architectures to answer some business need or concern. Because TOGAF is developed by The Open Group, a not-for-profit consortium, this is an cost-effective way to help build the systems/architectures that can answer those business needs.

February 3, 2011

We are all gathered here today to take an in-depth look at SWOT analysis. For those of you who may be unfamiliar with the acronym, it stands for Strength, Weaknesses, Opportunities and Threats.

Albert S. Humphrey is considered the father of SOFT analysis, which was used in a research project he led at Stanford University in the 1960s and 1970s. “Humphrey and the original research team used the categories, “What is good in the present is Satisfactory, good in the future is an Opportunity; bad in the present is a Fault and bad in the future is a Threat” (SOFT).” (3) I know you are wondering … what in the world does the history of SOFT have to do with SWOT? I am so glad you asked. In 1964, the “F” was changed to “W”; the lettering was rearranged and thus SOFT became SWOT.

For clarification, allow me to provide a somewhat technical definition of the technique — “SWOT Analysis is a strategic planning technique used to assess the internal and external environment in which a company operates and competes.” (1) In short, a SWOT Analysis is a technique companies use to help them sift through all the data relating to their business operations (internal factors) and their competitors (external factors) and categorize them into strengths, weaknesses, opportunities and threats. “The SWOT analysis provides information that is helpful in matching the firm’s resources and capabilities to the competitive environment in which it operates.” (2)

The Rapid Business Improvement site offered a very help chart and some basic “how to” steps for performing a SWOT analysis:

Overview Matrix:

POSITIVE/ HELPFUL

to achieving the goal

NEGATIVE/ HARMFUL

to achieving the goal

INTERNALOrigin

facts/ factors of the organization

Strengths

Things that are good now, maintain them, build on them and use as leverage

Weaknesses

Things that are bad now, remedy, change or stop them.

EXTERNAL Origin

facts/ factors of the environment in which the organization operates

Opportunities

Things that are good for the future, prioritize them, capture them, build on them and optimize

Threats

Things that are bad for the future, put in plans to manage them or counter them

How to do a SWOT:

Irrespective of whether you or your team are future planning for specific products, work, personal or any other area, the SWOT analysis process is the same.

Step 1 – Information collection (in the here and now)
List all strengths and weaknesses that exist now. Be realistic but avoid modesty!

You can conduct one-on-one interviews or get a group together to brainstorm — A bit of both is frequently best.

You should begin by preparing questions that relate to the specific company or product you are analyzing.

When facilitating a SWOT – search for insight through intelligent questioning and probing

Step 2 – What might be…
List all opportunities and threats that exist in the future. Opportunities are potential future strengths while threats are potential future weaknesses.

Step 3 – Plan of action…
Review your SWOT matrix with a view to creating an action plan to address each of the four areas.

SWOT analysis can be very useful to help business better facilitate their strategic planning and get a clear idea of the appropriate path to chart for their business. According to Mind Tools (4), some key points to remember are:

· SWOT Analysis is a simple but useful framework for analyzing your organization’s strengths and weaknesses, and the opportunities and threats that you face.

· It helps you focus on your strengths, minimize threats, and take the greatest possible advantage of opportunities available to you.

· SWOT Analysis can be used to "kick off" strategy formulation, or in a more sophisticated way as a serious strategy tool.

· You can also use it to get an understanding of your competitors, which can give you the insights you need to construct a coherent and successful competitive position.

Mind Tool also recommends you be realistic and rigorous when carrying out your SWOT Analysis. (4) “Apply it at the right level, and supplement it with other option-generation tools where appropriate.” (4)

February 3, 2011

We are all familiar with the old saying “if it ain’t broke don’t fix it”. If asked the question, Should businesses change their processes even though their current processes are working, what would you say? Probably no, but, Michael Hammer and James Champy say yes. In their book “Reengineering the Corporation” they take a deep look at how reengineering processes can help a suffering business improve and thriving businesses continue to thrive. The book defines “reengineering” as the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical contemporary measures of performance such; as cost, quality, service and speed (1). They don’t believe a business should simply make incremental improvements to the existing way of doing business but believe they should make a fresh start using a clean sheet of paper to create new ways of doing business. Who are the people that identified the process of business reengineering? What are the principles behind this concept and is this concept embraced?

Who are the authors?

Michael Hammer was born in Annapolis, Maryland in 1948. He earned a bachelors degree in Math in 1968, a masters degree in electrical engineering in 1970 and a doctorate in computer science in 1973. He taught Computer Science at MIT and later became a management consultant which kick-started his thinking and research on this book (1). He wrote three other books and multiple articles related to the topic of business reengineering. Michael Hammer died September 2008 at the age of 60 from a brain hemorrhage. James Champy is the former chairman of Dell Services, a consulting practice. He was responsible for providing direction and guidance to the company’s team of business and management consultants. James Champy was also chairman and chief executive officer of CSC Index, a $200 million dollar consulting practice. He earned a bachelors and masters degree in civil engineering from MIT and a Juris Doctorate from Boston College of Law (2).

What is business process reengineering really?

The main idea of business process reengineering is simply to start over. The can no longer stick with the old way of doing business. The key rhetorical question of reengineering is (5):

‘‘If I were re-creating this company today, given what I know

and the current level of technology, what would it look like?’’

What are the principles of business reengineering?

Reengineering the Corporation challenges the traditional assumptions of the division of labor. Gone are the days when a business could prosper using the work style created by Adam Smith in “Wealth of a Nation, 1776”. In which, companies like Ford and General Motors adopted the assembly line approach. This approach was effective in those times but in today’s environment would result in; high overhead costs, delays and errors and rigidity (5). The basic questions a business must ask are; does our mission need to be redefined? Are our strategic goals aligned with our mission? Who are our customers? There is no step by step guide about how to do business reengineering. However there are recurring themes that most processes align with (4):

Several jobs are combined. The assembly line approach is rejected

Decision making falls to the works not the managers

Process steps are performed logically not and naturally

No standardization – processes can have multiple versions of the same product

The work is performed where it makes most sense.

Checks and controls are reduced or eliminated

Hand offs and reconciliations are minimized

Reengineering the Corporation was on the New York Times Best Sellers list for 41 weeks in a row (1). It was pinned as the most successful business book of the decade. Many businesses embraced this concept and began reengineering projects and succeeded. However reengineering earned a bad reputation because such projects have led to massive layoffs. Although there are many success stories it does not always live up to expectation. The main reasons are (6):

Reengineering assumes that the factor that limits an organization’s performance is the ineffectiveness of its processes.

Reengineering assumes the need to start the process of performance improvement with a “clean slate,” i.e. totally disregard the status quo

In conclusion, “Reengineering the Corporation” changed the way businesses looked at process change. In order to stay competitive business must find ways to reinvent themselves to keep customers happy. This includes ditching the ways of the past and embrace new initiatives. Michael Hammer and James Champy give countless examples in the book that all businesses can identify with. Although there is no specific way to construct business process reengineering there is clear evidence that when a business does take on this project positive results follow.

February 3, 2011

In 1987, J.A. Zachman contributed an article to the IBM Systems Journal titled “A Framework For Informations Systems Architecture”. In this article, Zachman described his method for managing the complexity of increasingly distributed informations systems. Zachman’s vision was that business value and agility could best be realized by a holistic approach to systems architecture that explicitly looked at every important issue from every important perspective. (1)

The Zachman Framework summarizes the architecture of an enterprise from the perspective of the stakeholders. Zachman is represented in a two dimensional matrix in which the rows reflect the perspectives of six major stakeholders in the enterprise and the columns represent the six contextual dimensions.

The Framework is structured around the views of different users involved in planning, designing, building and maintaining an enterprise’s Information Systems:

Scope (Planner’s Perspective): The planner is concerned with the strategic aspects of the organization, thus addressing the context of its environment and scope.

Enterprise Model (Owner’s Perspective): The owner is interested in the business perspective of the organization, how it delivers and how it will be used.

System Model (Designer’s Perspective): The designer is concerned with the systems of the organization to ensure that they will, in fact, fulfill the owner’s expectations.

Technology Model (Builder’s Perspective): The builder is concerned with the technology used to support the systems and the business in the organization.

Detailed Representations (Subcontractor’s Perspective): This perspective addresses the builder’s specifications of system components to be subcontracted to third parties. (3)

While the rows describe the organization users’ views, the columns allow focusing on each dimension:

Data (What?): Each of the cells in this column addresses the information of the organization. Each of the above perspectives should have an understanding of enterprise’s data and how it is used.

Function (How?): The cells in the function column describe the process of translating the mission of the organization into the business and into successively more detailed definitions of its operations.

Network (Where?): This column is concerned with the geographical distribution of the organization’s activities and artifacts, and how they relate with each perspective of the organization.

People (Who?): This column describes who is related with each artifact of the organization, namely Business processes, information and IT. At higher level cells, the "who" refers to organizational units, whereas in lower cells it refers to system users and usernames.

Time (When?): This column describes how each artifact of the organizations relates to a timeline, in each perspective.

Motivation (Why?): This column is concerned with the translation of goals in each row into actions and objectives in lower rows. (3)

Weaknesses of the Zachman Framework:

It can lead to a documentation-heavy approach. There are 36 cells each of which could be supported by one or more models.

It can lead to a process-heavy approach to development.

It isn’t well accepted within the development community and few developers even seem to have even heard about it.

It seems to promote a top-down approach to development. When people first read about the ZF, they tend to think that it implies a top-down approach where you start with the models in row 1, then work on row 2 models, and so on. This doesn’t have to be the case, you can in fact start in any cell and then iterate from there.

It appears to be biased towards traditional, data-centric techniques (thus explaining its popularity within the data community). (4)

Strengths of the Zachman Framework:

The Zachman Framework is well accepted within the data community as the standard for enterprise architecture.

The Zachman Framework defines the perspectives that an enterprise model should encompass, the implication being that you can apply its guidance within a process such as the Enterprise Unified Process.

The Zachman Framework explicitly communicates that enterprise modeling has several stakeholders, not just enterprise architects and developers, whom you should involve in your modeling efforts. (4)

The Zachman Framework can be used analyze anything relative to its architectural composition. Zachman stated, “It doesn’t know what it is being used to analyze. Only the analyst knows the analytical target and establishes the boundaries of the analysis.” (2)

February 2, 2011

Twenty years ago, a new field Enterprise architecture was born. The field initially began to address two problems:

System complexity—Organizations were spending more and more money building IT systems; and

Poor business alignment—Organizations were finding it more and more difficult to keep those increasingly expensive IT systems aligned with business need. (5)

Enterprise Architecture is a comprehensive framework used to manage and align an organization’s Information Technology (IT) assets, people, operations, and projects with its operational characteristics. In other words, the Enterprise architecture defines how information and technology will support the business operations and provide benefit for the business. (6)

The Enterprise architecture is a corporate asset that should be managed as a formal program.

Enterprise architecture should be a key support element of the operations of the corporate, and should assist the operations function in performance of its customer-focused mission. Successful execution of the enterprise architecting is not simply an IT task, but needs the total enterprise participation including management, allocation of resources, continuity, and coordination. Effective enterprise architecting needs internal and external communication and sharing of lessons learned.

Obtaining the needed support from executives is not easy. Creating an Enterprise architecture program calls for sustained leadership and strong commitment. This degree of sponsorship and commitment needs the leadership by the CIO, and early designation of a Chief Architect. (4)

Layers of the Enterprise Architecture (2)

Business processes and activities

Applications such as custom or off-the-shelf software tools

Data that must be collected, organized, safeguarded, and distributed

Technology such as computer systems and telephone networks

Legislation

The Clinger-Cohen Act holds each Agency CIO responsible for developing, maintaining, and facilitating the implementation of an information technical architecture. (4)

Frameworks:

Many enterprise-architectural methodologies have come and gone in the last 20 years. At this point, perhaps 90 percent of the field use one of these four methodologies:

The Zachman Framework for Enterprise Architectures: Developed by Zachman

The Open Group Architectural Framework (TOGAF): Developed by The Open group

The Federal Enterprise Architecture : Developed by CIO Council

The Gartner Methodology: Developed by Gartner

When examining each of these methodologies in depth, one is struck by the fact that none of these approaches is really complete. Each has strengths in some areas and weaknesses in others.

For many enterprises, none of these methodologies will therefore be a complete solution. Such organizations might choose bits and pieces from each of these methodologies, and modify and merge them according to the specific needs of your organization. (5)

Four best practices to get Enterprise Architecture on track (3)

· Focus intensely on clearly defined goals.

· Base Enterprise architecture goals on what matters to the business now.

Enterprise architecture, when done correctly, provides a systematic assessment and description of how the business function operates at the current time; it provides a “blueprint” of how it should operate in the future, and, it provides a roadmap for getting to the target state. (1)

Some of the predicted benefits from a successfully implemented enterprise architectural include: (5)

Improvements in using IT to drive business adaptability.

Closer partnership between business and IT groups.

Improved focus on organizational goals.

Improved morale, as more individuals see a direct correlation between their work and the organization’s success.

Reduced numbers of failed IT systems.

Reduced complexity of existing IT systems.

Improved agility of new IT systems.

Closer alignment between IT deliverables and business requirements.

Without Enterprise architecture, the following risks exist, among others: (1)

· Locally optimal, rather than globally optimal solutions

· Expensive, non-shared, Run-the-engine intensive solutions

· Closed vendor/proprietary environments-little leverage.

· Solution band-aiding for the short term, but constraining in the long term

With ambitious goals, Enterprise architecture often face the daunting task of convincing business and IT leaders with operational responsibilities, near-term deliverables, and parochial interests to focus on the value of enterprise synergies. It’s all too common to see Enterprise architecture programs crash and burn because architects fail to convince key stakeholders of their value. (3)