Progress Acquires MarkLogic! Learn More

Old Dog, New Tricks – and Agile Modeling

Back to blog
3 minute read
Back to blog
3 minute read

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

James Wonder

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.

Read more by this author

Share this article

Read More

Related Posts

Like what you just read, here are a few more articles for you to check out or you can visit our blog overview page to see more.

Architect Insights

What Is a Data Platform – and Why Do You Need One?

A data platform lets you collect, process, analyze, and share data across systems of record, systems of engagement, and systems of insight.

All Blog Articles
Architect Insights

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.

All Blog Articles
Architect Insights

When a Knowledge Graph Isn’t Enough

A knowledge graph – a metadata structure sitting on a machine somewhere – has very interesting potential, but can’t do very much by itself. How do we put it to work?

All Blog Articles

Sign up for a Demo

Don’t waste time stitching together components. MarkLogic combines the power of a multi-model database, search, and semantic AI technology in a single platform with mastering, metadata management, government-grade security and more.

Request a Demo