The times of business applications as we know them are over.
Up until now most applications are more or less monolithic in their logic layer. There are different tiers but essentially all services and business objects that are part of the application are tied together and to their user interface.
Even if configurable, they are mostly built using high code environments that require significant expert skills. Although cloud technology and SaaS deployments have broken big suite types of applications down into smaller dedicated clouds that offer specific solutions to specific problems. The result of this approach is that there are often different databases and representations of the same real-world entity in the different applications or clouds. Some of the consequences are that object and database models need to be kept in sync. Another one is, of course, data duplication and the need for a middleware that joins the different applications.
End of the last millennium, then SAP CEO Hasso Plattner formulated a vision of building business applications by recombining business objects via drag and drop, i.e. mainly declarative means. To be sure, this was well before anyone talked about no-code / low code environments. One of the outcomes of his vision was SAP Business by Design, which after all fell well short of fulfilling his vision. A good reason for this was the unavailability of the required technologies.
Another one lies in the history of enterprise software. Again looking at SAP as an example here. SAP started with an ERP system that at the end of the 80s and the early 90s was already capable of running a good number of operational processes. Then came the times of advanced planning, CRM & co. All of them have been outside the ERP development stack. Functional silos were born early.
A third reason was the advent of SaaS and the breakdown of business applications into silos of clouds. One for sales, one for service, one for marketing, one for HCM, you get the picture.
All of these clouds have their own data- and object models and they need integration. On top of that, many core applications are deployed on-premise, following old architectural models, and that are hard to replace.
The sad consequence
Not surprisingly, the result of all these artificially created silos is not helping businesses to become more agile, more responsive to customers’ needs, and desires. It is also not offering a better user experience for employees. Instead, employees often need to deal with a multitude of different, often poorly integrated applications. Even worse, this gets aggravated by inconsistent master data, be it customer master data or simply product master data, even pricing data.
And we are not even talking about transactional or, god beware, behavioural data.
What a company wants to achieve is being successful by helping its customers successfully solve their needs and desires. To be able to succeed in this endeavour, the company needs to be relevant and get responses to relevant and meaningful engagements – or have meaningful responses when engaged itself. This, in turn, mandates to have a contextually relevant view on the customers, as a group and as individuals. Else interactions, or engagements, are based on guesses at best. As I have written and said repeatedly, what a company really wants is not a 360-degree view of the customer but one that is actionable at any given time.
The need for customer data platforms – CDPs – to fix this deficiency was born. But to be sure, a CDP is only a band-aid. It does not remove the silos, it merely provides the silos with some harmonized essential data – plus some services, as CDPs are evolving.
But don’t get me wrong. Although they are helpful, CDPs do not fix the silo issue. Nor has the “siloisation” of enterprise software been their only driver.
The way out
The cleanest way out is to build one’s enterprise software structure on one clean stack that offers all required business objects and -entities along with consistent extensibility.
Which is a pipe dream to achieve.
On one hand, most existing companies already have an existing legacy infrastructure which they will not be inclined to just throw away.
Justifiably so.
On the other hand, most enterprise vendors tend to acquire functionality that they do not offer if and when they deem it necessary. All of the sudden, the nice consistent clean stack is a thing of the past.
I know of only a few vendors that can offer this type of stack and the commitment to build missing functionality themselves, Zoho being one of them.
All other vendors need to go or are on the way of going one of two other ways.
- Either rewrite the applications in a way that unifies and exposes the business objects consistently (and this ideally in a backward-compatible way)
- Or add a service layer on top of the existing applications. This service layer then abstracts the different applications and exposes business objects consistently and uniquely across applications. It also takes care of create, update and delete operations.
In either way, extensibility and the creation of business processes/workflows needs to be supported. This is the place where no code and low code environments show real value – as opposed to freeing the citizen developer from the constraints given by evil IT – but I digress …
The latter is the way that e.g. SAP goes with SAP Graph, or that Oracle exhibited when releasing Oracle Fusion Marketing, albeit in a less generic but highly business process-oriented way. Even Zoho, which owns the full stack, is providing more and more services. Continuing this thought, applications can get disassembled and then recombined using these services.
Now, what to do?
What is paramount for businesses is being able to stay abreast of changing requirements. IT systems and IT budgets need to be able to support this. At the same time, it is an illusion that existing legacy systems are getting retired and replaced by something different in a big bang.
In the context of how business systems are built this means that executives need to work with their vendors and implementation partners to make sure of the following:
- The current status of harmonization of the vendor’s applications. Do this with a focus on applications that are currently in use and those that might get implemented in the near future.
- The intention and roadmap to de-siloisation of the vendor’s and ecosystem partners’ applications.
- The knowledge and experience that the implementation partners have built up to help migrate existing applications from a current silo state to a harmonized state.
- Having a good indication of efforts, cost, and timelines involved to gradually migrate the implemented business applications into a more harmonized world. This needs to be based on business priorities and constraints.
Once this is established, it is time to go into harmonizing the business applications suite, taking into account business priorities. This includes both capabilities that need to be developed and pain points that need to be removed. To accomplish this, it needs a “Think big – act small” mindset with frequent goal-readjustments to accommodate for changing priorities. I have frequently written about this. Important in this case is to maintain constant communication with the vendor to avoid surprises and to keep aligned with longer-term priorities.
Questions? Ask me!
