Microsoft, Jerry Seinfeld, and Enterprise Architecture

ComputerWorld, 21 August 2008 reports on a news article in the Wall Street Journal that “Microsoft hires Seinfeld to bite Apple.”

“Continually painted by Apple and other rivals as uncool and unsafe, Microsoft plans to spend $300 million on a new series of advertisements designed around its ‘Windows Not Walls’ slogan that will feature Seinfeld and Microsoft Chairman Bill Gates.”

“Microsoft is not only trying to turn around a stodgy corporate image, but also wants to reverse recent product misfires, including the Windows Vista Operating System and the Zune digital music player.”

“Apple has rubbed in Microsoft’s lack of success and highlighted its own winning streak in a series of ‘Mac vs. PC’ ads.”

Is the Seinfeld ad a good branding strategy?

Well as my wife said, “this is as close as Microsoft can get to cool.”

Seinfeld, while rated by TV Guide in 2002 as one of the greatest TV programs of all times, is at this point somewhat dated—having aired nine seasons between 1989 and 1998—so it was over ten years ago! (Wikipedia)

In perspective, Seinfeld was already off the air before Vista, Zune, or the iPhone was ever created.

Microsoft’s attempt at reversing their “stodgy corporate image” is a feeble attempt that in fact solidifies that very image. It is no wonder that Microsoft is enamored with the 1990’s when they were the king of the hill in corporate America and in the technology arena with the launch of Microsoft Office in 1989 (the same year Seinfeld episode 1 aired) and before Google was founded in 1998 (the last season Seinfeld aired).

The Wall Street Journal, 21 August 2008, reported that “Microsoft is a little like the General Motors of technology. The software giant is, of course, much more successful, financially and in market share, than the troubled auto maker. But as at GM, Microsoft’s very size—over 90,000 employees—and it bureaucratic structure often make the company seem more stolid and less innovative than smaller, nimbler rivals like Google and Apple.”

From an enterprise architecture perspective where is Microsoft going wrong?

Microsoft is still living in the past—hence, the choice of the historic Jerry Seinfeld as their new image maker. Rather than acknowledging their current architecture and looking to the future or target architecture and how to transition forward, Microsoft keeps looking in the rearview mirror at where they were 10, 15, 20 years ago.

Microsoft keeps trying to catch up to the new generation of innovators like Google and Apple by either trying to acquire the 2^nd tier competition like Yahoo or developing copycat products like the Zune.

More recently, Microsoft has tried to become more agile and take advantage of smaller groups to break their bureaucratic and cultural logjam. One example is Live Labs, “a small operation that aims to turn technology theories into real, Web-based products relatively quickly. It has only about 125 employees, and even that modest number is broken up into smaller teams tackling specific projects.”

Even if Live Labs succeeds, what are the other 89,875 employees at Microsoft doing?

To really compete in the future, Microsoft needs better planning and governance and this is what enterprise architecture can bring them—a forward looking and improved decision making framework.

Microsoft, Jerry Seinfeld, and Enterprise Architecture

Earned Value Management and Enterprise Architecture

“Earned Value Management (EVM) is a project management technique used for measuring project progress in an objective manner. EVM combines measurements of technical performance (i.e., accomplishment of planned work), schedule performance (i.e., behind/ahead of schedule), and cost performance (i.e., under/over budget) within a single integrated methodology. When properly applied, EVM provides an early warning of performance problems.” (Wikipedia)

There is a terrific article on EVM called “If the Pharaoh Had Only Used An Earned Value System in Building the Pyramids,” by Lt. Col. William Neimann USAF (Ret.) Lt. Col. Neimann demonstrates very effectively how to use EVM (a scary topic to many) in a humorous scenario of ancient Egypt and the building of the pyramids.

The article starts as follows:

"The developer of the great pyramid of Egypt might be looked upon as the father of program management. He had one of the first programs in recorded history that required a great deal of integration and coordination (i.e. program management). He did not, however, have the relatively new concept of "earned value" to assist in the management of this ambitious program. An "earned value" concept is the heart of all defense contractor management information systems, which comply with DoD Instruction 5000.2 concerning the earned value management control system (EVMCS). But let's go back nearly 5,000 years to the construction of the pyramids to see if "earned value" would have been of any utility in managing that program.”

So what are the key measures in EVM for identifying cost and schedule variances?

