An enterprise data model is a blueprint: a means of ensuring that standards for creating the IT function exist and that they are appropriately integrated with the overall function of the business enterprise the function is designed to support.
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. The following list identifies ten of the most frequently made errors in the process of developing an enterprise architecture.
- 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. 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.
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. Several effective methods for achieving this follow:
- 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.
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.
Consider the following 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.