Using SID Patterns

Back from vacation and then off the next day to Bonn, Germany last week to conduct some SID training.  So I thought it would be good to switch from the eTOM to the SID in this edition of the blog, based on an my experience with some students that knew UML but were not practicing information modelers.

But, before I get into the details of using SID patterns, I know I have a responsibility to chat a little about my culinary experience.  Being of part German descent on my father’s side, my grandmother’s maiden name was Huppman and she introduced me to many German delights, I was back in heaven.  There is nothing like some sauerbraten and potato dumplings to remind me of her!  And I was surprised to find quite a few Italian restaurants, so I had to finish my trip with gorgonzola gnocchi combined with an excellent German dark wheat beer.  And, rather than eating alone, which I typically do, I had some of my instructor pals with me, Andy (also known as Andrew or Drew… hmmm, seems like an identity crisis or something sinister) Chalmers, Josh Salomon, and Ivan Gramatikoff, which was an addition treat.

During the SID Modeler’s workshop I was also in for a surprise that occurs often when the class is made up of students who do not practice information modeling as part of their day-to-day jobs.  So, I guess I shouldn’t be surprised.  But, not let me digress.

The training started with SID Distilled, which includes explaining the patterns used to model a good part of the SID, along with the business requirements that the patterns satisfy.  The patterns are the Entity Specification / Entity, Composite/Atomic, Entity /Entity Role, Business Interaction, and Characteristic Specification / Characteristic Value.

Armed with these, the students were provided a business scenario and, as a starting point to represent the requirements as an information model, were asked what patterns could be used.  They started by listing the information requirements and then checking off the possible patterns that could be used to model the requirements as shown below.

Once these were agreed upon, which didn’t take much time, the next step was to construct the model as shown below, which was quite easy to do.

What does this say about using modeling patterns?  First, without patterns non-modelers would be faced with a real challenge on where to even start.  Even experienced modelers would come up with different representations of the requirements in the resultant model, if not given the patterns that can be used.  It’s about consistency.  Given guidelines, such as these, along with other SID modeling guidelines, the resultant model arrived at by different modelers will be quite similar.  What’s the benefit?  Arriving at similar models means that these extensions/additions to the SID developed by different software vendors can be easier to integrate.  Additionally, the extensions/additions easily adapt to new requirements.

I’ll be off to the Baltimore Team Action Week next week and then off to do the London Training Road Show the following week.  But, hopefully, I’ll have some time away from the pub and bangers and mash to do a blog from there.