(Positive is favorable, Negative is unfavorable)

• Cost Variance (CV) = Budgeted Cost for Work Performed (BCWP) - Actual Cost for Work Performed (ACWP)

So, if the Pharaoh’s project manager budgeted 14 million shekels for the pyramid construction, but actual cost came in at 13 million shekel, then the project has a positive or favorable cost variance of 1 million shekels. The pyramids are under budget.

• Schedule Variance (SV) = Budgeted Cost for Work Performed (BCWP) – Budgeted Cost for Work Scheduled (BCWS)

So, if Pharaoh’s project manager calculates that work performed was budgeted at $10 million shekels, but was scheduled to be 14 million shekels complete, then the project has a negative or unfavorable schedule variance of 4 million shekels. In other words, the pyramid builders have performed 4 million less work than planned. The pyramids are that behind schedule.

To calculate the overall project status at any given time:

• % Schedule = (Budgeted Cost for Work Scheduled (BCWS)/Budget At Completion (BAC)) * 100
• % Complete = (Budgeted Cost for Work Performed (BCWP)/Budget At Completion (BAC)) * 100
• % Spent = (Actual Cost for Work Performed (ACWP)/Budget At Completion (BAC)) * 100

How efficient is the project?

Greater than 1 is favorable, less than 1 us unfavorable:

• Cost efficiency = Budgeted Cost for Work Performed (BCWP)/Actual Cost for Work Performed (ACWP)
• Schedule efficiency = Budgeted Cost for Work Performed (BCWP)/Budgeted Cost for Work Scheduled (BCWS)

(Adapted from Earned Value Management Gold Card, Defense Acquisition University)

There are a number of other measures, but you get the idea.

EVM is important to Enterprise Architecture, why?

Enterprise architecture planning and IT governance is all about making order out of chaos in managing IT. By setting strategic direction with the architecture and enforcing it with sound governance, we set the stage for more successful IT project delivery. EVM is a way to measure IT projects success in terms of cost, schedule, and performance. Through EVM, we can measure our IT projects to ensure that we are meeting our EA plan and making course corrections as necessary through the governance process.

EA, IT governance, and EVM are ways to ensure that we no longer manage IT by the “seat of our pants” approach (gut, intuition, politics, and subjective management whim). We now have tools to plan, govern, and measure transformation.

Earned Value Management and Enterprise Architecture

Always Forward and Enterprise Architecture

ComputerWorld Magazine, 26 June 2008, has a terrific interview with Loraine Rodgers, formerly Xerox CIO, Citibank senior VP, city of Phoenix CIO, and American Express director.

Her early years…

Ms Rodgers found out at 16 that she was adopted and was “so angry at being lied to I threw away my merit scholarship and refused to go to college. But I took a programmer aptitude test and I aced it, so I started in IT as a programmer. I started in the weeds.”

Over the years, “I always volunteered for seemingly thankless jobs—challenging assignments that nobody wanted.”

Here’s the best part of what she said and I believe very inspirational…

“I am self-propelled, driven, excited about life, love to learn. I got my undergraduate degree at age 40, and my MBA at 42—all working full time. I move forward always—not necessarily in a straight line, but always forward. I have been fired once, laid off twice and promoted over 27 times. I repackage myself regularly and keep moving forward. I perceive the possibilities. I am not hindered by obstacles. There are no obstacles. Some things just take longer.”

WOW!

Ms. Rodgers is inspirational on an individual and organizational/enterprise architecture level.

Ms. Rodgers story is one of overcoming life’s challenges to succeed beyond probably her wildest dreams and most of ours. To succeed individually or as an organization, there are always challenges. Life is not a straight line upward, but is marked by up and downs, hopefully like Ms. Rodgers professional life, it has generally more ups then downs, and going always in an upward pattern.

Ms. Rodgers idea of always repackaging herself and constantly moving forward is terrific and in EA can be associated with an organization continually looking to reengineer and improve their processes and introduce new technologies to enable the mission and results of operation. The key is to always being grateful for what we have been granted, yet to always strive to improve things one step further: never to be satisfied with status quo or mediocrity.

Similarly, architecting the organization is not a one-time event; rather, it is an ongoing cycle of planning, governing, and transforming. Wash, rinse, repeat.

Whether on an individual or organizational level, we must learn to “move forward always—not necessarily in a straight line, but always forward!"

Always Forward and Enterprise Architecture

