Browsing articles from "February, 2011"

Cats Give Warnings Before It Gets Bloody

Feb 23, 2011   //   by Rob Drysdale   //   Blog, Data, Fun, Professional Development  //  3 Comments


What do you think of this picture of Annie?  Doesn’t she look cute?  She’s such a tiny cat and looks so innocent that you think you can pick her up and pet her and she’ll be all sweet and nice.  She can be nice and sweet, but she can also be nasty and bite and scratch.  The funny thing is, she turns from nice to nasty really fast.  You can be petting her and thinking everything’s fine, but all of a sudden she’ll turn and hiss and lash out to scratch.  For those that don’t know her and just try and pet her they are surprised when she turns and they aren’t expecting it.  For those of us that know her and have experienced it, we know what the signs are and can see her starting to turn.  It’s in her eyes and the way she holds her head, but if you haven’t seen it before you may not recognize it.

Last week I wrote a blog post called What It Feels Like To Be The Cat and I talked about a specific example of feeling like a cat when you’re in meetings.  In my example, the project team was surprised when I finally did “lash out” in a meeting, but they shouldn’t have been.  Just like Annie does, we all show signs when we are not happy, not engaged, ready to run, or ready to lash out.  We just have to look for the signs.  In Karen’s recent post Herding Cats The Hard Way, she talks about situations where you can be causing your users or project team to act like a cat and want to lash out, but sometimes it happens no matter what you do.  But I think that if we see the signs, we can change our actions and it can keep things from getting too bloody.

I’ll give an example of how this can happen.  Let’s say you’re invited to a normal status meeting where everything seems to have been going fine and it’s a clear agenda of things to discuss.  Now suppose that someone has found some problem that wasn’t on the agenda and it relates to your (or your team’s) work and they bring it up.  Your first reaction internally is an adrenalin rush and you get defensive.  Most of us won’t “lash out” in that meeting as a first response, but if it keeps getting discussed and we’re pushed into a corner it could happen.  But if the others in the meeting are paying attention they can see it coming and defuse the situation.  Think about it, has this ever happened to you? What was your reaction? Did you feel like the cat and want to lash out or run away and hide?

You’re actions and what you do and say are important in your interaction with people.  You can’t deliver the same message the same way with everyone and you have to watch and pay attention to the other person so you can see when their attitude is changing.    If you don’t pay attention, you could be surprised and a bit bloody.

Love Your Data

Feb 18, 2011   //   by Karen Lopez   //   Blog, Data, Fun, Social Networking  //  2 Comments



My friend Michael Swart (blog | Twitter) did this wonderful take on "Love Your Data" for me.  And I….love it.  Not only does it work for our theme, it also is a sort of inside joke for Trekkers.  Do you "get it"?

Check out his blog and his Twitter feed for great content and artwork.

I’ve asked him for another piece of art.  Can’t wait until it is done, too.

What It Feels Like To Be The Cat

Feb 18, 2011   //   by Rob Drysdale   //   Blog, Data, Professional Development  //  1 Comment

Frank as a Kitten

In her recent blog post Herding Cats the Hard Way, Karen talked about trying to herd a cat into a cat crate and that it struck her as being similar to trying to work with business users when you treat them like a cat.  Karen wrote:

The worst part was not being able to explain to Frank why all this was going on.  He had to be treated so there was no question about having to put him through this process.  Unlike a business user, though, we don’t have the opportunity to prepare him for the event with good data, analysis of the cost, benefits, and risks of going to the veterinarian.  He was blindsided by all of this.

All of this made me think of attending meetings where I really did feel like the cat and, like Frank, wanted or needed to lash out.  Over the years I have worked in a number of different areas as both an employee and a consultant and there are times when I’ve been the cat or when I’ve treated others like the cat.  We all know the meetings where someone feels like the cat…the person sits there and doesn’t understand what’s happening, they are reticent and don’t want to participate and they may get really defensive.  All the while, you’ll be sitting there thinking “What’s the problem here? I just want to make it better.”

At one point in my career I managed a contracting organization and a major client hired a system integrator and bought a new ERP system to do their work management.  The system integrator and the company justified this system to the Board of Directors based on benefits or savings and, in fact, the integrator would receive a portion of the savings as part of their contract.  Of course we weren’t privy to all of the information, but they wanted us to participate and tell them we were happy and agree with everything they did.

Frank Snoozing in the SunEvery time we had one of these meetings there was someone in there asking about benefits.   We were okay with that if the benefits were real, but we also foresaw areas where there would be costs associated with using this system.  The integrator and company would hold these meetings, lay out the process, ask about benefits, but never talk about costs.  In fact, when we asked about costs and how they would be handled we were told that was an issue for another group.

