After a recent presentation, I was asked “What can you do with Structr that you can’t with other software?”As we were short on time, I just replied with “You can do anything, but in much less time.” I wish I’d have had more time for a more thorough response like what I’ll detail below.
In this blog post, I’d like to take the opportunity to talk about the special magic of our project at Schleich, the well-known German toy manufacturer, and explain why this project was only possible with a platform designed and built for flexibility. If you’d like to read about the project from a business perspective, read this case study.
The use case – semantic product management – is a good example for complex models with many connected entities, so everything written here also applies to any other sufficiently complex use case in software development.
The Challenges
From a developer’s perspective, the challenges in this project were not only to migrate a central, business-critical application including gigabytes of production data to an entirely new technology and system architecture but also to clean up the data model and shrink it from almost 350 classes to less than 200, while at the same time developing new applications with new functionality and data interfaces.
The reason we started with an existing model was that the only way to access the data was a full dump in RDF/OWL format, and for the user interface, we could only analyze it from the outside by using the user interfaces provided by the existing system.
Something you learn over time is that you can get the semantics right only if you sit down together with power users, talk about every single use case in detail and really think it through. That implies that you, as a developer, don’t have the slightest chance to get the software models right before people actually use it, give feedback and make you adapt the software to their needs.
The knowledge about the data and processes in an enterprise is mostly concentrated in a relatively small number of people. It is important to identify this group of people, involve them as early as possible and make clear that they shouldn’t expect a final software on day one after the roll-out.
Treat Change as the Rule, Not the Exception
When starting a project, you have to consider that the first version you build is mostly not any better than a more-or-less educated guess. It is only based on what the customer said they want before they see the software, and what you, with your limited knowledge about the use case, make of it. The consequence is that the real work starts after the first iteration.
If this agile approach is properly reflected in the project planning and your communication, the involved people are positively surprised by the benefit to have an influence on the software, to make it “their” tool, rather than thinking of it as an unfinished product.
The amount of modifications and extensions requested by the users after rollout typically goes through the roof once you allow them to speak out any wishes. Without a technology stack that was designed and built for flexibility, a project like this will quickly fail because you can only process a small fraction of the desired change requests, so the rate of closing issues is just so much lower of the rate new issues are opened. It’s race you cannot win.
Needed: A Software Stack Built Around Flexibility
Software is an approximate representation of the real world and always a compromise between exactness and manageability. In the real world, products, components, materials and their properties and semantics, people’s workflows and schedules, project requirements, system parameters, services etc. are complex systems with non-linear dependencies. That means that the number of relationships typically exceeds the number of entities.
The most classic software and database architecture approaches fall short because they don’t treat relationships as first-class citizens, forcing software architects and developers to (over-)simplify the reality when mapping entities, relations and workflows onto abstract, static models because they have to minimize the number of interdependencies to keep the system manageable on the technical level.
Real-world systems change often. If your software architecture cannot handle change effectively, it is doomed to fail in a project like this.
What You Can Do with a Flexible System
With a very flexible software platform like Structr, you cannot only do simple things in very short time, like extending the data model by new attributes at runtime or adding new elements to the user interface. You can also add new classes, relations and additional functionality, from simple things like a new type to more complex changes in the data model. At some point, you will need a refactoring of the data model because it turns out that the initial model was either too simple and missing complexity, or too complex and not performing well.
In both cases, these kinds of change requests lead to really complex modifications on the technical level like changing the class inheritance or migrating data from a simple attribute to a new complex type.
In this project with Schleich, a major task was the reduction of a cluttered data model taken over from the previous system and grown over time, to a reasonable and clean new core model, without sacrificing functionality. In many other cases, simple things like a new field here and a new button for a shortcut there were what made users happy. If they don’t have to wait weeks or months to see new features, and get bugs fixed within days or even hours, the user acceptance rises.
Summary
The project at Schleich was technically and conceptually challenging. The agile approach would have failed without a really flexible software platform like Structr, and Structr wouldn’t be possible without an enterprise-grade, schema-flexible graph database like Neo4j.
Want to Learn More? Meet Us at GraphConnect Europe!
If you are curious now and want to learn more about Structr, please come to this year’s GraphConnect Europe on 26th of April in London. Dr. Andreas Weber will be talking about the project from a business perspective, and I’ll talk about the technology behind it. The Structr team will also be there, and we’ll be happy to answer questions, demonstrate Structr and hear about your use cases.
Structr is a Gold Sponsor of GraphConnect Europe. Click below to register for GraphConnect and meet Axel and the rest of the Structr team in London on 26 April 2016.
