Thinking About Customer 360

Customer 360.

Or, as one of our competitors (who shall remain nameless, but uses a Birch leaf as their logo) calls it, Single View.

Everyone wants it.

Everyone needs it.

After all, most of your customer data is stored in a variety of different systems, each providing just a small glimpse of any individual customer.

It would be great to have a single, wholistic view of the customer, in one place.

Thus, customer 360, the whole-ly grail of customer data.

And if you believe in the marketing on our website, all you need to do is take all of your existing systems, drop Couchbase in the midst of them all, draw a few arrows, and TA-DA, you’re up and running.

It’s magic!

Well…

Not so fast.

See, our marketing people get paid to convince you how simple and easy it is.

(Sorry Peter, just being honest here)

I have a different job.

My job is to help your projects to be successful when using Couchbase.

After all, our industry is littered with the corpses of failed projects.

We’ve all seen them…

Been to their funerals…

And many of us had a hand in at least one of the deaths…

So it doesn’t pay to take the simplified view.

(Unless your job title starts with a “C”)

No, for those of us whose job is to implement systems like a Customer 360, we need to pay attention to the details.

Integration

So, looking at the reference architecture drawing on our website, from left-to-right, you’ll see these boxes with various named systems encapsulated within them.

CRM, ERP, Mainframe, etc.

And a couple of arrows, pointing into and out of a tall rectangle labeled “integration.”

Looks simple.

Unfortunately, it’s not.

This is a part that’s going to involve a lot of thought.

Really, a lot.

See, it’s not just a matter of connecting the various systems to Couchbase using Kafka or some other connector and sending the data over.

I mean, you could, but then you’d just have a bunch of unconnected data cluttering up your Couchbase bucket.

No, you have to think about how to relate the customer data from the various disparate systems that it’ll be coming from.

And how to combine it.

And format it.

Like I said, a lot of thought.

Getting the data into Couchbase is the easy part, it’s the combining and formatting that’s the difficult part.

Or at least determining how it should be done.

The actual ETL process should be pretty straight ahead.

After all, it’s just a matter of extracting the data from the source systems, formatting it as JSON, combining the data from the various sources, and then storing it in Couchbase.

Easy, peasy…

I could do it in my sleep.

The ETL part of it, that is, not the data modeling…

I have to be awake to do that part…

Microservices

Yes, every implementation of a Customer 360 is going to involve some set of microservices.

You’ll have some important and sensitive data in this bucket, and at the very least you’ll want to control access to it.

What other microservices you’ll want to have will depend on your business, and what it wants to do with your customer data.

Probably some sort of business rules behind a REST API…

A business process or two…

And a data sync for a mobile application of some sort.

Which brings me to…

Mobile Integration

See, here’s one place where we (Couchbase) can really simplify things for you.

By integrating our mobile stack…

Couchbase Server, Sync Gateway, and Couchbase Lite…

You can reduce your mobile data sync responsibilities down to deciding how you want to divvy up the data for your mobile users.

You know, who gets what data.

Yes, I know, more thinking…

See, there’s only so much we can do to eliminate the thinking part of this.

Actually, very little.

There’s no getting around it, this does involve a good amount of thinking…

But once you’ve done the thinking part, we try to make the rest of it as painless as possible.

And by using our mobile stack, you can reduce what you have to think about down to how to allocate the data to users, and what properties you have in the various documents that you can use to determine this allocation.

Then you put this all into a function written in JavaScript.

And turn your focus to your mobile app itself.

Yep, I’m afraid the app will still need to be written.

No getting around that.

But it won’t have to deal with REST APIs, or waiting on the server to respond.

Nope, your mobile app will only have to deal with the local, on-device database.

We take care of everything else involved in getting the data to and from the device.

So, by using our mobile stack, you are able to reduce your mobile application coding responsibilities from this:

To this:

I know which one I would rather have coding responsibilities for…

Front-End

Which brings us to the final portion of a Customer 360, the user access application.

Unfortunately, we can’t do much to eliminate or simplify this part of the solution.

You have to determine how you want your users to access and work with the data…

Then turn your developers loose…

And hope what they deliver is close to what you actually wanted.

I mean, we do make it easy for developers to work with Couchbase.

We provide SDKs in most of the popular programming languages…

We make it easy to transition from SQL to N1QL for working with the data…

And we have numerous Training and Consulting services available to assist in your efforts.

But we can’t write your code for you.

Sorry.

So, Why Couchbase?

I mean, everyone and their dog will tell you that their database is the best for this solution.

So, why us?

Besides us being known for high-availability, speed, and easy scaling, we do have a few other things going for us…

Other than I my personal prejudice…

I mean, we make it easy to transition over from a SQL-based database by making our N1QL query language ANSI-compliant, allowing you to bring across your existing SQL knowledge and experience (no knowledge left behind?)…

And our schema-less document store allows your data model to evolve over time as your organization makes various demands on your developers for new features and functionality…

Our built-in Full Text Search makes it easy to find what you’re looking for without having to integrate in another tool…

Our Analytics service allows your business analysts to twist your data into all sorts of strange shapes without having to wait for an overnight process…

Our Eventing service enables you to cause all sorts of mischief in real-time…

And our mobile stack makes it very simple to limit what data any user has on their mobile device, and synchronizes updates between the phone and Data Center without having to wait on a REST service or write all sorts of complex synchronization routines…

And when the inevitable happens, and one of your servers dies (and trust me, one of them will die eventually), your data remains intact and available.

This will make your CIO very happy.

After all, it’ll be one less reason for your CEO to yell at him/her.

And eventually, that happiness will make its way down to those of us working in the digital trenches.

Trickle-down happiness.

It’s a good thing to think about…

Yep, there we go with that “thinking” thing again.