Now I can go with the flow and work through a lot of issues, but just like a cat, eventually I’ll lash out if you keep pushing the wrong way.  About halfway through the project we were having another meeting to discuss the process and I talked about how a certain part of the program should be configured.  The IROC sitting across the table with pen poised above paper asked “and what’s the benefit of that?”  My response was “I’m not going to tell you if there’s a benefit or not.”  Everyone in the meeting stopped and looked at me and I said that we would have no further discussions or meetings to discuss benefits until we actually talked about the “elephant in the room”.  The meeting was over.  Then all of the contractors and the project sponsors had to have a big meeting to talk about what we were trying to achieve and how we should work together and that it was benefits net of costs so we got what we wanted, too. 

Just like the cat, there are times when you have to lash out and make it a bit bloody for people to understand that you don’t like something.  We business users don’t want to do that, but sometimes that’s the only way to make certain people listen.

So the next time you’re going into a meeting with a business user, another department, a vendor, a customer, etc. think about it.  Have you been listening?  Have you shown the others that you understand what they want and are working to make that happen?

Herding Cats the Hard Way

Feb 17, 2011   //   by Karen Lopez   //   Blog, Data, Professional Development  //  3 Comments

CostofHerdingcats - photo hands with BandAids

About one hour before a webinar this week we had to get one of our cats to the vet.  This is a nervous cat but we generally can use food and kind words to lure him close enough to put him in a cat crate.

This time he was sick, so he wasn’t feeling well and he was afraid.  That made the whole process take much longer than it usually does, which led to the cat fighting back more than normal. Also adding to the stress was the fact that we had to get him crated and to the doctor at a specific time or lose our appointment. Having a webinar coming up within an hour or so made me more stressed, too.

First Rob tried to get him in the crate with smooth talking as a bit of distraction.  The cat was having none of that. So next he tried it wearing gauntlet-type leather work gloves.  The gloves didn’t even make a difference, Frankie’s claws went right through them.  Next Rob tried padded leather work gloves.  Same effect.  After several horrible attempts , Rob succeeded in getting Frank in the crate.  We had the cat locked in a bathroom with two people and all three of us were miserable.  Both Rob and Frank suffered injuries in the process.

I couldn’t help think of similar situations over my career of being locked in a conference room with project team members and business users with none of us wanting to be there.  We all suffered scratches, bites, and war wounds.

The worst part was not being able to explain to Frank why all this was going on.  He had to be treated so there was no question about having to put him through this process.  Unlike a business user, though, we don’t have the opportunity to prepare him for the event with good data, analysis of the cost, benefits, and risks of going to the veterinarian.  He was blindsided by all of this. 

Every time we have to get a cat to the doctor we have to tailor the process to the individual cat. For one, we could put the crate on the kitchen floor and he’d walk in because he loved being in the crate. For others it involves some kitty bribes and distractions. They don’t like being in the crate, but they aren’t hard to distract. For others, it takes two people, several strategies and a series of missed appointments until we are able to succeed. Those latter ones are the worst – we feel bad, the cat is unhappy and generally everyone gets hurt.

But there are benefits to going through this cat fight.  What Frank taught us about meetings with business users and project teams:

  1. Sometimes you have to go to meetings that no one wants to attend, but you do it because it must be done to keep the project from failing. 
  2. Springing bad news on a business user with no preparation and no supporting evidence is treating them like cats.  It puts them in a much more stressful position and makes them want to fight back.
  3. If all your encounters with others are like crating a sick cat, you aren’t doing it right.
  4. If team members are in a high stress situation, meetings are going to be much more painful than you expect.
  5. Sometimes you have to take the scratches in order to get the job done.
  6. If every encounter you have with business users results in going through a box of bandages, you aren’t caring for your business users enough outside of meetings to mitigate their fears and stresses.
  7. You need the right protective equipment for each meeting.  Sometimes that’s just kind words and some food.  Sometimes it’s a full blown Kevlar protection system.
  8. If you wear the Kevlar to every meeting, though, you are sending the message to the team that someone is going to be hurt.
  9. You need to tailor meeting locations, agenda items and communications styles to the individual business users. 
  10. Everyone in these meetings feels as if they are the cat. 

Karen’s Typical Day

Feb 17, 2011   //   by Karen Lopez   //   Blog, Data Modeling, Database, Social Networking, Speaking, Travel, WIT  //  1 Comment

I used this slide in my recent Webinar sponsored by Embarcadero Technologies.  It’s a collage of photos to represent how it seems I spend my time.



