Is the company working on an Enterprise Toybota Solution? Is that just unwittingly happening, or was this a conscious choice? Is there awareness of the path that the solutions are heading down on? Intriguing questions, aren’t they? This candid discussion will strive to balance the high level and just technical enough to be readable.
What is Enterprise Toybota Solution, you may ask? This will be clarified in just a moment. First, on the origin of the term Toybota, which featured on Top Gear’s car boat challenge episode. Top Gear is a British motoring magazine and factual television programme, more about it on their website.
In the episode that features Toybota, the three presenters were set the challenge of building amphibious cars and using them, to get to, and then across a two-mile-wide reservoir. Jeremy Clarkson built what he called a Toybota, a name he had made up and that’s the definition used in this post.
Jeremy’s co-presenters, James and Richard also made some interesting choices as well, those can be viewed via the Wikipedia page linked at the end of the post.
Some observations on the Toybota:
- a pickup truck, designed for hauling a certain category of cargo on regular roads, has been fitted with an oversized boat engine
- it is not a proper boat, and it is no longer a useful pickup truck
- the design is brittle, particularly when in the water
- during the race, video link at the end of this post, it seemed to be speeding its way across the reservoir only to overturn as it manoeuvered to dock at the pier
- if it comes to it, servicing such a thing is going to be costlier in any scenario than if it were kept to its original design
- the regular means of extending capacity will not apply to the Toybota, it would require additional steps with uncertain outcomes.
These observations could be adjusted to describe enterprise software solutions where customisations weren’t designed and implemented carefully enough. Top Gear’s Boat Challenge was hilarious as the show episodes often were, a funny quote at the time was that Top Gear is an entertainment featuring cars. That certainly rings true.
Jokes aside, deploying enterprise solutions can lead to costly outcomes if not carefully managed. Large enterprise systems such as Commerce, ERP, CRM, usually implemented within business environments in flux, sometimes suffer from inadequate design choices. The rest of this post will dive into a contrived commerce example to illustrate some implications of customising a product design. The issues highlighted easily apply to other complex enterprise systems such as ERP, CRM, HR Systems, to name a few. The same forces are at play, similar dynamics lead to similar outcomes.
A Contrived e-Commerce Site
e-Commerce software available in the market are typically complex, the implementation involves making several architecture and design choices. One insidious aspect is that the first wave of e-commerce software were modelled after traditional physical product commerce. Many companies though sell digital products, which are typically more flexible and varied than physical articles. As a result, customising e-commerce software is very common, teams just need to get it right. Consider the diagram below, for illustration.
The diagram depicts components of e-commerce software, it is not meant to be complete or even realistic, the aim is just to guide the discussion that follows next – a real-life e-commerce software may contain hundreds of components in multiple deployment units. In the diagram, standard product features are shown in a dark colour, the orange-reddish colour shows places where the vendor catered for customisation. The block sizes are chosen for ease of reading, in reality, vendors cater for much smaller customisation than the relative size of the boxes show.
Complexity in the Data Layer
Enterprise software, to be useful, need to manipulate data. Therefore, customisation tends to necessitate reading and writing data. The component diagram puts the spotlight on the area where data customisation may be applied. The next diagram illustrates how data customisation works, again a contrived example.
In the example, the Customers entity may bear additional attributes, CustomerOrders and Customers entities may be extended with whole new entities, all such extensions can be set up according to company-specific needs. Such data model customisations are made to support functionality customisation at the application layer.
Vendors cater for customisation both at application and data layers, it is up to companies to make decisions on what they need to customise, preferrably within certain limits and guidances – that’s where it gets interesting.
Vendor Software Implementation
Large vendor software providers offer tools and guidance to their customers. Very large vendors such as Salesforce, SAP, Microsoft, sell software so complex that they sometimes have created specialised configuration and programming tools and languages.
Large enterprise software vendors such as SAP, Microsoft, Oracle, and so on, provide extensive education and consulting services, directly or through a network of partners, for implementing their products. The data model behind some products are so complex that the vendors have created specialised configuration language and tools for them, SAP has ABAP, Microsoft Dynamics has BCL, for example.
Getting complex software implementation right is absolutely about having the key skills and expertise on board, the right approach to making trade-off decisions, and the ability to fine-tune the sunk-cost equation all the time. People, Processes and Technology must be orchestrated in perfect harmony with the right vision within the business context, to reap the rewards of such an expensive endeavour.
To Configure or, To Customise
The adage, with great powers come great responsibilities, prominently comes to the fore here. Complex enterprise software comes with powerful extensibility and customisation features. Despite the billions of euros spent in carefully crafting and designing large software, the reality is that we live in an ever-changing world and every business is unique in a somewhat similar way that every person is unique. Every large software implementation, therefore, entails lots of trade-off decisions between configuring and customising. Getting the decisions right often makes the difference between an expensive write-off, sometimes running up to hundreds of millions of euros, and successful deployment where a company can then focus on running their business and contemplate return on investments.
When does an entreprise system implementation starts to become a Toybota Solution?
In situations where extensive customisations at the data and application layer is done, the software implementation may become unique and brittle. Without proper guardrails, it is not unusual to see multiple small applications being built around vendor software, taking customisations so far out that the outcome veers way off from expected normal operations. When this happens, technical issues increasingly become costly to diagnose and fix, vendor software maintenance becomes much more involved, it becomes harder and harder for teams to even keep up with regular upgrades and patching, and that’s where one can consider it an Enterprise Toybota.
Enterprise Toybota is defined, in this post and probably nowhere else, as vendor software customised to such an extent that the deployment and running costs start to threaten business operations viability. Such solutions typically exhibit several of the following characteristics:
- The implementation timelines incurred significant delays and costs beyond initial planning and budget estimates.
- In some unforunate situations, despite heavy investment and delays, users are often disatisfied with what they consider to be bare minimum feature set and acceptable operational behaviour.
- The customisations introduced features that are so unique to the company that the product vendor either declined providing support or was forced to taylor a custom approach to the deployment site in question.
- The vendor’s scheduled or regular product updates and upgrades cannot easily apply to the implementation. In some extreme cases, such upgrades could represent effort so high as invoke comparisons with the initial implementation costs.
- As a result of customisation, the company has to ignore or forego taking advantage of recent vendor product improvements and features. This becomes a regular theme causing increasing frictions and frustrations across users and leadership teams.
- Runcosts and timelines are so significant that company leadership finds itself frequently caught in suncost evaluations and decision-making.
- In most extreme scenarios, as can be abundantly found in the industry news, the company leadership made a decision to write-off an implementation and take another course. In well publicised situation, a company to write €500 Millions euros of tech investment off! – in this case, however, the forces at play probably had complex organisation aspects in the mix. Nonetheless, it’s a cool sum to be writing off.
Not all Toybota Solutions are equal, they can be categorised into models, Accidental Toybota, Adventure Toybota, Incidental Toybota, or Challenge Toybota (a putative hackathon scenario).
It is an Accidental Toybota if the customisations were the result of last-minute tough decisions due to extreme circumstances. Examples of extreme circumstances might be regulatory, critical business milestones combined with oversight in product capability.
Adventure Toybota may emerge where highly opinionated implementation leadership, often disregarding vendor recommendations, pushed ahead for significant customisations. Should this come from a misbalance in trade-off decision making, several other issues might also be found. It could also be that leadership knowingly accepted such implementation and is comfortable running it.
Incidental Toybota, possibly the more common, arises from teams having the confidence and strong preference for adjusting vendor software to a high number of company-specific requirements. A typical trade-off in implementing vendor software is whether to adjust work processes to product features or the other way around. Incidental Toybota cases would tend to tip the balance more often towards the latter, surprised to discover at some stage that they may have gone too far with customisation. Incidental Toybota may be considered the most accomplished and productive scenario here, it does have some implications that will be illustrated shortly.
One scenario, not discussed, is Challenge Toybota, closer in spirit to the TV Programme from which the term was borrowed. Such a scenario might be occurring in niche contexts, not likely in real-life company life, however. Toybota is simply an amusing way of discussing complexity in this post.
Expensive lawsuits and reputational damages can result from botched large software implementation. When the implementers haven’t got their decisions right, vendor software typically gets the public shaming, careers may be damaged, jobs may be lost. Prominent vendors are acutely aware of this situation, they have spent lots of money in educating their customers and partners, they run extensive training and certification programmes to help with this challenge, though none of that is a silver bullet.
Expertise cannot be faked, mastery cannot be achieved by just reading some documents then whizzing through certifications, the latter arguable can also be gamed. The stakes are so high that some vendors would not allow deploying their software unless certified project leadership and governance is in place.
Even in the presence of perfect governance, whatever that means, software can have defects and shortcomings arising at unfortunate moments, sometimes causing teams to improvise and patch systems. The more vendor software is customised, the more costly it becomes to run and support it. The longer a customised vendor software runs and has been evolved at a company, the more complex and costly it gets to run it and keep it evolving. This latter explains why, for example, large systems at financial institutions evolve and give rise to a wild ecosystem of patched up and bespoke solutions yielding rigid solutions that can barely be “touched”. In this case, part of the reason is that solutions outrun the lifetime of the skills and expertise available in the industry, calling those Toybota may be a stretch.
Cloud to the rescue
The rise of cloud-based software as a service, SaaS, is giving new life to what it means to deploy and adopt complex enterprise software. With SaaS, the vendor is in control of the way their software is deployed, and this gives them a chance to progressively curate and migrate their customers away from unwieldy on-premises deployments. Vendors will still allow customising their software, but the options will be more restricted and highly curated if they are to avoid simply aggregating the world’s complexity at their inevitably limited resources. This section will draw more illustration from SAP, which also offer complex e-commerce software, but presents some unique learning points to talk about.
Attractive as it might be, migrating customers to the cloud presents a whole host of challenges in itself. Notably, this comes with both Cloud Transformation and Agile Transformation challenges, both eminently organisational level considerations. Vendors will want to trade carefully since they are more focused on selling their own technology services, they often achieve this by partnering with consulting outfits and getting closer to customer implementations.
Migrating customers to the Cloud is more manageable in green-field situations where little or no significantly customised on-premises implementations exist. Takes SAP, for example, they provide a very sophisticated and comprehensive delivery framework covering the entire lifecycle of deploying their HANA Cloud system. Given that SAP HANA software is an evolved reincarnation of their erstwhile on-premises offering, it is inevitable that feature parity is not a one for one match. Cloud offers SAP a chance to reimagine some features whereas others simply take time to be reimplemented for the Cloud. SAP has tackled this challenge in their implementation framework, the question is whether their customers are sufficiently taking advantage of the wealth of assistance available. This means that SAP has to find a way to get involved in consulting services in their customer implementations.
One last example challenge, drawn on SAP technology, is with long-standing companies such as manufacturing or large retail companies. There are documented examples of companies with decades-long SAP implementation that has millions of lines of ABAP code – as a reminder ABAP sits at an even higher level abstraction than the base system itself. In a situation like that, even SAP’s well-curated implementation tools will not be enough to assist in migrating such customers to the Cloud. The complexity is unimaginable, migrating such customers to the Cloud might require a special one-off solution that only SAP can build together with the company. This challenge is in the league of its own.
Some Key Questions
To wrap up this discussion, a number of questions can be raised when considering complex enterprise software implementation.
- How would a company balance trade-off decisions in implementing complex enterprise software? Does this need to be considered during vendor software selection as well? How and why invest in something else if a vendor software was already chosen?
- What does it take to deploy enterprise software sucessfully and cost effectively? Is there an established formula?
- Hows does a company assess the health and keep the pulse of their enterprise solutions built on vendor software?
- How does a company determine which Toybota model they are dealing with, is it Incidental, Adventure or Incidental? Should customising the data model be limited or avoided, if so, how would one cater for specific needs and wants? What are any alternatives to customising vendor software?
- Are such complexity factors only applicable to large vendor software, what about home-grown systems that grew to become large and complex?
- What about the sunken costs, what if so much has been invested in the solution that it would be an expensive write-off if it come to that? How does a company determine the right point and place to make a call on writing off such tech invesment?
- Should the company rely on or require their software vendors to guide them with their organisational challenges as well? If not, how will this be managed while adopting a vendor software?
These and numerous other questions arise. The answers aren’t trivial, they cannot be cooked into ready-made recipes. A general rule of thumb is to prefer configuration over customisation, how to go about it is craft with flair for organisational and technology complexities. It is really a journey involving conversations at the right level, at the right moment, with the right expertise involved.
This post provided a brief anatomy of the enterprise vendor software customisation, presenting some factors impacting the lifetime and total cost of ownership of solutions. It takes mastery to lead and manage complex enterprise software implementations. Customising vendor software is normal and usually unavoidable, due to business imperatives and as a result of conscious and rational decision making. When done right, as is always the intention, the benefits can be considerable and sustainable. In situations where the outcome should fall below expectations, the implications can also be signficant. Companies should choose their Toybota model carefully and decide how long they intend to stick to it.