Response to Design Challenge #6 - Taming the wild west modeler

So how would you respond to the Wild West Modeler?

In this design challenge I really enjoyed reading how everyone felt towards this Wild West modeler. That is, which respondents wanted to promote him, which wanted to sentence him to 20 years in Siberia, and which were somewhere in between. I have the feeling that a majority of us have been in somewhat of a similar situation in the past.

Before we get started with the questions, I mentioned in my last design challenge that we will randomly pick one person who responded to the design challenge to win a special prize. I take all of the names of people who submit responses to each design challenge, write them on little pieces of paper, and whichever piece my daughter Sadie picks up first will win the prize! If Sadie picks up more than 1 piece of paper, the first one she puts in her mouth wins! For this design challenge we had a large number of entries…and the winner is….drum roll please...Frank Palmeri!

 Congratulations Frank and your prize is on the way. Here is a picture of Sadie picking the winning piece of paper.

Ok, back to the design challenge. I mentioned this is a real situation in our company and Ulrich is my counterpart in Germany who is wrestling with this and has not made a decision yet on what to do. One of his major inputs to making the decision is to read your responses to this challenge. He offered the following 4 initial options or categories in an email to me (note in his email I substituted “Wild West Modeler” for modeler’s actual name in this email to protect the innocent…or to protect the guilty :))

 I see the following alternatives to move this forward:

  1.  Not considering the Wild West Modeler’s current model as being a [valid corporate model], but just using this as a source for Steve's Enterprise Model. I don't see a real issue with this, because the "Enterprise Model" is on another level of detail and will not pick all Subject-Areas from the XYZ Model anyway.

  2. Us to rebuild the model by interviewing the Wild West Modeler. This would significantly change the structure & complexity of the model…however he may not use it, but continue with his current "technique" without keeping us in the loop on this.

  3. Pause the debate and letting the Wild West Modeler know, that after he has completed the Data Definition work, we'll revisit this topic.

  4. Have a session with him requesting a proper "Business Data Model" and explaining him the motivation behind it. We may need to involve upper management in such a session.

 So to summarize these 4 from Ulrich’s email, we can either let him continue with his work, we’ll continue with ours, and not synch the two together (Option 1). We can change the corporate view (Option 2). We can postpone the decision (Option 3). We can force him to change his model (Option 4). Or some combination of these. Or maybe new options we didn’t consider.

Here is what our readership felt (in alphabetical order by contributor). Note that we are getting increasingly more responses from each design challenge (which is a good thing!), so I’ve needed to summarize comments in some cases to keep the total length of this challenge manageable:

 ALSO NOTE before you begin reading these: When you get to Ben Ettlinger’s comments, try to guess how many Mars product names he used in his response. How did he know we make all of these products? Pretty ingenious I think! :O)

Cheim

My solution would be to approach the Corporate Model and his with equal consideration and perhaps make a better model in the outcome - Using the Corporate approved modeling tool and regulations.  I would include your Renegade modeler in the process so he becomes familiar with your approach, tool, and constraints in the future.  This would help him 'think' in your language in the future as well as still offering him ownership in the new product. If you can accomplish this with finesse, you may get an ally and ‘promoter' for life. 

Chid

First, I would feel thrilled that among the user group there is an advocate in  modeling.  Trite as it sounds, as modelers we are faced with a daunting task of convincing why models are important before coding is even thought of. Having a user speak for us is an asset. So I would never, in my wildest (west!) dreams do anything to upset him/her. I would encourage them to do the model the way they think fit and actually "create avenues and opportunities" to exchange ideas. In one of these situations/meetings I will emphasize the need to have a corporate standard and will take pains to explain to him that all his ideas will be incorporated and due credit given to his/her team for helping us get those ideas off-ground into a model.

Two outcomes can occur:
1. The user is really convinced (that is the key, there should be no pressure) and buys into the idea. Both parties win.
2. The user mocks at the idea. I will then move the discussion to a slightly non-technical angle and talk in terms of the impacts of using his/her model - maintenance issues, ownership, reuse and "fit"  into corporate model.  If this does not work, it becomes imperative to involve other decision makers up the hierarchy for their call.

Ben Ettlinger

Obviously this depends on the corporate political climate. Uncle Ben says you could Snicker at him and say no way it just doesn't Klix with our enterprise model, then Skittle his model, tell him he's from Mars, and assign him to be the corporate Flavia brewmaster. You could let him just go on his own Milky Way and do his own thing, throw him a Malteser and let him think he model is great but ignore him. On the other hand you could really be caught beTWIX and between if the guy is a big political Starburst.

Seriously, the really Milky Way is the middle road. Sit down with him and see what his thinking is about, if it makes sense incorporate his ideas into the corporate model, or at least some of them. The user can bring great business value to a model, especially when it comes to incorporating business rules, where possible. Explain to him that two tools would not work and that the company tool of choice is what you are using. (Expect of course if he is using Erwin and you aren't. Then I would say, hmmmm good choice we'll switch. :) :) 

If everyone takes the "I" & the "Me" out of the mix, and considers the good of the company, the middle road will work…..How about a new product I & Me trail mix…………...

Gordon C. Everest