I’d love to see your typical day as you would represent it.  It doesn’t have to be a collage or even have photos.  Just blog your typical day in something other than paragraphs and link to the photo above or leave a link in the comments if you don’t see a track back in the comments automatically.  Include the hashtag #typicalday in the title.

Don’t blog?  This would be a great way to get started. 

I’ll write up a summary blog post of all the submissions, along with my usual witty observations.

Go! Show us what your days are like (or at least what they feel like).

The Repository, Users and Licenses – Clarifying ER/Studio Services

Feb 14, 2011   //   by Karen Lopez   //   Blog, Data Modeling  //  No Comments

In working with Embarcadero ER/Studio (currently branded as ER/Studio XE), I often find that accidental system admins are confused by what appear to be duplicate or overlapping set up steps to get someone up and running with ER/Studio and the ER/Studio Repository.  This is especially confusing if the admin does this only a few times a year or does not have a documented process for setting up accounts.

Before getting into the details, let’s first define some of the terms for this how-to:

imageEmbarcadero License Server: An application that runs on a server for managing the allocation of licenses for users of the ER/Studio suite of tools, including ER/Studio Data Architect, ER/Studio Business Architect, ER/Studio Software Architect, and Schema Validator. If you have concurrent licensing for ER/Studio, you must use the License Server to hand out licenses and keep track of how many are being used.  Other licensing schemes may or may not make use of the License Server.

imageER/Studio Data Architect: The ER/Studio data modeling client application.  This application runs on your desktop/laptop.  Also known as the ER/Studio client.  This is the data modeling tool.

imageER/Studio Repository: An application that runs on a server for managing versioning and releases of ER/Studio Data and Process models.  This is the service that allows you to check out a model and check it back in.



While the ER/Studio client can be deployed without these other services, enterprises typically deploy both the License Server and the Repository to help manage the complexity of enterprise projects.  However, to most modelers, it’s all magic to them: they run their local copy of ER/Studio and all these services work together seamlessly.

So when a user needs to be set up, they may need something to be set up in two locations:

  1. The License Server
  2. The Repository

And that’s where the confusion sets in, as it can appear they are having to set up users in duplicate.  It is even more confusing because organizations can customize how they manage licenses (letting anyone who has network to use a license, limiting licenses to specific machines or login IDs, etc.)  So I’ll leave the exact set up steps for another post. In my diagram above, that license server uses a concurrent user list to manage which machine logins (not ER/Studio logins, but Windows User Accounts)  are allowed to use a license.  Your licensing scheme may be different. 

The reason why users, accounts, or machines must be set up in the License server is that this services provides licenses for each of the ER/Studio suite of tools, not just ER/Studio Data Architect.   It’s also because an organization could deploy ER/Studio clients without the Repository or without the License Server.  They are two different services that can be used independently from each other.

Once an ER/Studio client application has obtained a license, a user can start working with models.  If that user is going to access the Repository, they need to have a login and a password in the Repository application.  Note that this is different than any data that was provided to the License Server.

To set up a Repository Account in ER/Studio Data Architect:

  1. Run ER/Studio client.
  2. Choose Repository from the menu bar, then Security and Security Center


  3. You will be presented with the Security Center window.  Click on the Manage Users Tab.


  4. Add the new User here.  You will want to use your organization’s standards for login IDs and passwords.
  5. Once a User has been added, he can be assigned access to certain projects and diagrams via roles.


Once you have completed BOTH allowing the user to get a license (via the License Server) and set them up with a login (User Account) in ER/Studio Data Architect, they should be ready to work.

1980 Called and it Wants Its Deliverables Back

Feb 13, 2011   //   by Karen Lopez   //   Blog, Data, Data Modeling  //  7 Comments


imageI’ve been doing this data modeling stuff for a really long time.  So long that I just put "20+ years" on my slides…and I’m well past that 20.  However, having done this for a long time does not qualify me as an expert.  What qualifies me is that I know how to adapt my tools, methods and approaches as development tools and methods change.  What worked for projects in 1986 doesn’t necessarily work now. Not only do we have radically more advanced features in our tools, we have many more platforms to support.  We have a greater variety of development approaches.  Our architectures are much more distributed and much more complex than they were in the nineties.

Aerobic Excerise in the mid-eighties I worked in the US Defense consulting business.  The somewhat serious joke was that consultants were paid $1 million for each inch of documentation they delivered.  It didn’t matter what was in the models or whether they were correct; it only mattered how many reams of paper were delivered.  That sort of "all documentation is great" mindset still exists well into 1999, long past its usefulness.   The world has changed and we data architects need to find a replacement for the publication fashion equivalent shoulder pads, thongs, leggings, skinny ties, and lace fingerless gloves.

