At Nielsen Media Research (NMR), the Core Business Architecture group recently completed a project to evaluate where systems support business processes poorly or not at all. Our first challenge was to determine the format to use in capturing the information.

Typically, this would be text documents or spreadsheets, much like requirements are often documented, along with data and process models. Having used such approaches many times before, we knew the frustration of managing multiple artifacts and trying to do an analysis from them. Instead, we decided to boldly go where we'd never gone before and incorporate all the information we discovered and derived into a single model that would serve as our source of project knowledge and provide ongoing benefits after the project ended. We chose a model, rather than another kind of artifact, because of the graphical component and PowerDesigner's extended object capability. In fact, it was the latter that started us thinking in this direction. I'll take you through the steps and methods we used to develop a new, or extended, model type. They are applicable to creating any kind of model, for any purpose. Next, I'll give a brief overview on how to use PowerDesigner's extended object capability and extend standard model definitions by creating your own object types. In conclusion, I'll share my thoughts on the usefulness of traditional IT models and how modifying them yields more information, more rapidly, with greater flexibility and ease of management, which lets us support and respond to business needs better.

So, we knew we wanted to use a model to collect all the project information. There are three major decisions to make. First "What kind of things do we need to capture?" The answer to this will depend on the nature of your project. For our project: processes, resources, pain points (the mismatch between system and business process), interviewees (who told us about the pain), project action (out of scope, IT addressable, business addressable), initiatives (wide scope work efforts to correct the root causes), and business needs (as opposed to what it's getting from systems). The last five are certainly not standard; they were specific to our project. No object types exist to capture that information, but we could create them using the Extended Object capability in PowerDesigner. This ability is key to creating new kinds of models. Simply putting a graphic symbol on a model diagram with, maybe, a text box property is in no way sufficient. New object types must have a full set of properties and collections like standard object types. Since it's impossible to imagine what object types you might have to create, it's impossible to imagine what object types you might want to relate them to. Therefore, they must have the capability of being related to all other object types, standard and created. In short, they must be as robust as the standard types.

Second decision. "What type of model will support our needs?" The type of model you decide to use as the basis for your custom model will again depend on your specific needs. Our thoughts went like this. Data model? No, our focus wasn't modeling data, although we would be identifying information entities. Process model? The business process was established and process re-engineering was beyond the project's scope. UML diagrams in an object-oriented model? We needed to see where business processes weren't properly supported by systems. None of the numerous UML diagrams would show us that. Free model? No. We don't want to have to create everything from scratch and some of the object types were already defined. Clearly, a new kind of model was called for: a Business Process and System Assessment model. Only that type of model didn't exist. Rather than invent a new model type from scratch, we decided that since we were gathering information related to business processes and systems (resources), we would start with a process model since it includes those object types and modify it to meet our needs by creating the object types listed above.

At this point we knew the information we needed to capture and we had identified a means to do it. Third decision. "How do we communicate what the new object types are, and how do we show the relationships between all object types?" To answer this one, we created a meta-model to define the relationships. For this, we used a PowerDesigner conceptual data model (cdm) since it enabled us to show optionality and cardinality. (Our BArc group routinely uses cdms to develop meta-models.) If you lean toward skipping this step - don't. Don't skip the documentation. You may know how the object types relate, but you're going to get tired of explaining it again and again as people try to visualize it. Put the information in a meta-model: define the object types, make sure you state the optionality and cardinality, and use explanatory role names on the relationships (omitted in the diagram below for readability's sake). I strongly advocate extracting the relationship statements out into a text format so that people don't have to be model gurus to understand them. You can write a VBScript to do this quite easily. (I'll have more to say on this subject later.) Put them in a text box on the diagram. It's much easier for someone to read the English statement, "A pain point must be associated with at least one and at most n interviewees," than to interpret the diagram symbols.

As you can see from the meta-model (see Figure 1), we ended up with more "new" object types than ones that are standard to a process model. By extending the model, we were able to capture all the information necessary to determine where systems supported business processes poorly or not at all in one place. We knew - and could visually see and communicate - what processes had pain, what that pain was, the root cause of the pain, what the business needed (as opposed to what they were getting), how we were going to deal with the pain, and a list of less than 10 initiatives that would address all the pain points. Pretty good for one model.

Once you reach this point, it's time to actually extend the model. Any kind of PowerDesigner model can be extended in the same way. Under Tools > Resources, create an Extended Model Definition for the type of model you're extending. You can do this with the model open or not. This is a separate file, with a .xem extension, that can be saved anywhere and will contain the new object types that you define. At this point, it's an empty file. You can create new object types when you create the definition or after you've linked it to a model(s). To link the extended model definition to a model, open the model and go to Model > Extended Model Definitions. Select Import an Extended Model Definition and browse to the .xem file. Opting to share the file lets multiple models use the same definition and insures that all changes to it are picked up. Copying it into the model does just that, but no connection is maintained to the .xem file. Any future changes to it won't be known. Since we had multiple people who would be working on the model, we elected to use a shared definition so everyone would be working with the same set of objects.

Opening the extended model definition's property sheet (see Figure 2) lets you create new object types as well as stereotypes of standard object types. From the Profile context menu (right-click on Profile), select Add Metaclass. You'll see two tabs: one with object types common to all PD model types and one with object types specific to model type. To create a new object type, select Extended Object. Each new object type is going to be a stereotype of the Extended Object. To create one, select Stereotype from the Extended Object context menu. You can elect to use your new object type as a metaclass. If you elect to do so, objects in the browser tree will be grouped by type, then by name. Personally, I don't find that useful, especially since you can go to Model > Extended Objects and sort by stereotype or apply a filter to show a specific stereotype. When you have more than two or three stereotypes of Extended Object and more than five or six instances of each, it's painful to look through the list and find the object you want using the browser tree, especially if you don't already know its stereotype. Of course, the corollary is that if you use created object types as metaclasses, you can go to Model > Extended Objects and sort by name without regard to stereotype. Two approaches same result. Using Categories (which act like folders), you can organize created objects in the extended model definition. Since we knew we would have sub-types for some of our new object types, we created separate categories.

Now for the fun part! Here's your chance to be creative. There's no button on the palette for Extended Object because, except for the free model, it doesn't appear in a model by default. Sure, you can create one from the model's context menu in the tree structure then open its property sheet and select the stereotype there but why not create a toolbar button for the stereotype? You'll need to have the graphic you want displayed on the toolbar in a .ico or .cur file. There are a number of freeware programs that will import varying graphic file formats and save them in these formats. They'll also let you create your own symbols. A search of the Internet should produce several choices. Select the Palette Custom Tool box then browse to the desired .ico or .cur file (the middle button next to Icon:). The symbol appears in the leftmost box. You can display the toolbar with the custom buttons by going to Tools > Customize Toolbars.