A better way to a single platform

A Better Way to a Single Platform is one of the 10 principles under Artis Group “A Better Way” philosophy. Having worked on numerous IT projects since the mid-nineties I’ve been a part of more integration projects than I care to recall. These experiences (good and otherwise) have led me to a strong belief that the Single Platform approach should always take focus to reduce the all too common risks associated with complex integration. But first a small bit of history…

Back to my mid-nineties

We, IT folk, had limited options as to how we could extend software solutions. More often than not, software was custom-developed or came from a vendor who set the scope of what the system did (and didn‘t do). By the late 90s many of these platforms started to provide the ability to extend and customise their previously locked solutions via APIs, a move that allowed us to start to “glue” together systems. Thus began the rise of the “best in breed” concept; the ability to choose the single elements of software that best suit a particular part of the problem, then integrate (glue) them together, the end result being the building blocks working together for the final best outcome.

While good in theory, in practice we were often forcing systems that were just not compatible to talk to each other and the time taken to build the integration was often longer than just starting from scratch.

Project failures around what was assumed to be simple often led to tears and ultimately very public (and costly) legal arguments. Whilst the tools and patterns (geek speak for “ways”) in which systems can be integrated have certainly improved and the concept of “best in breed” remains a valid approach, the larger providers now provide enough scope within their products to move towards a world where one provider can indeed provide all the building blocks that out of the box talk together…… a single platform approach.

The Rise of the Single Platform

As a Microsoft Partner and personal Microsoft advocate, I’m compelled to take the specifics in light of Microsoft, but you’d be right in thinking that Microsoft’s competitors have al followed suit in a bid to have you invest in their specific platform.

Microsoft’s massive investment in bringing their Line of Business, like Microsoft CRM, Finance and Operations etc. has been collected into a massive template of business objects that describe the key attributes of most of the “stuff” you can think of. For instance, the concept of a Contact (e.g. Matthew Verity) consists of several hundred fields of information from phone numbers to addresses, preferences etc. Similarly, Accounts, Appointments… the list goes on. If you consider every business system you’ve worked in, these are common data elements (or Data Entities). Microsoft has put all these together into what is called the Common Data Service CDS.

It is a huge database where you can pick up just those template data elements specific to your needs, then start to use them as-is and then extend them to add new fields to meet your additional needs (for example eye colour).

Microsoft has a large selection of templates to choose from.

So CDS deals with the data side, but what about how users interact with the data? The Create, Read, Update and Delete (referred to as CRUD) side of things? The same way in which Microsoft has templated the data elements, you can license pre-built applications to use these data elements – These are the Dynamics 365 applications.

Each application provides a different subset of what gets shown. For example, Dynamics 365 Sales provides access to data elements around managing a sales pipeline including Contact Management and Lead Management as well as providing pre-built workflows that not just allow for the saving of these elements but also a way to enforce rules and provide a process to follow.

If you need to have an application that provides Ticketing for client case management, Dynamics 365 Customer Service exposes elements around Cases and again Contacts and Accounts.

What if there isn’t a Dynamics Module for me?

This is the next logical, and easily answerable questions. The Dynamics Applications are designed to take you from data to a pre-built and Out of the Box usable set of features, but for larger businesses they will want to build and design to their own specifications.

Should this be the case, you can look towards Independent Software Vendors who have built very specific customised modules of their own for resale or “go it alone”. Either way, you are still building upon a foundation that is the same platform with all your data living in one place and all the tools to build and change as you choose.

How do I know which path to choose?

As much as I’m enjoying “building stuff”, experience in business has taught me to re-use and enhance rather than build. The adage around re-inventing the wheel should be front in mind. The pictured flowchart provides a basic approach as to how I guide the decision process around buy or build; you can see that from the start I will validate whether something is available and ready to go then work down towards a build as a last option.

Only you as the “builder” will have the skills to test whether something pre-built can meet your needs or your needs can be massaged to work the way in which the pre-built solution does, but by approaching buy-first you are benefiting from:

  • A (safe) assumption that the solution has been built based on a consensus formed from a range of organisations and that there will be benefits within that you may have not even thought about
  • The built option will provide increasing value over the life of the subscription
  • The built option is generally supported and well tested.

Again, in larger organisations with specific needs, the platform exists to provide a way to extend as required, but by keeping the buy/build ratio in check the risk profile of your project will be reduced. As I often say, “just because you can build it, doesn’t mean you should”.

Example of a decision process for when to re-use or build from scratch.

Why Microsoft?

For myself and so many of our customers, it comes from our daily reliance on Microsoft Office. Whether your killer app is Outlook, Excel or Word, most of us rely on Microsoft Office as a part of our daily work (and personal) lives. Office 365 has successfully placed itself at the core to how most of us log on, are secured, and get our email every day. It is the beating heart of most enterprises and for most of us, “in Microsoft we trust” means that we can knock our work out day after day.

Whilst we can all critique the Microsoft Experience at times, we all rely on it and the consistency in this experience allows us to move from Word to Excel to Project to Outlook with minimal retraining due to that consistency of experience. That experience has been built upon and taken into Microsoft Cloud service such as Dynamics CRM, which follows that flavour.

From a business perspective, the process of extending their services into the Microsoft cloud reduces the risk around change management concerns as user train into a known user experience. Even better, the username and password that they log on to their devices with every day are the same used to log on to those services as they turn them on.

No multiple passwords, no multiple ways to manage the users, instead we are just extending the services available to users. The Microsoft Single Platform vision sees a full suite of tools accessible not only working together in the backend but also served in a single palette as you need.

Most of us rely on Microsoft Office as a part of our daily work and personal lives.

“But you’re putting all your eggs in one basket!”

… is the catch cry of many when the Single Platform argument is posed. This is not an invalid concern and not one I say should ever be discounted.

Like all decisions made in life, it becomes a way of weighing up the benefits versus the risk and while it can be measured and possibly proven that there are outages and issues in all SaaS platforms, these issues are reducing over time and can be countered by the argument that spreading the load over multiple platforms means more frequent exposure.

The pros and cons of a Single Platform can be exhaustive but lie ultimately in you assessing the benefits of a platform that will extend without the risk of system integration versus a single ecosystem that “just talks”.