Ending the enduring legacy of data silos


“I understand what data syncing is, but why is it useful?” is something we hear all too often. Here’s how we try and explain it.

It should be that every time your business interacts with a customer, a piece of information is generated. This could be a phone call note, an invoice or a request for help from your customer. All common scenarios and, in most cases, all handled by different systems.

As our user community has grown, we’ve found that one way to consider the usefulness of syncing data is to think about all the places where a business interacts with customers.

  • The sales team are often using a CRM system (Dynamics, Salesforce, HubSpot, etc.)
  • The marketing team may be using email marketing (MailChimp, etc.)
  • The customer support team are typically using a helpdesk system (Zendesk, ServiceNow, etc.)
  • The finance team are likely to be using an accounting package to send and monitor invoices, debtors, etc. (Xero, etc.)
  • There may be collaboration software in use across the business, either to manage projects or just to maintain open communication channels (Jira, Slack, etc.)

That list just describes generic functions that most businesses have. It is quite likely that there will be some specialised software to support the primary function of your business. This could be point-of-sale software, manufacturing/control software, project management software, e-commerce, etc.

That’s a lot of places where there may be references to customers. When your sales team ring up a customer, they’ll want to know whether the customer has any outstanding complaints. When your accounts team need to follow-up with a query, they’ll want to know who is best to ring and ask. When your support team are working on open helpdesk tickets, it’s useful to know that the sales team have a big proposal submitted awaiting a decision.

This is where data syncing comes to the rescue. When I’m explaining the business value of Seamless, I often ask people to tell me all the different engagements their business may have with their own customers. I then ask what underlying system that interaction is recorded on. Typically, as we talk through these engagements, it becomes very evident how standalone silos of information are being built across the business.

Seamless is about making disparate silos of data disappear into the background. Staff across an organisation should all see the same information about customers (or orders or helpdesk incidents or … ) no matter which IT system they’re currently using.


Paying more for less – the false economy of data re-entry

Office“We can just solve the problem with a few cheap data entry clerks.”

Every time I hear this phrase, I am stunned. Introducing a process which involves re-keying data from one system to another is, pretty much without fail, a bad idea. Often it seems enticingly cheap – pick up a few students or offshore the data problem and there’s one less thing to worry about.

Data rekeying is a false economy, in this post we’ll explore some of the reasons why rekeying will come back to haunt you.

Continue reading

No-one likes downtime. But if it has to happen, at least make it happen elegantly

It’s hard to write a post which talks about any virtues associated with downtime but, in the wake of last night’s Azure UK outage, we had some small sense of satisfaction that Seamless behaved both as we designed and would’ve hoped. Connectivity to the UK South Azure data centre was lost between about 22:30 and 01:40.



Accepting that we weren’t going to fix Azure’s connectivity issues, where do we see the positives for Seamless?


1. Our alerting let us know it was happening (before Microsoft confirmed any issues)

The Seamless monitoring alerted us to the first connectivity alert at approx. 19:43. This seemed to be an isolated alert, however we received a second connectivity alert at 22:30 and they began to be raised regularly at that time. We then began our own investigation and the Azure service page confirmed a connectivity issue at approx. 23:30. Shortly after that, we issued our alert to the Seamless user community.


2. When Azure connectivity returned, Seamless shrugged its shoulders and carried on working

Bearing in mind that connectivity was the primary issue, the service itself actually continued running. As soon as connectivity was restored,¬†data continued sync’ing with no intervention from us (or, of course, our customers). Any data that had not been collected at source would’ve then been collected and posted to target systems. Any data “in transit” when the connectivity issues started was processed and sync’ed to relevant target(s).


3. We had mitigation actions ready in case we needed to support customers

Our mitigation options are typically to redeploy the service and the config to other Azure locations (subject to relevant instructions from our customers bearing in mind potential data considerations). In the event that the UK South region was not restored by the start of the business day, we were in a position to relocate the service and client configurations to Western Europe (Dublin). This would’ve taken us less than an hour and no data would’ve been lost in this process.

As Microsoft restored the Azure service around 01:40, this was not necessary.



No-one likes downtime and we recognise that we’re lucky that these 3 hours were outside of core business hours for our current customer base. In practice, we continue to believe that a Microsoft data centre is more secure and robust than were we to build our own. ¬†In this light, we architected the Seamless service to “fail elegantly” and although disappointed this had to be tested in anger, we’re delighted that it worked as we would’ve expected it to.

Business flexibility, celeb news, Lego modelling and IT architectures – you heard it here first

As much as it pains me to admit it, I fear that¬†Gwyneth Paltrow and Chris Martin were onto something when they coined the term “conscious decoupling”. In the data integration space, the ability to break down a service into components is a significant enabler of flexibility. That’s good because technical flexibility translates to business flexibility. If the only constant is change, as we’re so often told, then flexibility in technical architectures is the way to prepare for change.Continue reading

Designing for a happy birthday

In celebration of our first “official” day designing and developing software for Recursyv, we turn our attention to the birthday controls within Dynamics CRM. Getting to know customers and being responsive to them on a personal level¬†is one of the drivers of implementing a CRM system. In this light, it’s frustrating that¬†the storing and use of birth dates is so poorly handled.

Let me illustrate with the birthday selector on the contact form.


It’s a standard date control. You’d think there’d be no problem there, but in practice it means that either you need to know the contact’s birth year or your data is inaccurate. One is unlikely, the other is inelegant. Neither¬†make for great design. In practice, the pragmatic approach is just to ignore birth year in the data set, but¬†it seems that¬†in a mature software system, it shouldn’t be necessary to use workarounds for such basic features.

Our design ambition for the In-a-Box product set is that it should be intuitive and easy-to-use. Inelegant workarounds don’t fit into this mindset. Consequently, our current thinking¬†for the In-a-Box product set is to create custom fields for birthday (day of the month, i.e. 1 – 31) and birth month. This will at least enforce¬†that data held on system is robust (i.e. accurate). It will require¬†some changes to views but that’s straightforward enough. In practice, the data¬†should be used to drive dynamic marketing lists and that is easily achievable with data structured like this.