Long gone are the days when companies were likely to buy the entire stack of enterprise tools from their ERP software vendor, Mika Tanner pointed out in his recent blog post.
There has clearly been a switch from ERP-driven to best-of-breed software shopping and development. Adding to the equation, software buying power has switched towards business departments, and methodologies have shifted towards rapid and agile. The compound effect is that quick proof-of-concepts based on a broad range of technologies may spawn like mushroom in rain. Great success or architectural madness arises.
Many companies are still struggling with getting it right. In this post, I will highlight 5 topics to consider and pitfalls to avoid.
1. Be precise about division of responsibility and ownership of data
When a process gets sprinkled across multiple systems, each with different degrees of data sophistication, it can be difficult to choose which system should be responsible for executing certain tasks or leading a certain part of a process. Likewise, it can be difficult to decide which system should be the master of each data entity, and to which extent data should be replicated back and forth between systems.
Failure to address these topics with determination and clarity will cause problems in the short term (not getting the most out of your best-of-breed stack) or long term (e.g. data quality deteriorating instead of improving over time). Even if you don’t see the problems immediately, things may get out of control when you try to develop the next solution top of the jungle. (Putting an API on top of the jungle will not make the problem go away – see below)
My advice:
Be precise about the division of responsibility between systems. Be equally precise about ownership of data. Sounds simple, but many enterprises have serious challenges with this!
2. A simple API does not dissolve complexity
The startup world thrives on lean cloud apps interconnected over APIs. API talk also thrives among enterprise architects and salesmen. Best-of-breed buying is fueled by the assumption that anything and everything is easy to connect and extend, if there is an API.
Don’t overestimate the magic of APIs. APIs are terrific, but by no means a silver bullet to easily manageable architecture and walk-in-the-park projects. Publishing a complex process through a simple API does not make the complexity go away. It momentarily hides it from the people developing on top of the API. But in the bigger picture, there is still a full, hairy, complex stack of systems to govern and respect when you make changes to your processes.
My advice:
Build enterprise APIs, build enterprise software on top of APIs, but don’t forget that you are developing and maintaining full-stack solutions, which require full-stack governance and understanding. Choose partners and vendors who are up to the job.
3. The platform is the new monolith
Relying on the ERP as the center of everything is out of fashion, because it’s too monolithic. The same goes for building enterprise software too tightly bound to the ERP. There is plenty of buzz about how companies should build a digital platform as a foundation for rapid innovation. Buying software, add-ons or custom development that runs on the platform keeps your architecture coherent while helping you stay away from the evil ERP monolith.
But the risk is that your platform – be it a bare-bones cloud PaaS or a rich enterprise ecosystem in the cloud or low-code environment or a thin API layer – becomes the new monolith. If the platform sinks, down goes everything built on top of it. Many companies are currently facing massive re-implementation exercises as their “once best-of-breed but now sadly outdated” platforms are eroding, pushing massive chunks of enterprise software into sunset land all at once. Are the hot platforms of today less prone to future erosion? I don’t think so.
My advice:
Build on a platform when it makes sense, but always ask yourself: what happens the day when we want to or have to get rid of the platform? Can we re-deploy or do we need to re-write / re-purchase? Build independent, loosely coupled systems or services when your platform-monolith gut feeling warning bells go off.
4.Know your license terms
Software vendors want to make money. They want a huge share of your wallet. No surprise there. What may come to a surprise to some, is that e.g. an ERP system may come with licensing terms which are quite restrictive in terms of integrating with 3rd party systems. Recent news about a company having to shell out considerable amounts of money due to “indirect use” has brought more attention to this topic. Rightly so.
My advice:
Ask very precise and frank questions about licensing. Both from your 3rd party best-of-breed vendor, and from your ERP vendor.
5. Be bold enough to pull the plug
Lastly — quick Proof-of-Concepts are the stuff that agile business driven IT development is made of. Being able to try out new stuff without tedious planning helps you innovate faster.
But beware: PoCs which are set up in an ungoverned results-over-planning fashion, and never make it to a controlled transition to production at scale, also tend to become the stuff of enterprise architecture nightmares. Unless they are terminated at some point.
My advice:
Be bold enough to pull the plug on systems when appropriate. Get rid of solutions that never were designed for long-term, company-wide, future-proof usage. Alternatively, ensure that there is a solid path forward for the PoCs that you want to keep.