We must assume that the "key business user" understands application XYZ…That expert knowledge you want to capture.  Looking at their data model for XYZ is the opportunity and vehicle for doing that.  First, we must look beyond the syntax (notation) of their model and the tool used to produce it, and focus on the semantics of their model.  I would expect their model to include some semantics which are not in the central corporate model.  Those need to be understood, captured, and added to the corporate model.  When there are differing or conflicting semantics, the XYZ expert and the central data modelers must attempt to reconcile their differing semantics, based upon a shared understanding of the domain being modeled.  Such a shared understanding evolves from dialogue.  The objective here is to produce a better, improved corporate data model of XYZ application.

Scot Fearnside

Be supportive and listen to why the key business user designed the model that way, you may learn something about the business that was not evident before. Try to convey the need for standards and invite the person to help correct any flaws in the company owned model. Try to get them to feel some ownership in the newly revised company model.

Venkat Iyer

Would allow him to create his own model, as long as it is derived from the original XYZ model. I wouldn’t let him physically implement his model in terms of tables and databases, but would logically create views on top of the XYZ model in order to give him “his view” of the business. This way, the “organizational data” is intact and the “wild west” modeler is also the last man standing. As long as he is a valuable business user and knows what he is doing, we, as data modelers need to ensure that we provide him support to get to his data (after all he is the user that increases the company’s business!) , while ensuring that the integrity and consistency of the organizational data is not compromised.

Linda Kilbourne

I wouldn't want to discourage anyone who is so interested in data modeling that he went out and created his own model!  But, it doesn't benefit anyone to have two conflicting models of application XYZ.  I would try to harness the wild west modeler's energy and use it for good.  Since he is a key business user from application XYZ, I'll assume that his ideas for the XYZ model are valid.  If that is indeed the case, I'd meet with him to discuss his ideas (pick a meeting subject other than 'Gunfight at the OK Corral'!) and incorporate them into the existing company model of XYZ where applicable.  At the same meeting, you can thank him for his enthusiasm and share with him the company philosophy and modeling standards so he understands the importance of having a single modeling source.  If that doesn't work, by all means have him transferred to somewhere with 11 months of darkness!

Jeff Lawyer

Because your business partner "takes modeling seriously and is a strong advocate for this type of modeling", I would do little to discourage his activities.  Using your assumed authority, I would gingerly convert him over to the official, standards-compliant data modeling tool (perhaps by example and display of benefits of integration with other data models)….If you have a data ownership / stewardship program, consider this business partner as a strong candidate for representing his domain of data. Again, this is another opportunity to have him share responsibility for a data subject which spans multiple organizations and can not be relegated to only one organization for data ownership / stewardship. In actuality, you have a quite envious "problem" -- a business partner who gets as excited and is as passionate about data as you are!

Susan Lockhart

I run into this all the time.  For the sake of political correctness, expedience and decency, plus the fact that you never know who you'll be working with/for in the future, here's my approach:

  • Get the wild west modeler a copy of the accepted tool.  Any good modeler can use any tool.  If he's as good as he thinks he is, he can effectively use any tool or notation with little, or in most cases no, training.  And any training required can be self taught…If budgetary concerns prevent the wild west modeler from having the accepted tool, let him use whatever tool he likes and script up his models so they can be reverse engineered in the accepted tool.
  • Make the wild west modeler feel like part of the team.  Give him stuff to do, such as documenting his variations (make sure he captures the whole data dictionary), assign him as a data steward or as part of any data steering committee you might have.  If you don't have a data steering committee, ask him to head one up.  If this doesn't discourage his wild west behavior, I don't know what will. 
  • Best part:  next time a wild west modeler comes forward, ask the previous guy if he'll contact the "newbie" and gently explain what the enterprise standards are and why they are important, and make sure the new guy has all the right tools and logins. 

Manish

I will choose the option of reconciling his model to the corporate model. Data models are dynamic is nature but have strong underpinning requirements of standardization. It may be that the Wild Rider has his own perspective of looking at things, but it can be really possible that he is saying the same thing as said in the Corporate model, but in a different way. Encouraging scrapping of corporate model will make chaos, some other wild west rider will have his own notions and then the whole cycle will begin again. Unless there is a fundamental change perceived by the user, the corporate model should not be changed.

Frank L. Palmeri

…I'd say he's a good guy to have around. He obviously is coherent enough to know the value of a good model, he just needs to get on the same page with everyone else. I'd work with him, and who knows: maybe some of his changes have some merit.

Eric Wilson

Although transferring him to Siberia is very tempting, here are things I would try:
Assuming the company has a person or group responsible for the corporate data model, I would require that the rogue modeler gather and present his model, and specifically illustrate how it is different and the reasons for the deviations. (In other words, he must illustrate that he understood the corporate model and deviated consciously and not just because he's a renegade.) Then, the corporate data stewards should take this new model and its deviations and determine, on a case by case basis, whether the new model presents a better, evolutionary model portion, or whether the corporate model remains preferred. Then, alignment should occur. For some elements, this may mean extending the corporate data model with ideas from the rogue model, and in all other cases the rogue model should be revamped to align with the standard. So I guess my point is that the corporate standards should grow with and honor valuable work wherever it lives in the enterprise, but by the end of the effort, there still should remain one corporate data model and the rogue development should align with it. 
 

Need a refresher of this design challenge? Please click here