Is there anything worse than a crashed Endpoint?

STEP is likely to be a core system for any organisations that have invested the time and money to implement it. Consequently, there will be large quantities of data going in or out at various times, in many cases complex Business Rules must be adhered to/executed. The last thing the Business needs is one or more of these processes failing. So why do integrations or event processors crash? And what happens when they do?

What does STEP capability look like in your organisation?

A sneak peek into the workings of an innovative STEP MDM development team. I will discuss some of our responsibilities as designers and developers of the system, and how the Business are able to leverage this capability to continuously expand the benefits that STEP delivers..

How do you stay an expert in your own area of expertise?

Stibo Systems talked about Innovation, Partnerships and Sustainability as the three pillars of their corporate strategy. Sometimes these high level values can feel very abstract when you’re wrestling with the challenge of maintaining your in-depth knowledge of your STEP system at the same time as adding new features and enhancements to satisfy your business users.

Why Data Veritas, why now?

Data Veritas is me trying to help myself get better; by reflecting, by exercising my professional chimp, by documenting past glories and failures. Along the way it may help others. Either others like me, STEP Consultants, or perhaps “down-in-the-dirt” business users. You know… the ones who actually have to use the system once it’s been delivered.

What does STEP capability look like in your organisation?

Do you have Stibo STEP implemented in your business? How long does it take for an annoying “error” message that pops up on the Web UI from time to time during your daily tasks to be fixed? Do you have somewhere to report these errors? Do you ever have any expectation that they will be resolved?

Over the last few years I have been working as part of a STEP development team at PLUS, and previously I’ve worked on 8 separate client STEP solutions. The team arrangement and associated processes that support our work with STEP at PLUS are rare, but they work remarkably well, so I thought it would be interesting to discuss how we do things and hopefully initiate a wider conversation with other Stibo customers about how they work with STEP from a system ownership and maintenance perspective.


Our team has multiple functional roles within the domain of system ownership. We are responsible for the following:

Firstline support for the system – If any user experiences an issue during their work, they will report the issue to our internal service desk and relatively quickly the ticket will come through to us as an incident that needs analysis, diagnosis and correction. It’s possible that as part of our incident acceptance process that we identify that the issue is outside of our control, in which case we will hand over the incident to the relevant party, e.g. the Enterprise Service Bus, Stibo, or perhaps to the owner of another system within our enterprise infrastructure. If it’s within our control we will add it to our board and the ticket will be picked up and fixed in a timely manner (dependent on priorities).

Advanced Data Management – As a team we have a diverse talent pool, from software engineers to testing operatives, from university graduates to 30+ year loyal employees, and from solution architects to business analysts. As a result we are well equipped in many areas of STEP, and we’re available to the Business to assist with more complex data management tasks, mainly associated with executing Bulk Updates with complex requirements. Our aim is to remove this requirement on our team by equipping our business users with the tools and knowledge to be able to execute these tasks independently, but for the time being we are happy to help.

Continuous Feature Delivery –  The organisation has a healthy backlog of projects that need to be implemented across the business. Many of these are related to regulatory requirements associated primarily with the increasing uptake of Environment, Social and Governance initiatives by the Dutch Government (presumably some of this comes from the EU level too). From a personal perspective this increasing prominence of sustainability initiatives is a great thing for society and the environment, however it does place a burden on organisational compliance that often filters down to us on the STEP team. Initiatives like this along with other business-initiated requirements or top down strategic directions mean we need to ensure that the STEP system evolves to fit the needs of the organisation. The technical complexity of configuration in STEP can make the implementation of a continuous feature delivery pipeline challenging. Many other organisations I’ve worked with lean towards a project-led framework whereby the system is updated on timescales of a year or two, sidestepping the need for in-house development experts and condensing the changes into a time-limited project. At PLUS we have built a development operation that allows us to give our business users the confidence that the system will continually satisfy their business needs and they won’t need to “make do” with a system that is out of sync with the Business. Importantly, the cadence of the forces leading to desynchronisation – evolving regulatory requirements (e.g. ESG), the volatility of customer preference and innovations in the technology sector – are higher than ever. It is vital that organisations ensure that they put processes in place to help them keep up with the pace of change. Implementing one or more trendy pieces of software may give a short term boost, but the chances are they will rely heavily on your foundational data that lives in your MDM system. New features will be needed in STEP too.

