As I discussed in an earlier column (What is a Data Model? ), even the data management artifacts that we create (for example, conceptual and logical data models) exist primarily to guide and direct these conversations. As I’ve said before, I think we often misunderstand the Zachman Framework: We look at the Framework and see nothing but the artifacts, and we think of the Framework in terms of producing the artifacts. But that’s not really what the process of architecture is about! At each level of architecture, a two-way conversation (a dialog) is occurring between stakeholders in the architectural process. The architect, for example, talks to the clients about their needs and requirements. The clients, in turn, talk with the architect about what is needed to get their house built. The architect talks to the contractor about how the clients’ requirements can be realized; the contractor talks to the architect to get a better understanding of what those requirements are. The artifacts that are produced (architectural drawings, contractor’s plans, shop specifications, etc.) are the records of these conversations.
Which brings us back to the data architecture roadmap. The purpose of the roadmap is to define a scope, a vision, and a set of requirements for data and information management (based on a collection of stakeholder interviews), and then develop a 3-5 year program to achieve these desired goals. Developing the roadmap involves four sets of conversations:
- Conversations with the Enterprise Architecture group at my company (and with my manager) to initiate the project, develop the framework for the roadmap (scope, vision, etc.), and prepare for the stakeholder interviews.
- Interviews with high-level business and IT stakeholders to develop the set of data and information requirements that will be addressed in the roadmap.
- Conversations with my manager and other IT resource managers to develop a realistic 5-year schedule of projects and deliverables to achieve the goals of the roadmap.
- A final set of conversations with the Enterprise Architecture group to get the roadmap approved.
The scope and vision for our data architecture roadmap is centered around Enterprise Information Management (EIM), defined as “a set of disciplines, technologies and best practices to manage information as an enterprise asset.”1 The vision for EIM at our company embraces the following goals:
- To create a semantic layer of common business data definitions across our entire company (this could include a high-level enterprise data model and a set of common business data definitions).
- To define an effective data governance process to manage data at all levels of our company (one in which data content would be governed by the business units, with oversight at the enterprise level).
- To create a set of shared data services that enable quick and easy reuse of data to support enterprise information processes (this would include a set of master/reference databases and canonical XML schema definitions).
- To move toward the adoption of industry-standard best practices for data and information management (as codified, for example, in DAMA International’s Data Management Body of Knowledge).
I’m looking forward to the ensuing stakeholder conversations that will help determine the final form of our data architecture roadmap. My initial goal will be to identify our stakeholders’ data and information pain points and arenas of opportunity, as well as to document which subsets of our enterprise data are managed by each of our business units. Subsequent steps will involve identifying sets of master or reference data that can (and should) be shared across the company and that therefore should fall under the auspices of data governance.
From these many conversations, our path forward will be discovered!
I’d like to make this a dialogue, so please feel free to email your questions, comments and concerns to me at Larry_Burns@comcast.net. Thanks for reading!
Reference:
- For more information on EIM, see the EIM Institute’s website.