Bill Gates and Enterprise Architecture

On July 1, Bill Gates is stepping down from his day-to-day duties at Microsoft, but will continue to serve as Chairman. Bill Gates grew Microsoft into the worldwide software development leader with revenue of $51 billion for fiscal year ending June 2007 and 78,000 employees in 105 countries and regions.

As the prior CEO and chief software (and technical) architect it is definitely worthwhile to look at the legacy that Bill is leaving behind at Microsoft.

Fortune Magazine, 7 July 2008, provides four lasting imprints that Bill Gates is leaving on Microsoft and here are my thoughts on these as relates to enterprise architecture:

1. Software can do anything—Gates has a “utopian view of software. He believes it can do anything.” Like Bill Gates, we need to believe in the mission of our organization. Such belief is critical in inspiring passion for and dedication to what we do. However, blind belief that any one thing can do anything is folly. For example, software without hardware is a no-go as is hardware without software. Both are non-starters without the people to innovatively apply them to our greatest challenges.
2. Engineers rule—“Microsoft employees about 30,000 programmers among its 90,000 employees. In operating groups, engineers are involved in every major decision…Microsoft $8 billion computer science R&D lab is the world’s largest” Engineers are critical to solving our challenges, but you should not ignore marketing and sales either. Marketing and sales reach out and touch the people. You cannot ignore the human aspect to solving problems. Maybe it partially Microsoft’s obsessive engineering approach that has left it vulnerable on the people side, for example: “Apple’s biting ad campaign has successful painted Windows as uncool.”
3. “Institutionalize paranoia”—“’It’s very Microsoft to prepare for the worst,’ says Gates…Bill and Steve (Ballmer) created what I guess I’d characterize as a culture of crisis,’ says chief software architect, Ray Ozzie. There’s always someone who’s going to take the company down.” Paranoia is a disorder, but fighting for competitive advantage is reality. Your competitors are not laying down to die; they are fighting for their professional lives, and you need to meet the challenge every day if you want to be the best out there.
4. “Invest for the long term”—“Whatever the cycle is, we will keep investing through the cycle, because we know on the other side of whatever cycle happens, there is opportunity,” says entertainment division president Robbie Bach. The approach for long term planning is very enterprise architecture focused. However, the architecture planning without the good governance to administer structured, consistent, collaborative decision making is not very workable. Planning without effective decision making and enforcement falls short on the execution side. Again, perhaps here too, Microsoft could benefit from a less top heavy culture and a more open decision process, where all project and product stakeholders have a serious voice at the table. Then turning over the reins from Bill will not be as traumatic requiring approximately four years of preparation and turnover.

In the end, Microsoft is truly terrific company and Bill Gates is leaving a company that is nothing short of spectacular. Of course, even the best can get better with continuous learning and innovation and that is the next chapter for Microsoft in the world of the likes of Google and Apple.

Bill Gates and Enterprise Architecture

Information Warriors and Enterprise Architecture

In the digital age, information is critical to decision making. This is the case in the board room as well as on the battle field.

Information superiority is critical to our warfighters ability to intelligently and efficiently defeat our enemies. Many of the Department of Defense‘s modernization initiatives are aimed at getting the right information to the right people at the right time. Unfortunately, there are still some information gaps.

National Defense Magazine, December 2007, reports “troops in digital age, disconnected.”

Apparently, not everyone in the military is getting all the information they need (at least, not yet).

“The problem often is described as a ‘digital divide’ between the technology haves—the upper echelons of command—and the have-nots---the platoons and squads that are deployed in remote areas. These small units for the most part are disconnected from the Army’s main tactical networks and only are able to communicate with short-range voice radios…[however,] at the top echelons, commanders can tap into loads of data—maps, satellite images, video feeds, and reams of intelligence reports.”

Often though it is the small units on the front lines that need to send and receive critical information on combatants or other situational updates that can have life and death implications. This is why the net-centric strategy for virtually connecting all units is so important to achieving the vision of true information dominance.

Here are just a few important ways that information can help our warfighting capabilities:

• Providing information to soldiers to locate enemy combatants (such as from “live video from unmanned aircraft)
• Enabling location tracking of soldiers to save lives when they are endangered (such as from GPS locators)
• Sending information updates back to command for coordination and enhancing decision capabilities (such as from streaming voice and video, instant messaging, etc.)

