We’ve joined forces with Smartlogic to reveal smarter decisions—together.

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

A seasoned veteran in innovating with technology, James has worked with almost every programming language, database, search technology and has built large back-end and online systems for an array of customers throughout his 30+ year career. Most recently he has turned to focusing on innovating with NoSQL.

Having consulted privately, he started with the American Institute of Physics in 1993 and grew their online system to be the premier online service, known as Scitation,sm built on MarkLogic technology, before deciding to work for the leading Enterprise NoSQL database. As Managing Technical Director for MarkLogic, James leads development teams to build world-class applications for Fortune 500 companies.

Start a discussion

Connect with the community




Most Recent

View All

Unifying Data, Metadata, and Meaning

We're all drowning in data. Keeping up with our data - and our understanding of it - requires using tools in new ways to unify data, metadata, and meaning.
Read Article

How to Achieve Data Agility

Successfully responding to changes in the business landscape requires data agility. Learn what visionary organizations have done, and how you can start your journey.
Read Article

Scaling Memory in MarkLogic Server

This not-too-technical article covers a number of questions about MarkLogic Server and its use of memory. Learn more about how MarkLogic uses memory, why you might need more memory, when you need more memory, and how you can add more memory.
Read Article
This website uses cookies.

By continuing to use this website you are giving consent to cookies being used in accordance with the MarkLogic Privacy Statement.