Old Dog, New Tricks – and Agile Modeling

I had a realization today; I am getting old…

It happens to all of us, but my epiphany came while talking to a colleague over a cup of coffee and discussing data challenges. When I first got into the business world as a young, geeky Unix developer, the business would decide what they needed and we would build it for them. The challenges were easier and the data was certainly more straightforward. Today with the data being complex and voluminous, the capability and speed at which we can process that data is now dictating what can be done and how fast it gets done. Hence, like it or not, technology is limiting the business — and therefore, in a strong way, controlling the business’ direction.

My colleague and I came to this conclusion when I was explaining a conversation I had with a friend, a long-time DBA, about how MarkLogic enables the business to specify how you model your data instead of the data driving what functionality you can provide. It’s all about time to market, and any technology that decreases your time to market is an enabler for your business.

Data Shouldn’t Drive Functionality

Agile modeling is the key here! Load the data into MarkLogic and then model as needed for your business purpose. When the business tells you a specific piece of data is important you can determine if you want to model it or use it as is in the database. There are many ways to do this inside MarkLogic and the ability to not be limited by your schema is the reason!

My friend I referred to earlier found it hard to relate to not pre-determining your data model up front. He liked the absolute nature of knowing the format exactly and was comfortable talking about how they “force” (his words) their data into the schema.

“Do you use all the columns you create in the database in your business applications?” I asked.

“No,” he responded.

“Are you capable of loading any data type into your pre-defined data schema?” I probed further.

“No,” he said again.

After several minutes of conversation, he relented and explained that he did not understand how a database could take in any structure of data and make sense of it.

“A-ha!” I expounded, “The problem is not the technology but the simple fact that we have been trained to think one way — relationally.”

He admitted he is conditioned, by his RDBMS training and years of use, to “see” (his words) data in rows and columns and that it’s hard to envision using something like MarkLogic because of that!

Which brings me full circle to my “getting old” comment and teaching old dogs… Well, you get it. As a previous MarkLogic customer I too needed to un-learn my previous conditioning.

Data Should (and Can) Serve Your Business Requirements

Even though we have been trained to think a certain way, our data needs to serve our Business Requirements not the other way around. When dealing with disparate data from a multitude of sources, technologists need to look for new ways to deal with it, even if it’s outside their comfort zones.

When RDBMS was first introduced, it was outside the comfort zone of the mainframe technologists, but it was a better way to deal with their data challenges.

Today, we have the multi-model database — which allows agile modeling — a far better way to deal with disparate data challenges than relational modeling. Learning a new technology is tough. Especially for us old dogs. But we need to be open-minded and step outside our comfort zone sometimes. For the health and growth of our business (not to mention our own careers) it’s important we learn, adopt and adapt as quickly as possible. Even if it may be different from what you’re used to.

Thanks for listening!

For more information:

What ‘Load As Is’ Really Means