The good news is that there are a lot of new information technologies coming online to aid our military, including the Future Combat Systems (FCS) and Joint Tactical Radio Systems (JTRS).

To ensure the success of these technologies, we need to manage the solutions using enterprise architecture to validate requirements, reengineer the processes, and effectively plan and govern the change.

1. Requirements management—“how to identify essential needs for information as opposed to providing information indiscriminately”
2. Business process reengineering—according to Marine Corps. CAPT Christopher Tsirlis “it’s not just about the latest and greatest technology but also changing the organization to use new technology.”
3. Planning/governance—we need link resources to results;“the technology exists, the question is how we resource it, and what is the right amount for each level.”

With a solid enterprise architecture and innovative technologies, we can and will enable the best information warriors in the world.

Information Warriors and Enterprise Architecture

ITIL and Enterprise Architecture

Both EA and ITIL are emerging disciplines that are growing in importance and impact.

Here are their basic definitions:

EA synthesizes business and technical information and develops information products and governance services to enable better decision making.

ITIL (Information Technology Infrastructure Library) “provides a comprehensive, consistent set of best practices focused on the management of IT services processes. It promotes a quality approach to achieving business effectiveness and efficiency in the use of information systems. ITIL is focused on IT Service Management, which is “concerned with delivering and supporting IT services that are appropriate to the business requirements of the organization.” (ITIL IT Service Management Essentials, Pink Elephant)

To me, EA and ITIL are mutually supportive. Here’s how:

• EA is a decision framework that provides for planning and governance. EA answers the question, what IT investment will we make?
• ITIL is a service framework that provides for execution of IT services. IT answers the question, how will we support and deliver on the IT investments?

In short, EA is the discipline that handles the decision processes up to the IT Investment and ITIL handles the service management once the decision to invest in IT is made.

What are the considerations for EA and ITIL:

• EA considers such things as return on investment, risk mitigation, business alignment, and technical compliance. EA focuses on business process improvement and new introduction of new technologies.
• ITIL practices areas include such services as incident management, problem resolution, change management, release management, configuration management, capacity, availability, service continuity, service level management and more.

How are EA and ITIL similar in terms of requirements management and their goals?

Each seeks to understand the business requirements and satisfy their customers: EA for the requirements for proposed new IT investments and ITIL for the service required to support those.

Both disciplines are goal-oriented in terms of wanting to improve effectiveness and efficiency:

• EA prescribes in planning, what are the right things we should we be doing (effectiveness) and in governance, how should we be doing them (efficiency) relative to IT investments.
• ITIL prescribes in service delivery, what are the right service deliverables (effectiveness) and in service support, how we should be providing service support (efficiency).

While EA and ITIL are complementary, ITIL picks up where EA leaves off—after the IT investment decision, but before the service execution.

ITIL and Enterprise Architecture

Obstacles to Information Sharing and Enterprise Architecture

Here is the target architecture for information sharing:

An interesting document I read presented these five steps to architecting data and making it into useful and usable information for the organizations and its end users:

1. “Request the dots”—identifying and requesting data from the producers of data
2. “Get the dots”—capturing data through manual and automated systems
3. “Find the dots”—discovering needed data and having access to it
4. “Connect the dots”—processing the data into information by aggregating, processing, and integrating it
5. “Use the dots”—utilize information for enhanced decision making

And here are the major obstacles to finding, connecting, and using the dots, a.k.a. information sharing in our organizations:

According to the Association for Enterprise Integration (AFEI), Information Sharing Working Group, 15 January 2008, “There is a human predilection to guard what is ours. The information we hold and the resources we use to create it are no exception…[moreover], individual agencies/organizations are not motivated to treat information as a shared asset.”

Here are some other disincentives to information-sharing from a program manager’s perspective:

1. “Charity work”—“First, to a program manager, information sharing looks like ‘charity work.’ Sharing information beyond the scope of the program costs money, but is not directly accretive to the mission of the program.”
2. Elevated risk—“Information sharing poses a risk in the sense that it creates the prospect of uninvited critique, review, evidence for litigation, and so on.”
3. Standards cost time and money—Building to common standards for information sharing can be costly to a program; the standards may be more complex to implement, may require additional level of testing, and certification of compliance.

