Please note: This is an excerpt from Data Strategy by Sid Adelman, Larissa Moss and Majid Abai, published by Addison Wesley. The book should be available in early July, 2005.
A primary asset in IT is data and if most CIOs are asked about the assets under their control, most would be forced to respond that there are no plans for the use of this primary asset. They would have to admit that there is no inventory of data, that little is known about what data is in which database, that they have no idea about the quality of the data, and “there is no plan for the productive use of this asset.” Interestingly, the turnover in CIOs is also high, albeit not for the same reason.
Current Status in Contemporary Organizations
Very few organizations, large or small, have a well-defined data strategy If asked some will point you to dusty and outdated volumes of database standards, usually geared specifically to their Database Management System (DBMS). The more advanced organizations will have a subset of standards and perhaps a documented strategy on portions of what should be included in an overall strategy.
In most organizations, the value of data is not well understood. Data is considered the province of the department that creates it, and this data is often jealously guarded by that department, often under the guise of data ownership, which to the mind of the department head means secreting their data from all others in the organization. Some of the more astute people in your organization may recognize that data and the information derived from that data translate into real power, and that control of that data can be the steppingstone to advancement.
A data strategy is usually addressed piecemeal. A company will launch an effort to choose its preferred DBMS or will attack a database performance problem when response time becomes excessive. Rarely do organizations work from the big picture, and as a result they sub-optimize solutions, introduce programs which may have a deleterious effect on the overall enterprise, cause inconsistencies that result in major efforts for interfacing, or develop systems that cannot be easily integrated.
As application packages or enterprise resource programs (ERPs) are introduced, they bring with them a plethora of diverse standards, naming conventions, codes, and DBMS platforms. Modifying these packages to conform to the organization’s standards is unthinkable and so the data Tower of Babel becomes even more unmanageable.
There are also organizations that make terrible choices of their underlying technology infrastructure. For example, if a platform (operating system and DBMS) does not scale or will not support the organization’s service level agreements, projects will fail usually after millions are spent, years are wasted, and credibility and careers are dissipated. There is an interesting fallacy that holds that once the failure has occurred, the guilty (and some of the innocent) are sacrificed, the organization will have learned and therefore never make the same mistakes (or any other mistakes), and that success will be assured the second time around. There are countless instances of the second or the third time around also being failures, either making the same mistakes, or making new and equally catastrophic decisions. The absence of a sound data strategy provides a fertile ground for yet another disaster. The voice of reason is often ignored, those with an understanding of the potential problems are discouraged from voicing their opinions, and anyone who disagrees with a well-intentioned but unviable architecture is known as “not a team player.”
Most organizations have rogue databases running rogue and stealth applications. These are often on Excel or on Access but they may also be on SQL Server or on some other DBMS. The existence of these applications is often unknown (and purposely undisclosed) to IT. They came into existence because a department needed an application and users were unwilling to wait for IT to deliver, the department wanted total control or did not want to have to conform to IT’s standards. These departments either developed the applications themselves or hired an outside consultant to write the applications. The choice of the platform, the DBMS, and the development language was usually determined by the skills of those writing the application. There was almost no thought to conforming to organizational standards and certainly no thought to integrate with other applications.
Why A Data Strategy is Needed
Working without a data strategy is analogous to a company allowing each department and each person within each department to develop their own financial chart of accounts. This empowerment would allow each person in the organization to choose their own numbering scheme. Existing charts of accounts would be ignored as each person exercised his or her own creativity. Even to those of us who don’t wear green eye shades, the resulting chaos is obvious and easy to predict.
The chaos without A Data strategy is not as obvious, but the indicators abound: dirty data, redundant data, inconsistent data, inability to integrate, poor performance, terrible availability, little accountability, users who are becoming increasingly dissatisfied with the performance of IT, and the general feeling that things are out of control.
Without A Data strategy, the IT people within the organization have no guidelines for making the decisions that are absolutely crucial to the success of the IT organization. In addition, the absence of a strategy gives a blank check to those who want to pursue their own agendas including attachment to certain technologies, or Machiavellian aspirations of power. This includes those who want to try a new DBMS, new technologies (often unproven), and new tools that may or may not be appropriate. This type of environment provides no checks or validation for those who might be pursuing a strategy that has no hope for success.
A Data strategy should result in the development of systems with less risk and a much higher success rate. It should also result in much higher quality systems. A data strategy provides a chief technology officer (CTO) and CIO with a rationale to counter arguments for immature technology, and data management approaches which are inconsistent with existing strategies.
Value of data as an organization asset
Organizations have data on their customers, their suppliers, and transactional data that captures the heart of the business, the purchases, sales, customer calls, activities, as well as financial data. This data has value, which means it is an asset that is just as important, if not more important, than the buildings, the parts inventory, accounts receivable, and equipment assets of the organization. Some organizations that sell their data do carry it as an asset on their books and this may be considered intellectual capital. When a company gets evaluated for acquisition, evaluated as a merger candidate, or appraised by Wall Street, the notion of a going concern includes the value of the data as an asset. The Europeans have already adopted the notion of “fair-value accounting” and the United States is supposed to adopt this method of accounting by the end of 2006. This means they will be accounting for assets, previously unrecognized, and placing those assets on their books. An asset has future value and an organization’s data certainly has future value but this value has rarely been reflected on a company’s books. However, it’s lurking there sometimes as sound management, excellent technology, goodwill, and sometimes it is reflected in the price of the stock. It will be difficult to properly value this asset, especially data that has been in the organization for some time.
Why would we need to assign value to data since an organization cannot exist without the data that supports their applications? The reason is that budgets and resources are limited, and it may be difficult for the person attempting to get the needed budget and the right people resources. By showing the business value of data, the budget and the right staff should be easier to acquire.
New federal regulations require the CEO and the CFO to certify the accuracy of what is reported to the investment community and to the governmental regulators. Such certification would be greatly improved if the organization had a strong and viable data strategy.
Vision and Goals of the Enterprise
The vision of a data strategy that fits your organization has to conform to the overall strategy of IT, which in turn must conform to the strategy of the business. Therefore, the vision should conform to and support where the organization will want to be in five years.
Every organization, be it a publicly traded company, a private for-profit company, a non-profit organization, a governmental agency, or a quasi-governmental entity all have strategic goals. At minimum, the for-profit companies want to increase profits and most organizations have customer service in their goals as well as high levels of financial integrity.
Your goals will be unique because your organization is unique. Arriving at these goals and gaining consensus will be time consuming and will cause some dissension, but this is not a task to avoid; it must be addressed. Without the goals and the principles that follow, there will be little direction for the decisions you will be making
The following are a set of primary goals of IT. These goals should not be accepted without extensive discussion and the requisite commitment needed to make them work. None of these goals come free. There is a cost to each of them.
- Deliver systems faster
- Improve the relationship with the business community
- Improve the quality of delivered systems
- Reduce the risk and reduce the failures in application development
- Reduce costs
- Attract and retain good people
- Increase the productivity of application development
- Provide controls for the IT environment
- Improve the productivity of business people who use the data
Support of the IT Strategy
The target data environment does not exist in a vacuum. It is relevant only within the context of an overall IT strategy. This strategy, in turn, has been established to support the business of the organization, both for the existing environment and for the future plans of the business. Some organizations have been unable to pursue business opportunities because IT was unable to support them in a timely manner.
While we will be discussing the data environment, it is critical to recognize that a supporting infrastructure or architecture must be in place to be able to support a robust data environment.
Components of a Data Strategy
There are a number of key components in a data strategy, and each aspect is covered by a chapter in this book:
- Data integration
- Data quality
- Data modeling
- Organizational roles and responsibilities
- Performance and measurement
- Security and privacy
- DBMS selection
- Business intelligence
- Unstructured data
- Data categorization – categorizing data on the basis of performance requirements, security requirements, and availability requirements
Data Environment Assessment
Orienteering (the British call it Cunning Running) features cross-country running with a map and a compass. When learning to use a map and compass, the first exercise is to determine where you are on the map. Without this knowledge, you are absolutely lost. So it is with establishing a target data environment under the umbrella of a data strategy. First you must determine where you are today. This includes an assessment of your existing DBMSs, internal skills, culture, and legacy systems. Table 1 is a data Environment Assessment Questionnaire that should give you a first analysis of your existing data environment.
How is this going to happen?
The only way a data strategy will be developed and then implemented is with the very strong support of the CIO and business executives who must be educated on the criticality and impact of a good data strategy. It will also require that the business managers understand and concur with the goals and with the process; their cooperation is essential. A small team of dedicated (dedicated means full time with no other duties) people who will concentrate on building the data strategy and then concentrate on selling and then implementing the strategy. The ideal team will be composed of the chief technology officer (CTO) who will lead the project or at least be a major contributor to the project, a data administrator, a strong DBA, and a business analyst who comes from the business side. All these people should have a strong track record of accomplishment and a good relationship with key members of both IT and the business. They should also be intimately familiar with the business and the data that supports the organization. The team will have to sell the strategy and should be authorized to create the strategy and to implement it. Again, this means strong support from the CIO, senior directors, and the business executives, and this support must be communicated to everyone involved. A data strategy may attract many would-be assassins and the only thing that will keep them at bay is their understanding that the strategy will happen.
Table 1 Data Environment Assessment Questionnaire
The purpose of this questionnaire is to assist your organization in gathering basic information about its current data environment.
2. Application Production Environment
3. Application Development Environment
5. Distributed Data
mirrored metadata repositories or through XML-enabled metadata retrieval directly from tools?
6. Data Quality
7. Enterprise Issues
This is an excerpt from Data Strategy by Sid Adelman, Larissa Moss and Majid Abai, published by Addison Wesley. The book should be available in Early July,