Beyond the Monkeys, Information Usability in Application Development

May 20, 2011 Leave a comment

Following the third UAT session on the same application user interface, one of my business counterpart shared a song he heard on the radio during his drive called “Code Monkey” by Jonathan Coulton. It is funny and was worth my $.99 cent investment to check it out. How do we ensure people are not just good developers against specifications, we discussed, but also create a culture where developers really seek to understand the information delivered through the application so it makes sense.

Web sites, followed by mobile applications, put increased emphasis on the User Experience. Do the screen flows make sense? Are the fields, placement of information intuitive? Google search site’s simplicity is often given as an example, as well as the single button and swiping motions of an iPhone.

What about the information we deliver through the apps? Even with the emphasis on the User Experience, many developers still do not focus on data content, perhaps trusting what is in the database must be enough to meet the need or if a business/user representative asks for something, it must not be questioned.

20110520-041519.jpg

Somehow, it feels like we lost either our curiosity or confidence to look at the results our work produce and ask if what we see makes sense. This seems especially pervasive in reference and master data constructs, where standardization or understanding of common records or semantics require dialogue and are are essential to analytics. Applications that pass system testing per spec yet raising data content concerns by users during UAT both raise cost and delay delivery of value. I believe we need to re-embrace our curiosity.

I am fortunate to have a team of individuals, whether developer, analyst, or tester, that seek to understand what our partners and customers are trying to achieve and question if the specs or code are appropriate. Today, we take a few hours away as a team for a mental break, and have found our new team T-Shirt that embodies a fun philosophy for it. “Input no Evil, Process No Evil, Output no Evil”. Gone are the monkeys of the past. We are responsible for the success of our computing are environment.

Cheers

Mentioned Above, intended for humor or to provoke thought
Wise Robots shirt by SF Bay Area artist Cody Vross
Code Monkey song by Jonathan Coulton

Filed under Data Management Tagged with , ,

Saying Yes!! (or at least Maybe) to NO SQL

May 13, 2011 Leave a comment

Since the beginning of this year, the amount of chatter around the “NO SQL” (Not Only SQL) topic has increased. EDW conference seems to have made more people aware and whether on LinkedIn or other forums, there is a health amount of information exchange going on.

  • Some are excited about the possibility of a new way to analyze data
  • Others think this would make data quality management even more difficult

I think both groups are right. I also think it wouldn’t necessarily make data quality management more difficult, but make the challenge more obvious.

Where we all seem to agree on is the need to understand what the different tools are and the core strengths of different approaches. I think as a data profession, we need to be personally accountable to understand what can offer value to our colleagues and customers, and even if we don’t have a lot of time for research. I fundamentally believe that even if I don’t make the time to be aware of how a new technology or process may be of use, if the value (or marketing 🙂 is good enough, others will experiment and then when things stick, we may be playing catchup. I think it would be an err for the data profession is to repeat the same mistakes that were made when XML was first becoming popular and leaving these data structure definitions to the developers.

So saying Yes, No, or at least Maybe to NO SQL or any other innovation it up to us. In many instances, our experience with past technologies (relational, IMS…) can carry forward to how new technologies can make older approaches more scalable and viable. For the truely innovative thinking, it should at least be interesting enough to do some reading on it.

We live in “interesting times”, with the excitement and challenges of it all.

Filed under Data Management Tagged with ,

Data Models, Date-A-Models and the missing course content

April 27, 2011 2 Comments

Fellow data professional, Chris Bradley, had a great story from a conference. A passer by had asked what the event was about and the answer “it is about how to data model” came across as “how to date a model”. Chris’ story telling is priceless as the dialogue had gone on for sometime until the disconnect was discovered, but if got me thinking, could we get more out of this story?

When people learn how to data model, there is a lot of focus on understanding the concepts. What are the Entities? How may they Relate to each other? Could this be a one-to-one relationship?

Not that I am speaking from personal experience, but presumably if you want to date a model, you’ld also want to be aware of what kind of relationship could be possible, what other entities are there to see things may fit and how lines are drawn.

Whether the course is on how to data model or date a model, there would have to be emphasis on how to manage what you create? Once you get the date, how do you make it worthwhile? Will there be a second chance, a third? Will there be long term value? What ongoing complexities may need to be managed? When it is about a collaborative relationship, how will you deal with unexpected questions, semantic misunderstandings, or gaps?

In Data Management, we often do a great job in defining a data model that is flexible with content and constructs we are proud of. Too often however, the modeler focuses just on the creation and not how the information is shared or stored through the model. What are the quality expectations? How would we know if, not just the model but the system it enables is meeting the need?

This to me is the key difference between a Data Modeler and a Data Architect. A great modeler understands the concepts to represent them effectively, and perhaps through different mediums (relational, dimensional, XML…). A data architect also understands who needs the information for what purposes, what are the available data sources, what are integration or quality complexities and how they could be managed over time.

It is not about having all the answers but understanding what is it that would truly matter and continuously working to achieve it.

Whether you are working on data modeling or dating a model, good luck in your endeavors.

Cheers

Filed under Data Management

Newer posts →