Browsing articles from "March, 2014"

What about XP, Agile, SCRUM, Lean…? #EDW2014

Mar 31, 2014   //   by Karen Lopez   //   Blog, Data Modeling, Events, Speaking  //  No Comments

At the upcoming Enterprise Data World 2014, I’ll be doing a half-day presentation on Driving Development Projects with Enterprise Data Models

Here are a few teases for what we will be talking about:

image

image

image

 

The Abstract:

Monday, April 28, 2014
08:30 AM – 11:45 AM

Level: 
Intermediate

Join this session to see how data fits in real-world enterprise development projects. We’ll answer such questions as:

  • "Who does what?"
  • "Why are we doing this?"
  • "Will it slow things down?”
  • “Will it work with agile development?”
  • "Will I have to actually talk to a data architect?"
  • “What about the Cloud?”
  • "What are the biggest mistakes teams make?"
  • "Will I still have a job?"

The session will feature demos of common data modeling-to-database processes, including reverse engineering, forward engineering, generating DDL, alter scripts, and more. You will leave with 10 tips for making model-driven database development successful in your organization’s culture and environment.

Getting Cosmos Data From the Source

Mar 21, 2014   //   by Karen Lopez   //   Awesome, Blog, Fun, Space  //  No Comments

20140321-194352.jpg

Me: Hi, Neil, I’m Karen

Neil: Hi, Karen….

5 Classic Data Modeling Mistakes…And How to Avoid Them

Mar 12, 2014   //   by Karen Lopez   //   Blog, Data, Data Modeling, Speaking  //  No Comments

Slides from my frequent DAMA / Enterprise Data World presentation on Data Modeling mistakes.  You can click on the stopwatch in the player to auto-advance the slides.

There’s no sound; these are just the slides. If you’d like attend a presentation on this topic, ask your local user group (DAMA, ERwin, PASS, etc.) to invite me.

Data Modeling is Iterative. It’s not Waterfall

Mar 7, 2014   //   by Karen Lopez   //   Blog, Data, Data Governance, Data Modeling, Database Design, DLBlog  //  7 Comments

Sure, data modeling is taught in many training classes as a linear process for building software.  It usually goes something like this:

  1. Build a Conceptual Data Model.
  2. Review that with users
  3. Build a Logical Data Model
  4. Review that with users
  5. Build a Physical Data Model
  6. Give it to the DBA
  7. GOTO step one on another project.

And most team members think it looks like this:

image

Training classes work this way because it’s a good way to learn notations, tools and methods.  But that’s not how data modeling works when the professionals do it on a real project.

Data modeling is an iterative effort. Those integrations can be sprints (typical for my projects) or have longer intervals. Sometimes the iterations exist just between efforts to complete the data models, prior to generating a database.  But it’s highly iterative, just like the software development part of the project. 

In reality, data modeling looks more like this:

Data Model Driven Development - Karen Lopez

This is Data Model-Driven Development.  The high-level steps work like:

  1. Discuss requirements.
  2. Develop data models (all of them, some of them, one of them).
  3. Generate Databases, XML schemas, file structures, whatever you might want to physically build. Or nothing physical, if that’s not what the team is ready for. 
  4. Refine
  5. Repeat.

These, again, are small intervals, not the waterfall steps of an entire project.  In fact, I might do this several times even in the same sprint. Not all modeling efforts lead to databases or physical implementations.  That’s okay.  We still follow an iterative approach.  And while the steps here look like the same waterfall list, they aren’t the same.

  • There isn’t really a first step.  For instance, I could start with an in-production database and move around the circle from there.
  • We could start with existing data models. In fact, that’s the ideal starting point in a well-managed data model-driven development shop.
  • The data models add value because they are kept in sync with what’s happening elsewhere – as a natural part of the process, not as a separate deliverable.
  • The modeling doesn’t stop.  We don’t do a logical model, then derive a physical model, throwing away the logical model.
  • Data  modelers are involved in the the project throughout its lifecycle, not just some arbitrary phase. 
  • Modeling responsibilities may be shared among more roles.  In a strong data model-driven process, it is easier for DBAs and BAs to be hands-on with the data models.  Sometimes even users.  Really.

By the way, this iterative modeling approach isn’t unique to data models.  All the models we might work on for a project should follow this project.  Class diagrams, sequence diagrams, use cases, flow charts, etc. should all follow this process to deliver the value that has been invested in them.  That’s what Agile means in “the right amount of [modeling] documentation”. Data model driven development means that models are “alive”.  

If you are a modeler and re-enforcing the wrong perceptions of needing a waterfall-like approach to data modeling, you are doing it wrong.  You might be causing more pain for yourself than anyone else on your project.

Data Models aren’t just documentation checklist items.  They model the reality of the living, breathing systems at all points in its life.  They deliver value because they are accurate, not because they are “done”.

Data Management Career Success…in Turbulent Times

Slides from my frequent DAMA and Enterprise Data World presentation on data management career success.

I Welcome You All to Cloud Cuckoo Land! #NoSQLKitty

Mar 5, 2014   //   by Karen Lopez   //   Awesome, Blog, Data, Fun, NoSQL, Parody, Snark  //  1 Comment

I introduce to you, NoSQKitty

 

image

With this dialog, I had to do this. I had no choice, really.  Trust me. Just ask Biznis Kitty.

Emmet: I’m just gonna come right out, I have no idea what’s going on or what this place is at all.
Unikitty: Hi! I am Princess Unikitty, and I welcome you all to Cloud Cuckoo Land!
Emmet: So there are no signs or anything. How does anyone know what not to do?
Unikitty: Here in Cloud Cuckoo Land, there are no rules. There’s no government, no baby sitters, no bedtimes, no frowny faces, no bushy moustaches, and no negativity of any kind.
Lucy: You just said the word "no" like a thousand times.
Unikitty: And there’s also no consistency.
Batman: [the clown and the lizard man are dancing around him] I hate this place.

Every single line in that scene had me choking on my popcorn.  There’s a blog post in each one.  No rules? Nope, not in schemaless.  No signs? Nope.  No bedtimes? Nope, none. As a matter of fact, I want to make up t-shirts with each of these lines. Everything is Awesome about them.

I’m not anti-cloud, at all.   Nor am I anti-NoSQL (Hey, I know that’s a double negative.  Don’t blame me that the name NoSQL seriously needs rebranding.)    Plus, with a Starbucks name of Kitty, this is *so* my character.  Cloud Cuckoo Land and all.

*And I really do get what eventual consistency is all about. I know it means there is consistency. I know when it’s perfect for solving a problem.  I’m just quoting Unikitty.  Blame her.  But watch out for Angry Kitty if you do that.

Subscribe via E-mail

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


Categories

Archive

UA-52726617-1