Perhaps, this statement sums up best the information sharing problem at the project level: “Remember, a program manager is incentivized to deliver on time and on budget per customer requirements. His/her tenure may be two to five years [for a project]. The fact that the systems they manage may last 20 years and may be difficult to integrate in the last 15 of those years is not a compelling argument for a program manager to change his/her behavior.”

The way to overcome information hoarding is to develop rock solid Information Governance, so that the decision making and management of information is taken out of the hands of the program and project manager and is put into the hands of Information governance boards, communities of interest, and information stewards.

“The governance framework must articulate the accountability and authority promote standards and guidelines; ensure a consistent well-defined approach, processes and procedures; adjudicate disconnects; establish legal and policy enforcement; and use performance measures to ensure progress towards achieving information sharing goals.” (DoD Information Sharing Strategy, May 2007)

Information is an enterprise and national asset. Shared information is valuable because it is captured once, but is “used any number of times, by any number of users.” (AFEI)

To maintain its value, information must be kept current, accurate, complete, be easy to understand, and readily accessible; this is quality information and it is valuable to our decision makers and enhances our ability to deliver on mission.

Only through active information governance will we be able to achieve this end state. It will start with changing the culture and mindset that currently dictates that information is power and information is currency, and questions why share it. And information sharing will be realized when everyone in the organization, from the top executives to the hourly workers on the front lines, understand, advocate, promote and demand that information sharing be the new norm; that it is the only acceptable and rational behavior for achieving mission success!

Obstacles to Information Sharing and Enterprise Architecture

Disaster Preparedness and Enterprise Architecture

There are several disaster preparedness exercises that test and train our government and private sector partners’ ability to respond to incidents that could have catastrophic consequences. These exercises can be supported by a robust enterprise architecture; here is a brief description followed by a sketch of how EA can support disaster preparedness.

TOPOFF

“Top Officials (TOPOFF) is the nation’s premier terrorism preparedness exercise, involving top officials at every level of government, as well as representatives from the international community and private sector. Thousands of federal, state, territorial, and local officials engage in various activities as part of a robust, full-scale simulated response to a multi-faceted threat.” [Exercises have tested responses to chemical, biological, and radiological attacks.]

