Role-ing Along Toward E-Commerce

It responsibilities change with the times, but not always for the better

How do you sell the business on a common data language and get developers interested in using an enterprise data model? The answer, I believe, is “Understand your audience.” It is the most important and coincidentally the simplest thing that I learned from the implementation of my last project, a corporate data model (CDM).

In “What We Have Here Is a Failure to Communicate” (July 13, 1999), Trustman and Meshako stressed the need for a common language between IS and the business to improve communication, and ultimately, to improve requirements analysis. Without this lingua franca, they said, systems are certain to fail. I developed a project built on the principle that successful systems development depends on good communication. A CDM is the tool for the job.

How It Came to Be

While in the throes of a new customer relationship management project, my team recognized the need for a tool to help us better understand our “customer” (which is how we regarded any individual or organization with a relationship to our company) and its numerous business relationships across the enterprise. A CDM, we were told, fit the bill.

Having learned from past projects that we mere mortals are naturally better editors than creators, we employed a “skeleton-model” approach. Reusing the data groupings of our enterprise architecture project, we etched out a bare-bones CDM. We then set out for the business areas, in search of “the truth.” After several cross-functional, joint application-development sessions, we returned to our cubicles in IS and applied some loose rules of normalization, quality checks, peer reviews, and so on. … And wouldn’t you know it — we had a CDM! (Of course, this process was not as easy as my summary implies.)

Seeking Approval

At this point, we stepped back and took a hard look at our data-model documentation. We had created some kernel diagrams, a list of definitions, and some high-level relationships. Our conclusion? Boy, was it ugly! And boring! How could we expect anyone to get excited about reviewing or using this thing? Specifically, we identified the following problems with the documentation’s diagrams and usability:

The Diagrams:

• Size. The diagrams were too big. We needed a segue from the current functional area “tunnel-vision” to the new enterprise view so that we didn’t have to cram so much information into each diagram.

• Continuity. The diagrams somehow seemed unrelated to one another and repetitive at the same time.

• Aesthetics. The diagram space seemed very cluttered. We had not considered how to organize the entities on the data model and found little guidance in data modeling literature.

• Infoglut. The diagrams gave too much detail about the relationships. As a company new to data modeling, we suspected that showing the cardinality and optionality of relationships to the business might irritate our audience.

Documentation Usability:

• Words. The pictures were indeed worth thousands of words — but which words? It wasn’t crystal clear what we expected our business and IS reviewers to take away from the diagrams.

• Fit. The documents didn’t “fit” together easily. We had a repository of definitions, synonyms, and sample attributes, and a group of high-level diagrams — but their interrelationship was not readily apparent. How could we make them more user friendly?

To deal with the presentation and usability of the diagrams and essentially “market” ourselves directly to our end-users, we set out on a mission of “Disneyfication.” (In other words, we made them user friendlier by asking ourselves, what would Disney do?) We wanted our end-users to want to use our CDM.

Disneyfication led us to these guidelines:

• Small worlds (create subject areas). To provide a segue to our enterprise data view, we organized the data into 10 key subject areas. We realized it would be difficult for some of our audience to make the leap to an enterprise view, so we provided a stepping stone: a different (nonfunctional) area view.

• Our kingdom (use the highest-level view). To link the subject areas together, we created a high-level picture of all 10 icons linked to our company logo. This view communicated to the business and IS that all 10 subject areas, put together, represented our CDM.

• Technicolor (add color and space). Using common sense, we adjusted the spacing and organization of the entities in the models until the white space was balanced and the flow made sense. We also assigned an icon to each subject area. For example, as an insurance company, we are naturally concerned with claims information, so claims became a subject area. We attached an icon of a cartoon car crash to the diagram to make it immediately clear that the diagram’s subject was claims. We also added different color schemes to the diagrams to make them unique and more eye-pleasing.

• Rated G for general audience (remove some detail). We replaced the cardinality and optionality relationship notation with simple straight lines. We decided that the most we hoped to communicate to our reader was an appreciation that a high-level relationship existed — no more and no less.

• Narration (add some words). We added a narrative to each subject area to describe the general message of the diagram, the importance of certain entity groupings, and to note its relationship to other diagrams. In fact, each diagram had its own caption taken directly from a document the president wrote, to back up the importance of each subject area in our business strategy. We then linked the narrative to the diagram by using the same icon in its document header. We also created a help document outlining how to read the diagrams.

• Theme park (use Web pages). Finally, for ease of use, we created an HTML version of the whole documentation package. We used hyperlinks in each diagram to let readers easily jump to the related entity definitions and narratives within the documentation.

The Implementation Plan

I don’t mind telling you that after we made these changes we thought we had a pretty slick package! But we had new questions: How could we successfully roll it out? And how could we ensure its continued use on future IS projects? Well, we did some brainstorming, read some research on change management, and (as modelers do) we drew some pictures! Our resulting CDM implementation addressed four key components: vision, skills, incentives, and resources.

• Share the vision. We communicated our vision for the CDM through various executive and functional-area presentations, and we ensured a consistent message through our IS newsletter, Web page implementation, informal conversations, and our sponsor’s support.

• Provide the skills. We provided training to use the CDM in the form of our Web page implementation, user manual, and personalized demos.

• Create incentives. We “sold” the benefits of the CDM in our presentations. We promised our managers and developers that the CDM would give them greater productivity by saving them time in logical data modeling, speeding up the acceptance of project deliverables, ensuring better requirements gathering, and aiding them in better design creation.

