15.00 - Things To Avoid When Developing an Enterprise Data Model - Teradata Database

Teradata Database Design

prodname
Teradata Database
vrm_release
15.00
category
User Guide
featnum
B035-1094-015K

Things To Avoid When Developing an Enterprise Data Model

IT organizations often commit several common mistakes in the course of developing the architecture for their enterprise data model. Instead of providing the usual checklist of recommended practices for developing a successful enterprise data architecture, Rehkopf and Wybolt (2003) identify ten of the most frequently made errors in the process of developing an enterprise architecture.

Their list of common errors is as follows, listed in no particular order:

  • Treating the architecture as if it were a finished product rather than a process.
  • Like the enterprise data warehouse, the enterprise data architecture is an ongoing process, not a fixed, concrete thing. As such, it has a continuous life cycle that supports the following areas:

  • Identification of particular areas that particular decisions and technology selections affect.
  • Provision of guidelines for investment decisions.
  • Identification of the major processes, skills, and components needed to support the IT projects that support the enterprise.
  • Assuming that technical personnel make the best architects.
  • Of course, an enterprise data architect must be highly technical. The point Rehkopf and Wybolt are making is that architects must possess a wide ranging skill set, and that sheer technical competence in the absence of other equally important skills such as the following is a formula for failure:

  • Understanding and matching business objectives and needs to technological systems
  • Auditing architectural compliance to ensure its overall integrity
  • Educating and consulting with users about various architectural issues and so on
  • Rejecting input because it does not fit the existing (or preconceived) architecture or, as Rehkopf and Wybolt put it simply, "saying ‘no’."
  • Ideally, such decisions should be made by a Chief Information or Technology Officer, not by the architecture staff. The role of the architects is to keep the enterprise architecture life cycle process working, not to assume (or reject) the risks of technology decisions.

  • Failing to communicate early and often.
  • As stated previously, the enterprise data architecture is an ongoing process that must not only be updated continuously, but also sold and re‑sold to its constituents. Rehkopf and Wybolt suggest several effective methods for achieving this:

  • Report all important modifications to the architecture to all affected members of the user community.
  • Summarize and report case studies, both of works in progress and of completed projects, of how the architecture has been put into effect by users, including both successful and unsuccessful applications.
  • Conduct periodic refresher presentations and seminars on the architecture at department or staff meetings.
  • Produce architecture documentation in the form of checklists, templates, and contact lists.
  • Partition the enterprise architecture want list documentation into broad sets such as must have, should have, and nice to have.
  • Create an architecture intranet site or portal so users can easily access all enterprise project documentation.
  • Failing to explain concepts in simple, non‑technical language.
  • It is almost always a mistake to present an architecture project in purely technical terms. Instead, describe projects in terms of the business problems they are intended to reduce or solve.

    For example, whether a user‑defined function or stored procedure must be written to solve the problem is almost never relevant, nor is the question of whether the procedure should be written in SQL or C. Only the business problem to be solved is important along with a non‑technical explanation of how the problem is solved by the new application.

  • Mistaking standards for architecture.
  • Without being embedded in an enterprise data architecture, standards are nothing more than a list of things that are (or are not) permitted. For example, your standard might state that a tool for a particular category of tasks must support x, y, and z. When embedded within an enterprise architecture, those standards would also be augmented by a set of usage guidelines that map specific categories of tools to specific types of problems that the architecture is designed to solve.

  • Forgetting to assess people and process impacts.
  • Organizations frequently evaluate technology in a void, failing to consider the impact of new technologies on people and processes. Not only are ergonomic factors often overlooked, but even such basic business components as the staffing and administration of new technologies are often not evaluated.

    With respect to processes, factors such as capacity planning, security management, user administration, and operations management are also frequently forgotten.

  • Aligning with strategies rather than business goals and cultural values.
  • The problem with this approach is that business strategies not only change frequently, but often fail. If the enterprise needs to revise its strategy, it should not also have to revise its data architecture.

    Instead, consider aligning your IT architecture with the business goals and cultural values of the corporation. For example, a commonly stated business goal is to provide mid‑market products at the best price with the least possible inconvenience.

    An example of aligning the corporate information architecture with this goal might be optimizing supply chain performance with low cost and maximally efficient transaction processing.

  • Compelling unwilling constituents to participate in architectural decisions.
  • Rehkopf and Wybolt describe this behavior as acting like an uninvited party crasher. Enterprise architects should seek out individuals within the organization who understand the value of a sound enterprise data architecture and are willing to participate in developing that architecture.

    Avoid the temptation to coerce the participation of unwilling individuals, no matter how valuable you perceive their input to be.

  • Introducing technology before its time.
  • Avoid introducing new technologies just because the industry perceives them to be the next big thing. Instead, focus on finding proven technologies that can address existing business problems or that can enable the delivery of new business value.

    To facilitate this, Rehkopf and Wybolt identify 5 best practices for assessing the readiness of candidate technologies to support existing business problems and make it possible to bring new value into the enterprise:

  • Create a technology assessment program.
  • Establish pilot projects to evaluate and assess the readiness of new technologies.
  • Devise training programs to enhance the skills of the staff members who will be using the new technologies.
  • Design phased migration plans that parallel the evolution of updated staff member skills.
  • Consider engaging in partner relationships with the technology vendors to help introduce new technologies.