Why Visio Is Evil

Most of my time yesterday and today has been spent on the mind-numbing task of translating diagrams drawn in Visio into ProVision. PV does have a Visio import feature, and to be fair it does a pretty good job, but Visio just isn't rich enough to give PV what it needs to work with. So I'm doing a crapload of work that is to modeling as transcription is to creative writing.

 

I shouldn't have to do this. I mean, it's my job and everything, but the Visio diagrams were drawn by someone who really should have known better. It's not that the Visio diagrams are inaccurate or incomplete -- in fact, they're quite good; the problem is that they're Visio diagrams.

 

You see, Microsoft Office is the sort of hammer that makes every problem look like a nail. What's worse, everybody has said hammer, and very few are even aware of other tools. Even the hammers get mixed up: project plans appear in Excel, reports get written in PowerPoint, and so on. They're all, in fact, quite good hammers when used on the appropriate nails. But sometimes you need a screwdriver.

 

Hence, Visio is evil. It's evil because it lures systems analysts into producing models that have no value beyond their printed equivalent. The lines, boxes, and so on that comprise the model have no meaning from the software's perspective. They are not, semantically, associations and classes. They're just lines and boxes. They can't be re-used or analyzed.

 

Analysts, hear me: use a real modeling tool like PV or Rose (sorry, I meant IBM Rational Software Modeler). Don't just draw pictures in Visio. Do it right. Let your work have some value.

DAMA DMBOK

Since you're wondering, DAMA is the Data Management Association and DMBOK is the Data Management Body of Knowledge. I discovered the DMBOK last month when I was hunting for a best-practice framework to use as a basis for the data managemnt area of a project I'm working on. The full DMBOK is a work in progress but the outline is available as a PDF. I was quite impressed and I immediately adopted it, though I did have to narrow the scope a bit (read: cut it in half for starters) to fit my project.

Oodles of Models, Part 2

I took a break from work over the holidays -- actually shut off my work PC -- but of course my brain kept chewing away on the matter of metadata metamodels. So, I sat down last night and cranked out the following PV model:

 

The metadata element itself is modeled as a class with the prefix MD_. Within the class is a single attribute whose properties shall be set to reflect the canonical definition of the element. That attribute, if appropriate, can be associated with validating business objects; for example, the ‘Project Number’ metadata element validates against the projectNumber attribute of the Project class (which itself is a canonical representation). Business Object(s) having the metadata element as an attribute are shown simply associated with the element.

I think this approach respects the overall PV metamodel semantics. Of course, I'll have to work with it for a while to make sure.

This afternoon I used this metamodel to model the metadata element set for one of my company's SharePoint-based document libraries. It worked, but I found I spent most of my time defining the design details of the elements because they'd been implemented as static SharePoint LOVs. I think one integration challenge for us will be assigning underlying sources for the LOVs and dynamically updating the LOVs along with the source. I wonder if that's been done...

Anyway, until I get some feedback from my colleagues I'm calling this one done.