“If your time to you is worth savin'; then you better start swimmin'; or you'll sink like a stone; for the times they are a-changin’.” Perhaps no truer words have ever been mentioned by Bob Dylan, because it’s clear that the times are a-changing. In the software world, disappearing are the days of the deployed solutions and archaeic database-type solutions used to manage huge amounts of data and responsibilities, or disparate tools to manipulate the multiple service needs across the organization.
Current and future technology advancements are accelerating faster than organizations are able to adapt. So much has happened over the past few years in the service management space, specifically, and in software development, and there are many more changes to come. Organizations must find a way to future proof themselves or face some tough realities. For our part, to future-proof and ready ourselves for these changes, much has been going on at TOPdesk. With our newest version that was just released a number of changes have taken place. Recent changes can be summarized in one sentence: Continuous improvement on architectural and at the organizational level by leveraging DevOps.
Historically, most changes made by TOPdesk to its solution and organization have come because of initiatives made by the development department. For instance, when the development department started applying agile methodology some years ago, terms, such as “SCRUM” and “standups,” quickly became very well known throughout the organization and spread to other areas, including our sales and communications departments.
Since we’re a software company, this move to an agile solution-focused approach was not surprising. These protocols are core to our processes; much continues to evolve in this area. And while much inspiration comes from business-to-consumer giants, such as Facebook and Netflix, we continue to develop fresh ways to enhance user experiences and helping organizations become more lean, efficient and forward thinking.
Leading up to our newest version, the biggest change we made was moving to a continuous improvement model. We started making the change by looking at our organizational needs and the needs of our clients. We conducted interviews with a variety of stakeholders, out of which several points of attention were identified. These points basically proved the desire for change; and that is where the continuous improvement process came to fruition. Doing so gave us a formal process to get through the changes. The interviews made it very clear that changes to the architecture had to be made, but also that after those changes, the organization would be out of sync so other changes would have to be done there as well to match again.
The whole process works in tandem, implementing changes one step at a time while ensuring the technology is not disconnected from the organization.
A very important goal that came out of the stakeholder interviews was to move to a cloud-based horizontally scalable architecture. For that we moved from a monolithic approach to a service-oriented architecture with the services sitting behind APIs. There are two major things we focused on to accomplish this: replaceability and versioning. We basically started focusing more on requirements or what we should be delivering instead of focusing on how to implement it. Prior to this, in the old code-driven approach, we had been limiting ourselves because code is not only short lived; once written you are also stuck with it. By implementing replaceability, we are ready for rapid changes: Anything new that comes out can immediately be used and deployed, it’s just a matter of releasing a new API.
Versioning and replaceability is our attempt to make us future proof as such an approach really enables scalability. In the words of one of our architects, this approach is bringing us back to the feeling of the industrial revolution; it is such an exciting time with new things lining up one after another, we are confident that we are driving the train, not running behind it.
Another hot topic that came out of the interviews with stakeholders was about the speed of development and more specifically the speed of delivering these new developments. In the old waterfall approach, there were always bottlenecks along the way; for instance, things that had been developed a year prior, sat on the shelf. When finally ready to be tested, issues may have been identified that could have pushed the release even further down the calendar.
With the changes in the architecture, continuous delivery became a goal and DevOps enabled the process to get there.
Continuous delivery means that since new builds or versions of the software are constantly available, as a software company, you have to be able to trust the code and what has been created at any given time. Where in a waterfall approach changes of long periods are combined and then tested, a continuous delivery method means there is now a change in priorities to defining critical workflows that have to be covered by automated tests, creating more security of the quality of the version.
Also, a continuous delivery approach changes the impact and responsibility of a developer as they are constantly required to think about testing. When there is a new build of the product every day and something they created does not work, there can be no further builds until any issues are resolved. To improve the quality controls, critical workflows have been defined, and the notion of “blockers” has been introduced in the development prioritization process. All-in all the planning remains much more flexible now.
We clearly see an increase in the quality we’re now delivering, created by this change, as well as more automation and better collaboration on the product, with a focus on user friendliness. Of course, this change did not happen overnight. At TOPdesk, we implemented these changes by putting together a group of people from different disciplines and creating a community focused in helping create more automation.
The organizational changes did not stop there. Because of the shift in responsibility and the much more scalable and flexible approach, our product management team also got more room to work in a much more strategic way, enabling us to focus on themes or the bigger picture instead of modules.
Internal collaboration also got a lot clearer. Where in the past there already was clear feedback and communication from support and consultancy to development, these lines got a lot shorter as the pace of developments and delivery increased. Feedback is much quicker both ways now.
A nice example of results we have accomplished can be found in our newest version. It is being continually deployed to our SaaS customers and offers a great deal of new functionality to enable the Shift Left strategy not only internally within the service management department, but also towards the end users or customers (what we call Shift Left Left). Because of our organizational and technological changes, we can implement these functionalities, taking into account direct feedback from our customers and all of our departments so we are able to publish the best product available.
Thus, trends and requirements that come up can immediately be communicated, developed, delivered and deployed without sitting around on a shelf for several months while we wait for the next delivery date. Now our process truly is agile.
We are future proofing through continuous improvement and delivery. We have started this continuous cycle and the process by interviewing stakeholders and implementing changes they asked us to make. Now we will always be available, always ready to help our clients serve their customers in a more agile and efficient way.