Posts From This Author
About Our Authors
Wanted: Generalist. Deep Expertise Required.
By Alec Sharp on March 23, 2010View Full Bio →
Hi everyone. This blog is a bit late because I was busy last week at Wilshire Conference’s “Enterprise Data World 2010” event in San Francisco. It was the scene of much tweeting using the #EDW10 hash tag, so if you sign on to Twitter and search on “edw10” you’ll be rewarded with a full account of a terrific event.
At the conference, I was surprised (and pleased!) to be awarded the DAMA 2010 Professional Achievement Award. In case you aren’t a member yet, DAMA is the Data Administration and Management Association, at www.dama.org. The award was apparently to recognize that I always insert a data modeling / data management perspective into consulting and speaking engagements, even when the topic at hand is something quite different. That was the topic of my last blog on “Gorilla vs. Guerilla Modeling” so let’s continue in that vein.
Wanted: generalist. Deep expertise required.
The blog stated a couple of important principles underlying successful “guerilla modeling:”
1. The participants didn’t know they were data modeling, because I didn’t tell them and didn’t use the term;
2. I didn’t have to convince anyone to attend a data modeling session because that’s not what it was; usually, I was doing “data modeling by stealth” within the context of a session that had been arranged for some other purpose.
The catch is that you aren’t going to be asked to run one of these sessions if your only known skill is data modeling. That’s where being a generalist comes in – you need to have other skills in addition to data modeling. Almost all of the well-known data modelers I’m familiar with have significant expertise in other areas, and therefore opportunities to introduce data modeling in other settings. The obvious skills are being a DBA, or working in BI or analytics, but I can also think of data modelers with significant expertise in SOA, business rules, facilitation, specific industry verticals, application requirements/business analysis, or business process management (BPM.) In my case, the three areas I’m most often asked to assist with are business process change, application requirements, and general facilitation. I’ll devote a future blog to the role of data modeling in the business process field, so for now let’s consider a couple of examples from the other two areas.
1 - An application requirements example
Several years ago, out of the blue, I got a call from a plant manager at a large manufacturing company. “Could you come out and do… that thing you do?” was his question. “Ah, I suppose so,” I answered, “what thing exactly did you have in mind?” After some back and forth, I realized he was referring to some “stealth data modeling” I had done a few years before while conducting requirements determination sessions for a purchased application. He didn’t realize we’d been data modeling, but what stuck in his mind was that after a couple of sessions “we all shared a far better understanding of our business than we did before.” As dictated by their CEO, they were about to embark on an SAP implementation and he had the feeling that if we did “that thing” for this project it would be very helpful. The SAP consultants thought this was a terrible idea, which was all the incentive I needed to hop on a plane and lend a hand.
Very briefly, what I did was help them identify and define the “things” that they needed to manage, determine how they related to one another, and state some of the important assertions (rules) currently governing them. Along the way, I gently introduced some data modeling terminology and let them know that what we had produced was an “as-is” data model plus some rules. Next, we identified what they liked and didn’t like about this as a guide to configuration of SAP. Of course, it was also important how the SAP modules wanted to do things, but my clients started with a holistic view rather than a hodge-podge of unrelated requirements in the dreaded bulleted list.
After three days of this, my part was done and I flew back home while my client carried on as a project manager on the implementation. Years later, after the company had become a showcase SAP account, I heard that the plant manager referred to those three days as “the highest value part” of their entire SAP journey. Not a bad testimonial for some stealth data modeling, eh?
2 - A facilitation example
I started working on my facilitation skills close to 30 years ago when I was running subject area data modeling sessions at large companies. I quickly learned that if you’re known as a facilitator, you get asked to help out on all kinds of interesting initiatives. I’ve facilitated sessions for strategic planning, problem-solving, sales planning, and all sorts of other things. This was also when I started to realize I was doing more to advance data management when I was working outside the field. Simply helping clarify terms and definitions, which is the very heart of data modeling, is highly appropriate and useful in many kinds of sessions.
A favorite example came up when I was asked to facilitate a task force looking at some problems in a UK justice system. Early in the first session, I innocently asked if the group could help me out by answering a simple question – “What actually is a case?” The immediate reaction was amazement that I had been flown over “from the colonies” to ask a silly question like that. I persisted, and you can all predict what emerged – fundamental disagreement among the participants (police, prosecution, forensics, …) about the definition, which set the stage for the development of a very useful conceptual data model. They also agreed that perhaps it wasn’t a bad idea to fly someone over from the colonies to ask silly questions.
Wrapping up
At the EDW conference last week, I overheard a globally-known industry analyst (whom I greatly admire) state that “data modeling is a dying career.” I was stunned, but, after hearing a bit more, I could see his point. He didn’t say data modeling was a dying skill – far from it – but he did imply that for most of us, it isn’t enough to build an entire career on. If you haven’t done so already, I hope you’ll use this as incentive to get started on adding another core skill to your personal portfolio. It will be good for your employment, and it will be good for data management.
Follow all Expert Blog updates by subscribing to the
RSS feed.
About the Author
Alec Sharp has managed his consulting and education business, Clariteq Systems Consulting Ltd., for close to 30 years. Serving clients from Ireland to India, and Washington to Wellington, Alec has expertise in a rare combination of fields - data management, business analysis, business process improvement, and enterprise architecture.
Glad I’m getting in at the beginning of this series, because I’m gonna want to read them all…
December 31, 2010
A few observations and questions:
My data modeling/ DBA experience has been that I was better received when modeling with business people then with developers. Developers seemed to have a different mind-set than data modelers. I have not been able to understand this conundrum. Any ideas?
Why do you think, after 30+ years of formal data modeling positions in corporations that we (data people) feel we need to operate in ‘stealth’ mode? If non-data people (developers included) can relate to business processes (rules, etc.), why can’t they relate to data (rules, etc.)?





















March 26, 2010