It's drafty!
The importance of platforms and the right infrastructure in the era of digital transformation
I'm talking and posting quite a lot about digital transformation right now - be it in presentations, at LinkedIn or in remote calls. In doing so, I mainly focus on aspects for marketing and find answers to these and other questions: "How do I develop the right patient platform?", "Can I automate something in this multichannel campaign?", "Are interfaces to SalesForce or Veeva possible?" or "Which KPIs are of interest to management?” - just to name a few.
At some point, ideas, projects, schedules and cost estimates emerge from such discussions. Then sometimes the surprise is big, when a "normal" project takes five months and a team of seven people will be working on it throughout.
To be honest, it's not always easy for me to explain. Why?
Because the subject has a certain complexity.
Digital transformation requires a corresponding digital infrastructure – and this consists primarily of software applications such as apps, CRM systems, content management systems, APIs, interfaces, databases, etc. In addition, the topics of "IT security", "data analytics" and "cloud computing" have become extremely important in the last two years – with associated effects on efforts and timelines.
There are simply more and more individual topics to be considered, which require corresponding specialists. These in turn must work hand in hand to create a consistent "overall end product", for example in the form of an Omnichannel platform with CRM connection.
Website module for website module
The following diagram shows the basic software architecture that we have modelled at antwerpes and with which we set up large platform projects for our customers:
I will start with the explanation at the bottom right: The Content Management System (CMS) is used to manage the contents and to enable their input: texts, pictures, diagrams, schemes, animations, videos, audio files, graphic elements – everything that is needed is entered via the CMS and made available for use on the web.
What is noticeable: The CMS has become a rather small building block with relatively little importance for the big picture. A few years ago, many of the layers shown above were still united in the CMS. This made the CMS very important, virtually indispensable and therefore expensive. Modern headless approaches divide the whole construct into different building blocks and thus make it more flexible. The individual components are then easier to "handle" on their own.
An example: The web frontend was formerly part of the CMS. If one wanted to relaunch the frontend or the CMS, all components had to be relaunched. Nowadays you can redesign the frontend without having to “touch” the CMS.
Static instead of dynamic
After the "Content Management", you have to think about "Static Site Rendering".
What is it?
"Static Site Rendering" is used to avoid having to reload and dynamically render web pages each time a new page is requested. Instead, the pages are rendered statically before being requested by users and then only stored on the web server as simple HTML. This reduces loading times tremendously and is therefore also important for search engine optimization. Static site software tools (so-called generators) are for example "11ty" or "Gatsby".
The website core
Next comes the "core layer", which contains the business logic. In simple terms, this is where the (headless) HTML front end is merged with the system behind it. Simple example: In this layer, the input from a contact form is processed, e.g. forwarded to further systems such as databases or CRM systems. All this is quite easy to imagine in terms of a contact form, because it is very clear: You make an entry via the form fields, click on "send", you will receive a confirmation à la "Thank you very much! Your data has arrived" and then something happens to the data - so far, so good. But what if a chatbot is to be developed that includes fifty user addressing options and that can offer on average four additional input options for each of these fifty options? One can then hardly imagine how many "communication ramifications" have to be considered and planned. The business logic is thus a kind of kit that "sticks" the content together properly and provides the right outputs - and is responsible for the user experience (UX).
Frontend: the view in the foreground
The next layer, the web front-end, is closest to the user: It contains everything that can be seen in browsers like Firefox, Safari or Chrome. Here, all contents that have been entered into the CMS at some point are displayed. Rendered statically or dynamically, depending on whether you use a static site generator or not. The web front-end has to "make friends" with all common browsers in all common versions; on the desktop, the tablet and the smartphone - and therein lies the challenge.
The whole thing is peppered with the topics security, GDPR, analytics, data management, medical cloud, continuous integration (e.g. via Gitlab) and the web server to be used. We have included "Security" as a separate layer in the overview, as its importance, especially in the pharmaceutical and health care sector, is very high.
The user, for whom the whole thing is done, sits in front of his browser window and sees the frontend.
Growing complexity in the digital world
This is how we at antwerpes approach digital transformation: With the right backbone and with the appropriate, scalable infrastructure. The small stand-alone product website is practically no longer or only rarely available. Usually, extensive analytics and data aggregation or connections and interfaces to internal systems such as CRM or online shops are required.
What I'm trying to say is: The digital world, and with it the digital transformation, is complex and will become increasingly complex. In order to cope with this complexity, more and more specialists are needed, who contribute their knowledge in their respective niche. Personally, I find such projects particularly exciting and educational.
You always learn something new in the process and the end result usually has certain uniqueness – in principle, no two platforms are alike, because the starting points and requirements are never identical. By this I mean above all the strategy and the approach behind it. If one project is about relieving the burden on a medical service centre, for example when running a patient service, the next project is about accompanying medical professionals for a year via eight different touchpoints. A third approach might be to implement a chatbot that invites as many target persons as possible to a digital event, and the fourth project focuses on the requirement to digitalize your own sales force and integrate video calls into the existing CRM system.
Clarify these 5 questions at the beginning
All these approaches require their own infrastructure, are based on existing components and have an impact on internal processes. Therefore, answer the following five questions at the beginning of a transformation project:
1. Which departments need to be "picked up" and included in the considerations?
2. Which required IT systems are interdependent or influence each other?
3. Which data from which systems are required? Does "Global" have to be involved?
4. Which existing software tools must be used? Which software licenses are already available?
5. What internal policies regarding security, hosting environment and infrastructure need to be considered?
And, last but not least, you should take heed of the following: Digital transformation is a "continuous journey" - rather than loading all the project pressure onto a specific day, take a period of time and define several milestones within this period, which you approach in an agile manner.
True to the motto: "Done is better than perfect."
"We at antwerpes speak of "Creative Digital Transformation".
By the way, creation should not be neglected with all this technology – that's why we at antwerpes speak of "Creative Digital Transformation". Creation, content, technology and advertising have to be brought under one roof or, to stay in the picture, connected on one platform.
Because if it starts to pull at the top, you don't have to run the risk of being blown away – with a stable backbone, it is quite sufficient to close a window.
----------------German version of this article-----------------