Those differences mean that the deliverables we produce need to be radically different from what they were in 1999.  Our team members are no longer going to open up a 175-page prose document to find out how to use and understand the data model or database.  They don’t want all that great metadata trapped in a MS Word document or, worse, buried in an image.  The can’t easily search those and they can’t import that knowledge into their own models and tools. 

As much as I don’t want this to be true, no one wants to read or use massive narratives any longer.  Sure, if they are really, really stuck a quick write up might be helpful, but sometimes a quick video or screencast would be faster and easier to produce. If you are spending days or weeks writing big wordy documents, the sad truth is there is a high likelihood that absolutely no one except your mother is going to read or appreciate it…and she isn’t actually going to read it.

I’ve significantly changed what I produce when I release a data model.  I constantly monitor how these deliverables are used.  I look at server logs or general usage reports to continually verify that the time I’m spending on data-model related deliverables is adding value to the project and organization.  The main way I gauge usefulness of deliverables is by how urgently my team members start bugging me to get them up on the intranet where they are published. 

Here are my top 10 recommendations for approaching your data model deliverables:

  1. Get formal, lab-based hands-on training for staff.  Or use staff that are already trained in the tools and version of the tools they are using. You may be missing out on features in the tools that make publishing data models much easier that the methods you are currently using.  I had a client who was struggling to support an elaborate custom-developed application that they didn’t really know how to use or maintain.  It used a deprecated data model format to build an HTML-based report of the data model.  Sound familiar? Almost all tools provide a feature to generate such reports in seconds. 
  2. Move away from very large, manual documentation.   Think in terms of publishing data and models, not documents. Prose documents are costly to produce and maintain.  They do more harm than no documentation at all when they are not maintained.  The are difficult to search, share, and use.  This is not how the vast majority of IT staff want to consume information.  Team members want their data model data (metadata) in a format that is consumable, that can be used on a huge variety of platforms and that is interactive, not locked only in a PDF.
  3. Know how long it takes to produce every deliverable.  Having this information makes it easier for you and your team to prioritize each deliverable.  I once had a project manager ask if cutting back the automatically generated reports could save time for getting data modeling completed. I could show her that the total time to put the documents on the intranet was only about 5 minutes.   My document production data also helps other modelers estimate how long a release will take to produce.
  4. Stop exporting data for features that can be done right in the tool.  Move data model content that is locked in MS Word documents into the models or stop producing it.  Exporting diagrams as images and marking them up with more images means all that mark-up is unsearchable.  It also means that every change to the data model, even a trivial one, triggers a new requirement to recreate all those images.  Modern tools have drawing and mark-up features in them. Cost/benefit of exporting and annotating outside the modeling tool means you’ll always be spending more than your "earn".  You’re creating a data model deficit.
  5. Stop producing deliverables that require a complete manual re-write every time there is a new release.  Unless, of course, these sorts of things are HIGHLY valued by your team and you have evidence that they are used.  I’m betting that while people will say that they love them, they don’t love them as much as getting half as much data architecture work done.
  6. Focus on deliverables that are 100% generated from the tools.  Leave manually developed deliverables to short overviews and references to collaborative, user-driven content.   Wikis, knowledgebases, and FAQs are for capturing user-generated or user-initiated content.
  7. Focus on delivering documentation that can be used by implementers of the model.  That would be Data Architects, DBAs, and Developers.  Probably in reverse order of that list in priority.  Yes, you want to ensure that there are good definitions and good material so that any data architect in your company can work with the model even after you’ve won the lottery, the largest number of people who will work with the models are business users, developers, and DBAs.  Think of them as your target audience.
  8. Automate the generation of those deliverables via features right in the tools – APIs, macros, etc. Challenge every deliverable that will cost more to produce once than the value it will deliver to ever single member.
  9. Move supporting content that is locked into MS Word documents (naming standards, modeling standards and such) to a collaborative environment like a wiki or knowledgebase.  Don’t delay releases just to deliver those items.  Theses formal deliverables are important, but from a relative value point of view, they should not hold up delivering data models.
  10. Focus now on making a process that is more agile and less expensive to execute while also meeting the needs of the data model users.   If it is taking you more time to publish your data architectures than actually architecting them, you are doing it wrong.


While data modeling standards have stayed relatively stable over the last 10-20 years, our methods and tools haven’t.  If you are still modeling like it’s 1980, you stopped delivering value sometime around 1999.


Subscribe via E-mail

Use the link below to receive posts via e-mail. Unsubscribe at any time. Subscribe to by Email



UA-52726617-1 Secured By miniOrange