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:
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:
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:
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.
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:
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.
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.
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.
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.
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.
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: