Debunking common myths about cloud computing

Cloud computingIt wouldn’t be remotely accurate to suggest that cloud computing is the “next” big thing. I had my first email address in 1993 and Salesforce, the golden child of cloud apps, was founded in 1999! However, there are still a number of misconceptions that we encounter when we mention that Seamless has been designed and built as a cloud-first integration solution.

When we say Seamless was built “cloud first”, we mean that it was built using capabilities that have only become available in the cloud-era (i.e. microservices delivered within a cloud computing platform – more about that later). We do not mean that it will only connect to other cloud based applications – Seamless can absolutely connect on-premises software to cloud applications.

To make sense of it all, we’ve debunked some common myths about cloud computing.Continue reading

Taking a moment to celebrate the engineering


Since the beginning of the year we’ve been working on a particularly thorny deployment. An integration with lots of technical challenges which brought together many features of Seamless for the first time. Jon has been tucked away in “deep dev” mode and, as he prepared to put the integration into test, he wrote a wrap-up note for the rest of our team. The implementation validates a lot of the underlying engineering for Seamless. On reflection, I realised that this integration creates a lot of milestones.
Continue reading

Why don’t we just get the dev team to build it?

When we’re discussing integrations with prospective clients, one question that seems to come up every so often is “We’ve got a dev team as part of the project, why don’t they just build it?” It’s not an unreasonable question, if there’s no compelling argument for using an integration service then why bother with one?


Getting to grips with integration development

Having some insight into how an integration works will provide some useful context. In simple terms, a straightforward integration follows roughly these steps:

  1. Get specific data from the data source (i.e. construct the relevant queries)
  2. Assess whether that data has changed since the last time we got it
  3. Decide whether the data needs to be posted to the target system
  4. Encrypt the data
  5. Compress the data
  6. Move the data from source to target
  7. Decompress the data
  8. Decrypt the data
  9. Transform the data
  10. Write the data to target

I should add that those steps are of differing levels of complexity in different scenarios. At a simple level, some systems can provide data which has changed since we last saw it, some systems cannot and the integration needs to perform the compare. At a more complex level, some systems have sophisticated APIs which allow us to construct queries “on the fly” using configurable options, some systems require us to hard code the queries before we can execute them.

In the cold light of day, most of these steps are generic:

  • Step 1 is specific to the source system but not necessarily to your business need, that is to say – “Dear system, please tell me about new records created in the past 30 seconds” is a generic request of whatever system you’re using. It is not specific to your business need. If the source is bespoke, then naturally it is a wholly bespoke step.
  • Step 2 is typically generic, but will be driven by business need.
  • Step 3 is a business decision largely informed by the outcome of Step 2.
  • Steps 4 through 8 are generic for any (well designed) integration.
  • Step 9 is specific to your setup in the target system. The data transformation will need to reflect the data structures in your target system, including both the overall data structure (an account in the source may be called a company in the target) and potential dropdown list values (Mister maps to Mr, status set to “Active” maps to status set to “Live”, etc.).
  • Step 10 is specific to the target system in the same way that step 1 is specific to the source system.

Steps 1 and 10 are specific to the “technical scenario” (i.e. the systems in play) and steps 3 and 7 are where your business requirements are going to drive how the integration should work. The rest of it is pretty much the same, whether you’re connecting your CRM to your helpdesk or your accounting package to a front-end e-commerce system.


Paying to reinvent the wheel

With that in mind, let’s return to the question: “We’ve got a dev team as part of the project, why don’t they just build it?” The short answer is “Because the vast bulk of their development effort would be spent on generic integration features which are already accessible to you at a much lesser cost than building them yourself.”

Naturally, there is more complexity to the answer. In my experience, point-to-point integrations are usually developed to a “minimum functioning feature set”, i.e. they can get the right data from A to B on day one. That’s not necessarily a terrible place to be, but it is not as good as it could be.

A service built first and foremost as an integration service will offer sophisticated features which your project budget is unlikely to underwrite for a single point-to-point integration. Encryption, compression, elegant management of downtime at the source or target, ability to be easily extended, etc. All of these features need to be designed and built.

Additionally, developers are not “just developers”. That’s like saying builders are just builders. The technical skills required to marshal data, overcome infrastructure and connectivity complexity, manage reporting, etc. are quite different to the skills required to configure / build your new application. Sure, there’s some overlap. Most bricklayers can do some paintwork, but for painting decorative ceiling cornices, I’d rather get a painter.


The big picture

In a 2015 paper on digital transformation projects, Gartner noted that “many organizations already favor a new kind of “build” that does not include out-of-the-box solutions, but instead is a combination of application components that are differentiated, innovative and not standard software or software with professional services (for customization and integration requirements), or solutions that are increasingly sourced from startups, disrupters or specialized local providers.”

We’re happy to be one of those startups, even if it means using American spellings on our blog post.


What inspired us to build the In-a-Box solution?

The inspiration for In-a-Box comes from two things we’ve seen over the past few years of implementing Dynamics CRM.

MS Dynamics CRM, now part of Dynamics 365, is a complex, enterprise product which is feature rich and extendable. In practical terms, it is a massive toolset of options available to the user. This means that it often requires extensive professional services projects to configure/customise the solution to the needs of a particular instance. While these projects are interesting, they’re also expensive and create a significant barrier to entry to many smaller businesses wanting to benefit from the power of the platform.

And all the while, the world is changing. More and more enterprise class services are being sold on a monthly subscription basis (per user, per month) at rates that are very affordable for small and medium businesses. To Microsoft’s credit, the “new Microsoft” has recognised this and is turning many of its traditional boxed software businesses to be cloud first (Office 365, Dynamics 365, Azure services, etc.). Dynamics 365 can be had for well under £100/user/month, a small price to pay for the power it provides.

But there remains a gap between this massive hurdle getting onto the platform relative to the monthly cost of using the platform. Small and medium businesses just don’t have tens of thousands of pounds to hand to spend on software projects. The In-a-Box products were conceived to bridge that gap. We’ve consolidated our experience across hundreds of implementations, looking at the things most businesses have asked for, and built this into a packaged solution.

The design focus has been driven by two principles:

  • Simplification of the solution: pare down the forms to use the most commonly used data fields, provide a handful of well-designed business processes, deactivate views to hide complexity, etc.
  • Don’t break the underlying data model: part of the attractiveness of Dynamics 365 is that it provides a scalable path for businesses who either grow or have new business requirements (Customer Service, Project Service, xRM, etc.). By staying true to the data model, we can ensure our clients are not compromised in any way by decisions taken in respect of using an In-a-Box solution rather than a bespoke implementation.

The downside is plain to see. By using an In-a-Box solution, you’re limited to the design decisions made in building the solution. It’s not really different to buying a physical product at a retailer. There are probably a few options you could exercise, but the core product is the one you bought. The software may only meet 85% of your requirements rather than the 100% that a bespoke implementation may achieve. With a handful of consulting days, you might close that gap to 90% and still stay in the realms of a reasonable cost. (Or, better, use the system for 3 months, and then re-assess whether perceived needs are real needs!)

I guess it boils down to a simple question: do you want stay on spreadsheets (as many of the target customer base are likely to be using) or, for a reasonable cost, cover 85 or 90% of your requirement? Because the 100% requirement is just not realistic for small and medium businesses.


Recursyv Sales In-a-Box is now commercially available. If you’re interested in discussing these ideas further or a demo, please be in touch.

Note: We’re aware that Dynamics 365 Business Edition is a similar application of this mindset. In another post, we’ll share some of our considerations in respect of furthering developing of this product versus waiting for Business Edition.