Total Cost of Ownership: 7 Tips to deal with Complexity
So you made it through the first part of this series on Total Cost of Ownership (TCO)? Congratulations! If not, don’t worry, it’s not a prerequisite for this blog post.
In the previous installment we discussed the relevance of TCO in a VUCA world. It turns out that it is arguably more important than ever, but also that it hasn’t become easier. We promised to cover some specific aspects of TCO more in depth. In this installment; Complexity.
Complexity is a Fact of Life
A couple of years ago, one of our customers had to reinvent herself. A decisive management recognized they had to become a different company to remain successful/relevant in a VUCA World.
Having a number of poorly integrated siloed tools required for them to rethink their entire IT landscape. When discussing possible to-be architectures and roadmaps with them (also presenting these to the Board of Directors) inevitably one question often arose: “Does it really have to be this complex?”
A number of consultancy firms were contacted to provide studies to verify this, and there was a clear common ground that all competitors recognized: a certain level of complexity is necessary to meet the demands.
In other words, complexity is a given.
Start Simple
None of the studies started out with complex figures. If you fly high enough, your birdseye view will always be simple.
TIP 1. As a starting point, try to consider your IT Landscape as simple as possible.
Something like this list should be recognizable:
There is a limited number of high-level business applications (if you abstract sufficiently this is typically a handful of key value-chain systems)
There are some integrations with Suppliers (of goods, services or data)
There are some integrations with Customers (certainly in B2B, otherwise ‘integrating’ with your customers via a portal may be the only component there)
There is ‘magic’ that makes it all work together, compliant, secure, efficient, … (Often depicted by just arrows, completely missing (abstracted away), or simplified by vague boxes (typically thin layers at sides/top/bottom))
A more detailed view
One of the worst mistakes that can be made next, is skipping drawing a more detailed version of this overview (maybe separate diagrams per domain or ‘block’), and jumping straight to a component selection (buy) or project scopes (build) for the blocks in the overview. To help you detect whether you have stopped shy of the proper decomposition you can use control questions like these:
Do you have software running (check licenses or cloud billing information, for instance) that either partly fits everywhere or fits nowhere?
e.g. tool stack used for Identity and Access Management - IAM
Do your projects have dependencies that seem to fall out of scope of any other projects or teams?
e.g. Consent Management: our project scope needs to take into account what user preferences are, but the process (,tools, requirements) where the consent should be asked and managed is not, nor is there another project or software already present that takes care of this.
When you make ‘buy’ decisions, is it difficult to find specialized tools to match the requirements, so that the bigger suite vendors are all that remain?
Have you explicitly drawn the transversal items, i.e. supporting blocks that are typically enablers for your key value chains, but may not be top-of-mind?
e.g. project management tools (both planning and follow-up), HR tooling (workforce mgmt, time registration, absence management, …), Security tooling, Identity and Access Management, Privacy tooling, Integration Tooling (ESB, API manager), Decision Support Systems (Data Warehousing, ETL tools, Batch job Schedulers, BI tooling, analytics tooling, Data scientist playgrounds, …), ALM related (devops tools, version control tools, build agents, orchestrators, …), ‘Quality’ Tooling (data quality validations, monitoring, logging, service desk, …)
TIP 2. Use control questions and information about your current application landscape to validate the required level of detail.
Still not sure? Cloud providers are a magnificent additional way of validating your level of detail. AWS, Azure, GCP, … all have overviews of their offerings. Look at how they are categorized, and they will provide ample inspiration and guidance of what ‘blocks’ you need to consider.
TIP 3. Even if not using cloud services, still look at the cloud provider offerings for inspiration.
Below are 2 examples (AWS and CNCF):
Resulting Logical Application Landscape
Invariably, the result of the previous steps and tips is a more complex landscape than you probably envisioned (or the realisation that you already have so much more than you were aware of). Having 50-100 software packages + bespoke applications + cloud services is really no exception.
So, there you go: “Complexity is a given”.
The Consequences
There are many consequences to this complexity, but let’s focus on 2 important ones: Quantity and Integration.
Quantity
The sheer amount of applications that you need evidently has a direct impact on Total Cost of Ownership of your ecosystem. The typical budgeting exercise (yearly IT budgets, Roadmap estimations, Project Budgets) is underrated with 30%-40% because of this (or suffers from the equivalent in scope creep).
TIP 4. If you have no time/expertise in drawing the correct landscape, add 40% contingency to your budgets.
So, if you really can’t establish a correct detailed view (we don’t condone), you will have a more correct view on your TCO if you add 30 to 40% to your overall IT landscape related estimates. Better take the 40% side if you are in the kind of organization that cannot (or does not want to) invest in a detailed IT landscape overview (AS-IS or TO-BE). As a motivation for this budget you can always list some of the examples from the control questions that aren’t covered in your estimates.
Note that we are certainly not claiming this the best approach to take, but on average it will yield a more accurate estimated TCO based on empirical findings.
Integration
If you are part of an organization that does a lot of its own development (hired or in-house) the complexity of the ecosystem in which applications have to be deployed has a direct impact on estimations. Either you have a separate ‘platform’ team (or hired services local or in the cloud) that incur direct costs, or the development teams are left to deal with these integrations in the business scope projects, which means additional requirements leading to additional costs (“Integrate with IAM tool”, “Publish business changes on Event Hub”, “Provide archival mechanism to offload data to Long Term Storage", …).
TIP 5. In estimates, take the IT landscape details and validate for each component whether there is an impact/integration required.
When buying commercial software packages, or selecting open-source or free alternatives, there are 2 specific items that will improve your control on TCO (and a qualitative IT application landscape, for that matter).
Firstly, there are plenty of great software packages out there, but they often have wildly varying features, so understanding in your ecosystem which features/requirements are important to you will help you better evaluate the proper fit. As we discussed in the first article of this series, the ‘best fit’ should always mean lowest TCO (given the same business value).
Secondly, try to remain aware of the overall picture. There are past selections, but you also have ongoing processes in various stages (RFI/RFP (Requests for Information/Request for Proposals), POC/POT (Proof of Concept/Technology), Pilot, rollout, …), as well as planned selection processes. Someone needs to keep the overall view. If multiple selection processes have the same tooling or even vendor in their short lists, there is an added benefit for selecting the same in both tracks (even if individually they may not be the first choice). In the open source world, the same goes for communities; there are clear stacks that work really well together, and that can offer a big advantage when used together. Companies in full digital transformation initiatives usually do well to not only have the awareness of the overview, but even translate it into validation/scoring items in each selection process. Depending on the stage of other selections the scoring and phrasing will differ, but it can always be taken into account.
other tool already selected (e.g. looking for a tool for specialized marketing campaigns, already using dynamics for plain CRM): “How (well) does your tool integrate with MS Dynamics?”
other selection ongoing: “How (well) does your tool integrate with Dynamics?”, “How (well) does your tool integrate with Salesforce?” , … (use shortlist)
other selection planned: “What integrations with CRM packages does your tool support out-of-box? Are there optional/additional connectors + their cost?”
Note: Be aware of commercial pitch versus reality: we have seen several examples where in practice (during POC/POT) it turned out that a component from a suite from the same vendor integrated more poorly with another component from the same suite/vendor than a competitor’s component. Especially the larger vendors with aggressive Merge & Acquisition strategies need a due diligence on commercial pitches (but that's an article for another time).
TIP 6. Convert your ecosystem tools (current and future) to evaluation items during selection processes.
These newly introduced scoring items (and their weights) should directly translate in the best/lowest TCO (given same business value).
You can't do it alone
Sofico is one of our customers that has been making the challenging transition from a single-siloed application (Java with Oracle/MS SQL backend) to a real integrated ecosystem approach. They have been on this journey for a couple of years. Has it been easy? Not by any stretch of the imagination. Is it necessary? Absolutely.
As a true software development company (with a very open culture) they applied many of the above tips by having highly skilled technical architects that really understood the impact of such a transition, and a management that listened to them with enough patience and motivation to understand all the aspects. That brings us to the final tip.
TIP 7. Establish a network of ‘believers’ that represents all layers of the company.
If you are a manager, make sure that you listen to technical people that discuss the complexities of an ecosystem (yes, it can be a challenge 🙂). If you are a technical architect, make sure that you use examples and actual cases to highlight complexities and hidden costs. Say: “Remember last year when our online shop was down? That was because that data was delivered from supplier X. This year we are becoming reliant on external data from 10 suppliers instead of that one, so we need to do something to mitigate the risk of direct impact.” And please, don’t say: "We need to write an abstraction layer API, a central data lake buffer, and then a custom transformation connector for each supplier”.
Outro
There you have it, 7 straight-forward tips on how Complexity can be incorporated in your company best practices to get a better grip on TCO. Do this well, and it may just give you that needed edge over your competitor.
Of course, we are very interested what your experience is or has been applying these tips, or how you currently go about budgeting. Let us know in the comments or by PM.
If you applied these tips, or in another manner, arriving at a Total Cost of Ownership that far exceeds the available budgets: don’t fear. We have successfully helped companies reduce their ecosystem related TCO by a factor 2 to 10, so get in touch with us.
Last but not least, keep an eye out for our next installment because we’re getting personal! We'll discuss how people affect TCO and how they can be taken into account.