One of the largest challenges facing commodity traders is joining up their complex operations across teams with very different roles. Achieving collaboration across departments can lead to fewer errors, better decision-making, improved asset turnover and ultimately greater profitability.
For a long time, technology has been helping teams within these organisations manage their processes better and create greater efficiencies, but now the challenge lies in connecting these teams together and closing the loop between trading, risk, finance and operations.
Whilst there are many different potential technological solutions to the challenge, they can be broadly divided into two contrasting approaches. A monolithic system attempts to provide the software every team needs in one place, such as when an ERP provider adds a CTRM module. Monoliths therefore can be inward-looking as the expectation is that no external software is needed.
Ecosystems such as Gen10’s CommOS take the opposite approach. They are inherently outward-looking as their purpose is to connect the highly specialised tools and technologies your business needs, no matter who supplies them, so that your connected technology behaves as one complete commodity management system.
| Monolith | Ecosystem | |
| What is it? | A single system that operates in total- or near-isolation to run your business processes. | A connected group of software systems that allows each business area to use the best software for them, but the technology behaves as one connected system. |
| Amount of choice | Once a monolith has been chosen there is limited, if any, choice over new technologies that will integrate. You may be limited to this vendor’s software if you wish to integrate across teams. | Ecosystems are designed to give you greater choice and flexibility. They allow each business area to choose the best technology for them, whilst maintaining flows of data between these technologies. |
| Customisation | Broadly speaking, monolithic systems are older and more rigid in their data structures so can be less customisable, or can require lengthy and costly development to make changes. | Customisability can vary considerably, but for many ecosystem providers, this is one of their key product benefits. |
| Adding functionality | With limited options for add-on systems, additional functionality may not be possible, or may require a lengthy and costly development project. | This can vary but generally ecosystems should enable you to add more apps, add customisation or incorporate new technologies into a vendor’s software more easily, and ideally allow you to work with the vendor to decide which option is right for your business. |
| Working outside the system | If functionality doesn’t exist or is too inflexible to work with your business processes, teams do not have much choice but to use unconnected or offline tools such as spreadsheets, creating errors and risks. | If a tool doesn’t provide the features you need, you can incorporate one that does. New technologies can be integrated into the ecosystem, so using new tools does not mean working outside the system. |
| Implementation | Implementation projects can be lengthy and impact the entire business as they often involve large-scale changes. Change management and project management processes can vary greatly. | Implementation can occur one business area at a time to minimise disruption. Modern cloud systems can be implemented 100% remotely and in a matter of months, even when onboarding multiple systems. |
| Investment | Fees and pricing structures can vary widely, from a large up-front payment to ongoing Software-as-a-Service contracts. Generally, if the software will require more custom development or a longer implementation, this will add to the cost. | Pricing varies but each piece of software can be better value than the equivalent monolith module. As each component is procured separately, pricing can be considered in each tender, rather than being locked in to one supplier. Shorter implementations can help to reduce costs. |
| Delivery model | Historically have been delivered on-premises. They are increasingly available in the cloud but not necessarily cloud-native, so may not capture all the benefits of cloud computing. | Can vary but expect the best ecosystems to be cloud-native, making the most of the flexibility, scalability and data processing power of the cloud. |
| Future-proofing | Likely to be developing their software for the future, but they can be limited by building on an older system that is harder to develop. | Designed to allow clients to make the most of new technologies as they evolve by integrating with them. Often cloud-native meaning that future development is rolled out faster. |
| Expertise | The company provides a range of software modules so expertise is spread across the business. They may also supply a wider range of industries outside of commodities, which can provide new perspectives but can also mean that vendors have breadth rather than depth of expertise. | Ecosystem technology providers have one area of expertise and focus on doing this really well. They are often less well-known than large monolithic systems so rely on their depth of expertise and being able to truly understand their customers and meet their needs. |
| The technology summarised | The goal of managing the full commodity lifecycle in one system would be an advantage, but is only realistic if your processes match the system’s often rigid workflows.
The monolithic design can make it difficult to add new software and prevent effective digital transformation if this is not the case. |
Ecosystem vendors don’t expect to be able to solve every problem across every business area. They encourage you to choose the best-of-breed technologies. The ecosystem shares data between tools so that users and data scientists have the same information as if they were using one overarching system. |
At Gen10, we believe that ecosystems are the best way for our clients to onboard the best technologies for their needs with agility.
Monolithic software can mean disjointed processes and copying information between systems if functionality is missing, or being limited to modules that do not support your business’ unique processes. We prefer the ecosystem approach because we believe that technology should work around our clients, not the other way around.
Want to read more?
Subscribe now for monthly updates
By submitting your details you agree that we can store your data and communicate with you. You can opt out of these communications at any time. Read all in our Privacy Policy.
