Of CRUDs and CUDDLs...

 

Back early on in my career as I moved from a programming role to an analyst role, I was fortunate to be funded for training by the utility company I worked for at the time.  The training was conducted by Tom deMarco of Ed Yourdon and Associates, and had to do with analytical techniques, dubbed structured analysis - mainly data flow diagramming (DFDs), and data structure diagrams (DSDs). DSDs fell by the wayside, but DFDs served me well over the years.  The basic premise was to model a clien'ts environment using sources, data flows, processes, data stores and sinks. These fanciful terms could be used in diagrammatic form to describe the "current physical" and "current logical" environments and then the "future logical" and "future physical" environements.

There were many rules and methods one could employ, such as "structured english" to describe processes, and ensuring that a process transformed the input data flow into the output data flow.  We learned that if the output data flow was the same as the input data flow, well then, there was no process at all, was there? And if there was something in the output data flow that was not input to the process, there was something awry with the process. Data flows represented data in motion and data stores represented data at rest. With all that flowing going on wasn't it thoughtful of Ed and Tom to give data a break now and then?

At the time, I was a young buck looking for the silver analysis bullet to help advance by career by doing a stellar job, and I thought this was the ultimate way to model current state and describe future requirements.  It worked very well over the years, and still does, for that matter, although I have to admit I may have become somewhat less rigid about applying Ed and Tom's rules.  

After a few years with the utility company, I moved half way across the country to join an oil and gas company. I learned about data analysis from a company called LBMS, which if memory serves, stood for Learmonth Burchett Management Systems, a company from London, England.  What they were doing in Houston is anyone's guess.  

Like the process modeling I learned about from Ed and Tom, in data there were both logical and physical aspects.  I came to the conclusion that data at rest was actually far more important than data in motion, and became somewhat of a data zealot, tossing aside my previous process modelling soapbox for a new data modelling podium, waxing eloquently (well, maybe just waxing) about logical data models, entities, attributes, relationships and obscure things like fourth normal form.  A slightly older buck at that time, I moved into the realm of data management, database administration and data-driven applications development, even helping to develop a tool that would generate code from a data dictionary based on data entity types and their attributes.  We called it the prototype system, and it was truly impressive (if I may say so myself), generating a menu structure with "CRUDs" for each entity type (Create, Read, Update, Delete).  We didn't get as far as generating reporting modules for each relationship between entities in the data model, but we could have.  A colleague I worked with subsequently insisted on calling these generated modules CUDDLs, not only because we added list functionality (hence the L) allowing the display all instances of the Entity, sorted in multiple ways as desired by the user, but also because CUDDL sounds a lot nicer than CRUD.  I have to agree. Go ahead - pronounce both and decide for yourself.  

I have seen and used many more modelling techniques over the years including use cases, user stories, affinity diagrams, and so on. I am glad to see a mix of both the old and new techniques in current materials, such as PMI's newly minted Business Analysis for Practitioners: A Practice Guide, which you can still download for free at pmi.org.  

So what is the message?  A guess there are a few.  Realize that many modelling techniques are necessary to do a good job in your analysis role - so learn many of them. If you must be a zealot about something, choose modelling. Don't choose a specific hill upon which to die. It's not a war, and there are many hills worth saving.  

Now, does anyone know what you call a ... shall we say ... seasoned buck?