Solution Optimisation –  In addition to new features, we get regular enhancement requests from our business users. Sometimes these enhancements can be done by the business users if we give them the tools to do so. As our STEP system at PLUS is gradually renewed, we put this requirement at the forefront of our design thinking. Providing our power users – in our case Data Stewards – with the ability to enhance the experience of the business users alleviates pressure on the development team, gives the Business increased agency and ownership over the system and just generally makes us all happier! As a combined team we can place more effort in the challenging new requirements or tackling bigger projects that come along, allowing us the headspace to continue to deliver high quality functionality.

STEP Upgrades – This responsibility should drop off given the roadmap Stibo have defined around the SaaS future of STEP, but as it stands we are still managing the STEP upgrades internally. When I joined we were quite a large number of versions behind the latest and we were soon to be placed “out of support” if we did not upgrade, so we collectively reviewed upgrade documentation, pooled our thoughts, and planned the work needed to deliver the upgrade without an interruption for our business. We’ve consistently protected against any major issues following an upgrade through good planning, and we’ve even been able to further optimise the solution and make improvements passively as part of this effort.

Technical Debt – In software development, the accumulation of design decisions and suboptimal code results in a system that is difficult to maintain and augment. STEP is not immune to these issues, and even non-code configuration can present challenges to delivering new features. In my opinion the main cost with a poorly architectured STEP system is the consumption of time. The PLUS STEP system was implemented by a global SI firm and was originally part of a dual MDM and ERP implementation. The ERP renewal failed, and many rigid requirements from the legacy ERP system were consequently built into STEP. I can see that we are doing a good job of passively reducing this technical debt solely by having a robust process around our development. We do our JavaScript coding in VSCode and track our work in git linked to Bitbucket and JIRA, our ticketing system. This has given us great visibility over our development process and allowed us to carry out Code reviews of our work.  This has been an eye-opener for me; giving me access to powerful tools and enabled me to continuously improve the quality of my work. The process also provides us the opportunity to boyscout the existing codebase; much of which was produced by junior, fresh out of university developers. As you can imagine, there is plenty of room for improvement! Stibo has always maintained that STEP is a ”configurable” software platform and does not require “development” in the traditional sense. This may be strictly true, but I think organisations are missing a huge trick by discounting the benefits and power that can be unleashed if STEP is treated in the same way as any other developable software system. You really can turbo-charge the quality, quantity and frequency of enhancements if you embrace a DevOps culture. Even if STEP is not strictly compatible with the core philosophies/requirements of the DevOps movement, much of value can be borrowed. I’ve been calling this concept STEPOps; in truth this is probably a misnomer, because we’ve lost the “Dev” bit and retained the “Ops”, which should probably be reserved for the Business in this context, but I think it communicates the sentiment well. Being agile, innovative and pro-actively implementing robust development best practice brings benefits for both business users and commercial colleagues. Rapid and flexible implementation of new features means we can avoid costly standalone projects and the stagnation of systems relative to competitors; the commercial impact this approach has will soon become very clear.

So, there’s a flavour of what we do at PLUS. What are other people doing when it comes to STEP ownership and maintenance? Is there anybody out there who feels isolated and unable to benefit from the team collaboration I enjoy at PLUS? What aspects I’ve mentioned above are priorities for your Business? I’d be really interested to hear some other viewpoints/opinions on how businesses should work with Stibo STEP. It seems to me Product Owners are very hard pressed at the moment, the responsibilities are growing and often spanning multiple systems (mind blown), so I’d love to hear from you Product Owners as well as from people managing/working in the STEP team.