This is the first of a blog series which will be exploring repetitions in Pharma Marketing digital solutions, the current repeatable solutions in place including issues we are facing with them, and the clear need to do better. We will be defining Microservice based Data Contracts to solve business problems, and will provide an in-depth breakdown of this new powerful paradigm in the upcoming parts of the series.
Pharma and the repetition problem
We have all seen it before. A forward-thinking agency, full of new ideas, coming up with the pieces necessary to build the ultimate brand experience. Creates and builds all the pieces, tight timeline, glues them together and tightly couples all the functionality needed. So many bugs, QA, review, so many other bugs, iterate some more. It’s a decent launch. That was rough, so many learnings, let’s have a post-mortem, how effective are those anyway? We have all… seen it before.
This feels like a long time ago but not thinking about repeatability allowed for what seemed to be unlimited creative possibilities. Unfortunately, in practice, this approach became heavily limited by its own inefficiencies because grunt work repetitions reduce precious innovation time. Rarely did those hard-coded, custom solutions get applied across brands, projects, or even across channels. How do you keep track of security practices? What happened to all the learnings across vendors? In fact, what happened to the assets and code that the vendor was supposed to document?
Pharma and the hard-coded problem
That was then. We have been making some progress since. We now have modules, guidelines, libraries, CMS’s. Thanks to templated solutions, we are able to have some consistency across the board. There are also modules that can be reused, at least when it comes to the web. This is great progress, and we have extensive experience of these approaches here at Klick including deep knowledge on a range of CMSs , but we can do even better.
All of the above are heavily dependent in the system they are part of, are usually hard-coded to the requirements, and are tightly coupled to the problems they are solving. Hard-coding creates a high barrier to entry, and does not allow for flexibility. Try and re-use a module built for Drupal 7 in Drupal 8! It also makes innovation expensive because we are not only thinking about the problem at hand, we are also thinking about how it will fit with the rest of the pieces.
To offset some of the above, the business sometimes tries to settle on a single IT vendor that controls the technical parts of the puzzle, which automatically makes them the bottleneck as strategy and creative teams are trying to innovate. Over time the system starts dictating the brand vision instead of the other way around. The vision of the vendors’ solutions doesn’t match the hard-coded systems now in place, thus often creating a lot of friction between teams and in the end, often not coming up with the correct implementation.
There is a myriad of other issues with this approach, including generally being single-channel, problems with routing and how new solutions are approached, a general disconnect between tech and other disciplines, and a gradual stall of innovation.
How many times have we all heard the question – “What if we changed the CMS?”
These problems are rooted in the hard-coded nature of the approach itself, so patching the solutions independently does not fix the core issues.
Pharma and a paradigm shift
A very common pattern in scientific disciplines when a paradigm theory is not working is to change the paradigm altogether. We call these Paradigm Shifts. So when a paradigm shift occurs, in some sense the world changes. Or to put it another way, a non-working paradigm theory such as Pharma’s hard-coded problem is in serious need for disruption across our whole industry.
Data Contracts and Microservices
At the heart of this paradigm shift are communicating pieces that each independently, solve one problem very well, and the only coupling interface is a data contract, or in programming terms, an API.
We will go over how this seemingly simple approach can change everything, but first, let’s go through some of the requirements to make this all work.
- API First approach. There is no functionality that can be reached outside of the data contracts specified.
- Discoverability. Each API is clearly documented, easy to find, and easy to follow.
- Endpoint Testability. For every endpoint here, is an example that can be run instantly where the data going in and the data coming out are clear to visualize.
- Immutable Versioning. Every single functionality change or data contract update, is a new version.
- Service Level Agreement. A clear SLA for each service that defines a maintenance agreement, response time for issues, and resolution plan.
Part 2 of this Series will cover these requirements in more detail, describe how advances in cloud services providers allow for these requirements to be well implemented, and include different tips on how to achieve them. The requirements above are also enforceable and nonsubjective which is necessary to provide strong guarantees for a working ecosystem.
Since the data contract becomes the only binding mechanism between microservices, this paradigm allows for repeatability of each single functionality independent of the overall system.
This paradigm is a major technical advantage when it comes to scalability and how we program solutions. Even more importantly, it’s a major business advantage since it allows for functionality to be decoupled cleanly, allows for repeatability across the board for true omnichannel, and encourages innovation since dependency obstacles are now removed. Data contracts also allow for a very fast time to consume any of the existing functionality, so repeatability becomes a commodity.
Another major advantage is that this also allows for effective, accurate, and unbiased collection of measurements and metrics which we will be covering in detail in Part 3 of this series.
Problem solving in computer science is very often a balancing act and every concept comes with its own challenges that need to be clearly understood for it to be effective. There really are no silver bullets.
This paradigm shift is often called Microservices, and unfortunately the term has been abused somewhat to mean many different constructs of it. In Part 4 we will clarify what it means in our context, what the different challenges with it are, and how to avoid common pitfalls.
Who does this matter to and why?
As a conclusion to Part 1 here are only some of the roles that would massively benefit from such a paradigm shift.
Brand managers benefit from speed to market and no restrictions on innovation.
IT stakeholders benefit from consistency across the board at the functionality level, security guarantees at the contract level, discoverability using well defined industry standards, and unbiased report metrics that inform decisions.
Procurement teams benefit from standardized SLAs, standardized pricing models, and lower unnecessary costs.
Regulatory departments can also benefit from pre-approved functionality and content across multiple channels.
Here at Klick we have a working implementation of this paradigm, and we would love to help our clients with any aspect of it from consulting to full implementation.