(http://www.dhs.gov/xprepresp/training/gc_1179350946764.shtm)

Cyber Storm

“The U.S. Department of Homeland Security’s (DHS) National Cyber Security Division (NCSD) successfully executed Cyber Storm, the first national cyber exercise Feb. 6 thru Feb. 10, 2006 [and a second biennial exercise was conducted in March 2008]. The exercise was the first government-led, full-scale cyber security exercise of its kind…Cyber Storm was designed to test communications, policies and procedures in response to various cyber attacks and to identify where further planning and process improvements are needed.”

(http://www.dhs.gov/xnews/releases/pr_1158340980371.shtm)

Government Computer News, 14 April 2008 reports on the Cyber Storm II exercise in which DHS “hosted federal, state, local, and international government agencies along with more than 40 private-sector companies” in these “high-stakes war games.”

Carl Banzhoff, the vice president and chief technology evangelist at McAfee summed it up as follows: “when the internet burns to the ground, how are you going to get updates?”

“The goal was to test communication coordination and partnerships across sectors.”

Bob Dix, the vice president of government affairs at Juniper Networks said that “the greatest impediment to sharing information still is trust.”

Whether the preparedness tests are for terrorism or cyber security, the essence is to test our ability in preparing, preventing, responding, and recovering from security incidents. This involves building capability for uninterrupted communications, information sharing, and coordinated response.

How can enterprise architecture support disaster preparedness?

1. Requirements—EA can capture strategic, high-level requirements from mission areas across the many functional areas of homeland security and weave these into a core map of capabilities to build to. For example, we have a requirement for system security that is mandated by law and policy, and securing our communications and infrastructure is a core capability for our information systems that must be executed. The weakest link in security has the potential to jeopardize all components and their response capability.
2. Planning—EA analyzes problem areas and uncovers gaps, redundancies, inefficiencies, and opportunities and uses these to drive business process improvement, reengineering, and the introduction of new technologies. Improved business processes and enabling technologies can enable integration, interoperability, standardization, modernization, and information sharing that can enable a better prepared homeland security infrastructure. For example, identifying shared mission communities and building information sharing and collaboration among stakeholders in these improves our preparedness abilities.
3. Governance—EA brings the various stakeholders to the table to vet decisions and ensure sound business process improvement and IT investments. Governance involves sharing information, building trust, and making decisions towards a unified way forward. For example, through the DHS Enterprise Architecture Board (EAB), the CIOs of all components can collaborate and engage in developing targets that will lead to implementation of best practices and standards across the Department that will improve overall efficiency of all components.

Of course, EA is not the be-all and end-all for preparedness, but it provides critical elements of requirements management, planning, and governance that contributes to disaster preparedness.

Disaster Preparedness and Enterprise Architecture

Fear, Greed and Enterprise Architecture

Fear and greed can have a huge influence on our decision making processes. Rather than making rational, informed decisions, we are driven by fear and greed and herd mentality to do stupid things.

Irrational decisions driven by fear and greed are the antithesis of rational, well-thought out decisions driven by enterprise architecture planning and governance.

In an interview with Fortune Magazine 28 April 2008 (and on a day of teaching students from the University of Pennsylvania’s Wharton School of Business), Warren Buffet stated: “when people panic, when fear takes over, or when greed takes over, people react just as irrationally as they have in the past.”

Similarly, in The Wall Street Journal 18 April 2008, an MIT financial economist, Andrew Lo, stated: “You have to understand the mechanism of how fear and greed impact market decisions.”

Fear and greed are affected by our endocrine system. According to Andrew Lo, “for better or for worse, biochemistry makes money go to our heads. ‘We need to understand that physiological aspects of brain behavior really impact financial decisions.”

Testosterone is the hormone that makes us irrationally exuberant, confident and greedy, and another hormone, cortisol, causes us to feel fear and gloom.

Do these hormones and the resulting emotions we feel impact our decisions and behavior?

Your bet!

“Among males and females, testosterone is a natural component in the chemistry of competition…it enhances persistence, fearlessness, and a willingness to take risks. Among athletes it rises in victory, and falls in defeat. “

Endocrinologists have identified “the ‘winners’ effect,’ in which successive victories boost levels of testosterone higher and higher, until the winner is drunk with success—so overconfident that he can no longer think clearly, assess risk properly or make sound decisions.” On the opposite side of the spectrum, “too much cortisol, secreted in response to stress, might in turn make them overly shy of risk.”

In the face of fear and greed, decision making is impaired and becomes irrational. Decisions are no longer driven by the facts on the ground or by judicious planning or sound governance that comes with disciplines like enterprise architecture. Instead, people become slaves to their hormones and emotional effects.

In Fortune Magazine, Warren Buffet warned against falling into the fear/greed trap of decision making. He stated: “I always say you should get greedy when other are fearful and fearful when others are greedy. But that’s too much to expect. Of course [at a minimum] you shouldn’t get greedy when others get greedy and fearful when others get fearful.”

Rather than optimizing decision making, our fears and greed destabilize our ability to think clearly and rationally. When this happens, we need to rely more than ever on our enterprise architecture target and plans and on our governance processes, so that we stay focused on our goals and path to them and not be sidetracked by, as Alan Greenspan stated, “irrational exuberance” or irrational fears.

Fear, Greed and Enterprise Architecture

Master Data Management and Enterprise Architecture

“Master Data Management (MDM), also known as Reference Data Management, is a sub-discipline of data architecture within Information Technology (IT) that focuses on the management of reference or master data that is shared by several disparate IT systems and groups. MDM is required to enable consistent computing between diverse system architectures and business functions.” (Wikipedia)

“Master data are the critical nouns of a business and fall generally into four groupings: people, things, places, and concepts. Further categorizations within those groupings are called subject areas, domain areas, or entity types…Master data can be described by the way that it interacts with other data. For example, in transaction systems, master data is almost always involved with transactional data. A customer buys a product. A vendor sells a part, and a partner delivers a crate of materials to a location… Master data can be described by the way that it is Created, Read, Updated, Deleted, and searched. This life cycle is called the CRUD cycle…Why should I manage master data? Because it is used by multiple applications, an error in master data can cause errors in all the applications that use it. (“The What, Why, and How of Master Data Management” by Wolter and Haselden, Microsoft Corporation, November 2006)

How can MDM software help manage MDM? Wolter and Haselden identify three primary methods:

• Single-copy of master data—where all changes and additions are made to the master and all applications accessing it use the current master data set
• Multiple copies of master data—master data is updated in a single master, but the data is sent out to the source systems where data sets are stored locally and changes to non-master data can be made)
• Continuous merge—where changes are made to the source data sets and are sent to the master to be merged and resent out to the source data sets again.

CIO.com, in “Demystifying Master Data Management”, 30 April 2007 reports that “unfortunately, most companies don't have a precise view about their customers, products, suppliers, inventory or even employees. Whenever companies add new enterprise applications to "manage" data, they unwittingly contribute to an overall confusion about a corporation's overall view of the enterprise. As a result, the concept of master data management (MDM)—creating a single, unified view of an organization—is growing in importance.” However, the article notes that adding MDM technologies will not magically correct an organization’s data quality issues, as noted in “a recent report from The Data Warehousing Institute that found 83 percent of organizations suffer from bad data for reasons that have nothing to do with technology. Among the causes of poor-quality data were inaccurate reporting, internal disagreements over which data is appropriate and incorrect definitions rendering the data unusable.”

So the essence of an MDM initiative is to first improve data quality by developing the process to define, categorize, and identify authoritative sources for data, and only then to apply MDM software to build a single view of the data.

MDM is important to enterprise architecture for a number of reasons:

• Information sharing—MDM is critical to information sharing, data integration, and reconciliation, as it establishes an authoritative source of data that can be shared between systems or organizational entities.
• Data governance—MDM helps establish the basis for sound data governance, since data owners, stewards, and users need to be able to distinguish good data from bad data, define data objects, establish data standards, metadata requirements and registries for discoverability, access rights, transfer protocols and methods, and maybe most importantly a governance process that defines who is allowed to change system data and how.
• Business Intelligence—MDM enables business intelligence by providing for an integration of data for mining, reporting, and decision support.

Creating authoritative master data is an imperative for data and systems integrity, and good decision making based on sound enterprise data.

Master Data Management and Enterprise Architecture

SDLC, CPIC, PMBOK, and EA

User-centric EA seeks to align the various life cycle IT system processes to help users understand, navigate, and complete these as simply and smoothly as possible.

Below is an alignment of the processes for System Development Life Cycle (SDLC), Capital Planning and Investment Control (CPIC), Enterprise Architecture (EA), and the Project Management Book of Knowledge (PMBOK).

SDLC	CPIC	EA	PMBOK
Conceptual Planning	Select	Business Alignment	Initiating
Planning & Requirements	Control	Technical Alignment	Planning
Design			Executing
Development & Testing
Implementation
Operations & Maintenance	Evaluate	Architecture Assessment
Disposition			Closing

The graphic demonstrates that the various IT system processes align quite nicely, and that user seeking to stand up a new system or make major changes to existing systems can follow the basic 7 steps of the SDLC and complete the requirements of CPIC, EA, and PMBOK along the way (the touch points are all identified).

The way to read this graphic is as follows:

For example, in the first phase of the SDLC, the conceptual planning stage, the user does the following: 1) defines their need (SDLC process) 2) develop their business justification and seek to obtain approval and funding from the IT Investment Review Board (CPIC process) 3) develops their business alignment and seeks approval from the Enterprise Architecture Board (EA process), and 4) define their project and seek authorization to proceed (PMBOK process).

For CPIC, users identify the following:

• Select—How does the investment meet business decision criteria?
• Control—Is the investment being managed with the planned cost, schedule, and performance criteria?
• Evaluate—Did the investment meet the promised performance goals?

For EA, users demonstrate the following:

• Business Alignment—Does the investment support the agency mission?
• Technical Alignment—Does the investment interoperate within the technology infrastructure and meet technical standards?
• Architecture Assessment—Is there a need to update the architecture?

For PMBOK, users complete various project management processes:

• Initiating—Define and authorize the project.
• Planning—Define objectives and plan course of action.
• Executing—Integrates resources to carry out project management plan.
• Closing—Accept product or service.

Note: The EA/CPIC alignment is adapted from Architecture Alignment and Assessment Guide, Chief Information Officers Council, August 2001. The PMBOK definitions are adopted from the Project Management Book of Knowledge, Third Edition.

User-centric EA promotes the alignment of the various IT system processes to help users to easily understand the touch points in the various life cycle steps to getting their system up and running. Moreover, the alignment enables the CIO to develop processes and job aids to assist and ‘speed’ users through the process. Thus, the processes are transformed from inhibitors to facilitators of systems progress for the enterprise.

SDLC, CPIC, PMBOK, and EA