Putting the "I" Back in IT Planning
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Putting the "I" Back in IT Planning
In "How Did IT Get this Way?" DMReview (March, 2002) Rob Seiner says:
"If your company doesn't have any problems managing its information assets, this test is not for you. Okay. That should have eliminated...nobody."
Sadly, I agree with Rob. Nonetheless, perhaps twenty years ago, this situation (every company having problems managing information) would have been less disturbing. While many factors contribute to creating these problems, lack of planning or "dis-integrated" planning is a key factor. As a friend says, "we don't plan to fail, we fail to plan." Some examples of planning failures that we continue to see in our practice are:
A lack of formal, enterprise-wide IT planning (architecture) or unrelated pockets of planning
Data/information planning isolated from the "real" IT architecture (i.e., the technology architecture)
The terms "data architecture" and "data model" used inter-changeably;
The data model constructed before or without (reference to) the enterprise architecture
The data management organization viewed as a group of eccentrics who aren't nearly as vital to IT as the developers and data base administrators, or worse—viewed as a roadblock.
Like many, I began my IT career as a programmer, and moved "up" to design, then analysis, all at the project level. Then, listening to James Martin, I was "awakened." It took a few un-sought job "opportunities" before I fully understood the value and the business benefits of integrated IT planning at the enterprise level—not the least of which is planning for the business data. Even now, when the criticality of data to the business is almost universally understood, many organizations resist using IT resources to develop an architecture that goes beyond technology. In the past couple of years, I have seen an intensified interest in attendees of our architecture seminars in more broad-based architecture, especially when mergers and consolidations virtually require it. I believe we can leverage this interest to begin to make some profound changes in the process—or lack thereof—that we use to create plans for IT. Data and the data manager play a vital translation role in this process.
I have recently been reminded of how apt is the comparison of IT to building a house. I learned first-hand that what you plan formally is more likely to happen, that what you include in the plan is most likely to be executed and that what you omit—like an extra closet—will likely not see the light of day. I was reminded also that key to a successful outcome is the ability to translate intent from the client to the architect, through the builder and to the implementers who execute the plan (electrician, plumber, etc.). In the instance to which I refer, the builder's outstanding ability to translate the architect's plan into directions for the implementers resulted in tremendous success.
In our workplace organizations, the business client, the architect, the data manager and the developers often need to forge stronger relationships and call on their translation skills. To create better, integrated IT plans, we identify and implement process modifications. Working within better-defined processes, our
IT professionals can have a profound impact on the quality of IT implementations, and ultimately on the organization's success.
In our practice, we call the broad-based, enterprise-wide integrated IT plan the "Enterprise Information Architecture" (EIA)*. Presented here is one of the approaches we use to begin to close some of the gaps in the IT planning process. Specifically, we look at how to create the often-missing link between enterprise architecture and data modeling. Here's how the two views line up:
|
Enterprise Architecture Model |
Data Model |
|
Business View of IT Strategic View Planning Phase Relationship of Data to Business Functions, External Interfaces, Services, Technologies/Strategies Key Data Interactions, Capture and Storage Art? |
IT View of Business Logical View Analysis Phase Relationship of data to other data Data Structure Science? |
When the gaps between the two views are not bridged, the result may be technically excellent but useless outputs. For example, in one organization, when we developed the target architecture required to support a new business direction, it was an almost impossible task to persuade the data team to "reverse engineer" the enterprise data model. In another organization, we urged the decision-makers not to purchase an external data model before we defined the target architecture. Neither of these situations was likely to produce the sort of high-quality business data on which organizations today rely.
* "where "enterprise" means all parts of the company, business unit, agency or organization. "Information" means all the data required to run the enterprise and includes the functions, the technology and the people that create, access, use or transform that data into information and ultimately, knowledge. "Architecture" refers to the set of plans that describes how all parts of the IT infrastructure need to behave to support the enterprise needs and goals."
** "...the one-page entity-relationship model that describes the relationship of each set of subject data included in the architecture model to every other set."
Our experiences—the good, the painful and the almost terminally ugly—have led us to devise and use some very practical approaches for creating the necessary linkages and closing the gaps. In the nine "Dos and Don'ts" that follow, the architect and the data manager play key process roles in creating linkages through translation.
Do include key information "subject areas" and business functions in your target IT architecture. If your "architecture" is simply a technology plan, throw it away and start over. The plan needs to include the data, function and technology components of the business and how they are related. Architecture modeling is one of the best ways to portray the relationships. The architecture model should include the data architecture—by identifying target operational data stores, data warehouses, data marts and reference data.
Do use business language in the architecture models. The architect plays a critical role in the translation of business needs to IT architecture. If the business calls them "clients" don't refer to them as "customers" in the architecture. There is plenty of time to precisely name objects in the detailed logical data models.
Do get business and IT concurrence on the architecture before you proceed any further. This tests the accuracy of your translation. Any lack of time spent here is sure to cost you greatly in later steps.
Do use the architecture model as the basis for developing a conceptual data model.** The data analyst plays a critical role in the translation from architecture model to data model. This requires the data analyst to identify large, conceptual data subject areas referenced in the lowest level target state architecture models. These data areas are translated to provide an initial set of conceptual "mega-entities". The data analyst edits the mega-entities by adding or dividing where big, obvious gaps exist.
Do include business policies in the conceptual data model—those very high-level written statements or guidelines that describe how the business wants to operate on the information. Don't try to get "atomic" or pin down "rules" yet.
Do set a few, key standards—names and definitions for the mega-entities. Since a conceptual data model should fit on one page, there should only be a few, not many, entities that require standards, and these should be the basic information blocks of the organization, e.g., Customer, Product, Employee. These will be the basis for more detailed modeling and development.
Do get concurrence from the architect and the business on the conceptual data model before you build anything new. If possible, do use the same participants who reviewed the architecture model. In a couple of cases, I found marketing and operations leaders who were eager to participate in both reviews. If this group doesn't understand the conceptual data model, then it is not conceptual or it is not an accurate translation.
Do consider "just in time" logical modeling as you go forward—developing detailed logical data models only for new, large funded projects that comply with the target architecture.
Do publish and update. Even the most excellent plans, if "secret" or static, are useless. Make sure the architecture models and the data models are available to the business and IT—architects, analysts, designers and developers—through the intranet, repositories and open forums.
This is a fairly simple, but not necessarily easy, process to execute. You are likely to meet resistance, which is why the concurrence steps are so important—and often, so time consuming. But having undertaken these steps, you will have put in place key linkages required to accurately translate the business requirements to architecture, to translate the architecture to data models, and to use the data models to provide direction and guidance for on-target code and business data implementations. By following this process, you will contribute heavily, not only to the elimination of problems managing information, but also to the delivery of IT components that actually meet the business goals—and that, hopefully, is why we are getting paid.