One of the biggest issues I see in the market is the notion of procuring the perfect platform. When talking to a new or prospective client for the first time I will often hear “We have this mess on Product A, Database B so we’re thinking of moving to Platform X”.
In my experience there is no single platform, product or framework that solves all the Information Technology problems a business will encounter. Every business is different. Every challenge is different. Every context is different.
A Boulevard of Broken Dreams?
The technology landscape moves faster than most others. Every other month there is a new buzzword to learn or capability to evaluate and with so many vendors to choose from, it’s little wonder many organisations end up with multiple ‘best of breed’ platforms in their environment that overlap or have duplicate functionality. Alternatively, there exists a plethora of technology initiative briefs that remain unfulfilled due to decision inertia e.g. fear of another long expensive procurement cycle.
To avoid an unhappy ‘boulevard’ of wasted or poorly leveraged technologies, platforms or products, sometimes a business must reflect on a confronting question: “If others can achieve success with Product A, why can’t I?”
The Boulevard is littered with pretenders and people aimlessly wandering and expecting the answer to their troubles to be presented to them. An alternative direction is to head to the Marketplace – where choice abounds but where success is defined by having a clear vision of the business need that you’re wanting to fulfil, and a flexible but purposeful intent of procuring what is needed to fulfil it.
Business Context
To prepare for the ‘Marketplace’, having a complete understanding of the business problem that is trying to be solved by ‘installing or switching to Platform X’ is fundamental to the success of any technology approach. Some important points to consider are:
- What is the current state?
- Existing technology investment
- Existing skill set
- Business strategy and vision
- Status of your market and industry standards
- What does success look like?
- Performance requirements
- Customer impact
- Staff impact
- ROI
- What is the history?
- Who are the stakeholders and what are their experiences and opinions?
- What hasn’t worked up to now and why?
- What are the options?
- Facts versus hype.
- Technology lifecycle, likely to be 3-5 years at best.
Performing a proof-of-concept (POC) to see how a technology, pattern or approach would work in your context is always a good idea before committing to a significant investment. A POC shouldn’t fear failure, instead establish the ability to pivot the architecture quickly as a guiding principle up front. This will help to avoid “platform installation” thinking and long procurement lead times to change architectures.
Embracing Change through Architecture
Every technology, approach or pattern has pros and cons which may change with different circumstances, so creating a rigid ‘ivory tower’ reference architecture ahead of the installation of a platform should be avoided. Instead, plan for architectures to constantly or frequently evolve and arm teams with the patterns (including process patterns), tools, ecosystem, operating culture and working environment to enable them to solve unexpected challenges as they’re presented with them.
Take microservices for example. Although the microservices approach recommends a polyglot architecture (using several languages) this should be taken into consideration with the other aspects that make up the microservices approach such as the inner vs outer architecture. Polyglot does not mean installing another expensive platform and building everything on top of that. In fact, the polyglot approach is specifically an admission that there is no such thing as a single perfect product or technology and each microservice should use whatever solves that challenge best. It means expecting the architecture to change and evolve.
Utilising ‘Cloud’, ‘No Code’, ‘APIs’, ‘Microservices’, and ‘DevOps’ all have merit, but chasing these buzzword technologies without gathering and digesting facts and reflecting on how and whether they’re suitable for your business challenge and context will lead to more ‘broken dreams’. Software-led rather than principles-led architecture can lead to anti-patterns like swapping out APIs for soap web services and implementing microservices with shared persistence and compute layers, which will only hamper agility and blow out costs.
In Conclusion
Expecting an external solution to arrive and solve your challenge will mostly lead to disappointment. The software you purchase will only perform as prescribed or as instructed. The best way to help your business thrive is to expect change and plan to embrace it constantly without having to run frequent long and expensive procurement cycles.