• Outline resources. We provided subject matter experts (our team) and the facilities and equipment to use the CDM (Oracle’s Designer 2000, Netscape, Word, and so on).

Understand Your Audience

Fate intervened just in time to save this project from being ignored out of existence. I happened to see an article on the Web about analyzing the audience, and its ideas implanted themselves in my mind. In my opinion, it really did save the project, because our opportunity to share our vision was confined primarily to making presentations to different groups in the company. Therefore, those presentations had to be persuasive. I used the article’s advice to greatly improve the content and message of our kick-off presentations, as you’ll see if you read on….

The Executive Group — Buy-In and Obstacles. Of the lessons I took from this experience, the one that left the biggest impression on me was learning the importance of the WIIFM approach (What’s In It for Me?). The president and vice presidents don’t care about how pretty we’ve made a data model; in fact, they don’t really even care about a cool Web page design. (Imagine that!) What they do care about, of course, is the infamous Bottom Line.

After months of being bumped from the agenda at the monthly executive meeting, we finally presented the execs with a short update on the CDM as part of our application architecture project. We stressed the enterprise need for a CDM to help save the company time and money in application development and better align applications with the business strategy. This message caught their attention, so we were able to secure continued support for our project and a request for further business participation as we forged ahead with the rollout to the rest of the company.

IS Staff — a Service Theme. We recognized early that our colleagues in IS might see the CDM as more of a hindrance than a help, so we set out to reposition our model and team as components of an in-house service. We likened our CDM to a grocery store, reasoning that it was a service analogy readily understood by all. (See Figure 1.) We presented the following ideas in a short kick-off presentation that included managers, business systems analysts, and developers:

FIGURE 1 Advertising flyer used to notify IS staff of rollout in department meeting.

• Think of the CDM as a grocery store.

• Our “fresh produce” equals business-approved entities loaded with attributes and packaged with relationship “recipes.”

• Our products are affordable (save you time) because they are reusable.

• We have an accessible aisle layout comprising 10 subject areas.

• We have easy electronic check-out through our CASE tool.

• We support e-commerce, by virtue of a Web-page design.

We set up the conference room as a grocery store, complete with free samples. (Everyone knows that your presentation’s success is almost guaranteed if you provide free food!) We organized tables to resemble aisles and covered several boxed and canned goods with our entity names, definitions, and “sample ingredients” (data attributes). We then walked through a case study showing how our data warehouse team had “shopped” our CDM aisles and selected entities based on their “shopping list” of requirements from the business (our “suppliers”). It may sound a little goofy, but this strategy was very effective.

Field Management Conference — It’s All About Cross-Functional Communication. So why would an underwriting or claims manager in the field care about a CDM? Again, it’s all about understanding your audience. We interviewed the vice president of underwriting to get an idea of the daily obstacles our field managers encountered — in particular, those related to our information systems. Their biggest complaint related to data entry. Staff productivity was suffering because our multiple systems required duplication of data entry. We used this information to position our CDM as a method to help solve this problem. We also piggybacked on the theme of the recent management conference: best practices.

We decided our message would be about the need for a common language. Our goal was to show field management that in order to build systems that talked to one another, thus removing the need for duplicate data entry, we needed to start out with a “common language” across functional areas. With that in mind, our presentation began with a short game we called “Cool Definitions, Man!” (The name reinforced our CDM acronym; the game was like Jeopardy.) The emcee asked three managers, each from a different functional area (finance, underwriting, and IS) to define the word “widget.” The goal of the game was to show the difference we bring to our understanding of terms, based on our backgrounds and experience. We also created a handout for managers to take back to the office, outlining our expectations for them to support the common language of the CDM and communicate its existence with their staff.

Success and Feedback So Far

The feedback on the presentations has been overwhelmingly positive. One senior developer commented that it was the best presentation he’d ever seen! Countless managers and vice presidents have gone out of their way to commend us on our presentation at the management conference. Our Web pages, at last count, had received about 80 unique hits since the conference. Not too shabby!

As for the CDM itself, we are promoting its use through word of mouth and feedback to our sponsors and management. We continue to sell its success by reviewing and reflecting on its use on individual projects. We are interviewing users to see how their projects incorporated the CDM, to estimate the time saved in creating definitions and modeling relationships by using the CDM as common ground from which to start the project.

Keeping It Current

In February, we rolled out our “Data Definition Management Group” (a.k.a. the data team). This group’s membership includes people from all functional areas in the company. Its main objectives are to formally review the CDM on a semi-annual basis and, as needed, track its use on IS development projects. We chose this approach to minimize the business’s time commitment. From the start, we tried to set up the team for success. Following the “best practices” of project management research, we involved our team members up-front in the definition of their roles and the objectives for the team. We also drafted a group contract outlining acceptable behavior for the team in meetings and the defined process for making changes to the model. We asked team members to select their subject areas of responsibility, to encourage accountability in the maintenance of the definitions and diagrams. I have to point out that this process is quite different from our company’s regular culture, with respect to team formation and especially how we hold meetings, but so far it seems to be working.

Since its official rollout, I’ve heard that the CDM has been “embraced” by several executives outside of IS — something I had hoped for but didn’t really expect. With their support, it has become “required reading” for business representatives on IS projects, which illustrates the importance of management buy-in.

By understanding our audience, I believe that we delivered a corporate data model that not only fits our customer’s needs, but also minimizes the infamous communication gap between the “business” side and IS. Now, if only I could convince my boss that a trip to Disney World would help us keep this model up-to-date!