Our primary goal as an organization is to provide our users with the best software and services we possibly can. But with the many unexpected challenges lurking around every corner, we also need to be ready to provide the best support to our users whenever they should need it. With that in mind, we also need to evolve as a company to be as efficient as possible. Because efficiency for us, is efficiency for you!
In order to get that efficiency, we’ve evolved our Core Software Development Teams to work in a DevOps manner. Our focus is: “You build it, you run it”. Put differently, we want to bring our development teams closer to the user in order to deliver the most efficient solution for the issue by connecting you to the person who can help you best as fast as possible. So, we’ve also reorganized our Operations Team.
In the past, we had Operations Engineers embedded in our System Engineering Deploy Teams only. The bulk of the investigation was done in this team without referral to our Core Software Development teams. But this siloed way of working leaves room for untapped potential since the wider team doesn’t get involved to come up with better fixes, mitigations, and more informed thinking when new developments take place.
That’s why we’ve now split the Operations team into 3 separate units.
- The Central Ops Team will process and triage all incoming cases. They will provide “quick win” mitigating actions if they can, but they will also identify the cause of the issues and ensure that the appropriate tasks are assigned to either our System Engineering Deploy Teams or Core Software Create teams as soon as possible, making sure the right eyes are on the issue. They also take the responsibility to have high-level visibility on a situation and all its associated tasks, so that you can always get a comprehensive update.
- Core Software Create Teams now have IOC engineers assigned to take up the management and communication of the issues in collaboration with the Central Ops team while the issue is assigned to that team. They will ensure effective and regular communication with the user, and help simulate and investigate the issue. Bringing these elements close together will also enrich our development process and thinking, and enable us to have the user story more readily in mind during the entire procedure.
- System Engineering Deploy Teams now have the same arrangement as Core Software Create Teams.
Customer DataMiner Reporting (CDMR)
We encourage all users to connect to CDMR (Customer DataMiner Reporting). This is our preferred method for examining the state of a remote DataMiner System as it enables us to work quickly and lessens the need to connect directly to user systems.
System Performance Indicators (SPI) & Cloud-connected Agents (CCA)
Increasingly we’re adding more and more SPIs (System Performance Indicators) to the DataMiner software. For Cloud-connected Agents (CCA), this anonymized SPI information can be sent back to Skyline to give us even more information about the state of a system. With both CDMR and SPI/CCA in place, we can spot an issue before the user even knows there’s something wrong, and recommend or immediately take corrective actions.
If you have any questions about this transition or technical support in general, please contact techsupport@skyline.be.
Hi Simon,
It looks like a positive change from our perspective. I’m a bit confused about the setup, though. In the beginning, you say that you’re moving to a DevOps model of “you build it you run it”. However, the rest of the article goes on to explain how you are creating separate Development, Operation, and Deployment teams, which seems contrary to that philosophy. I guess this is an iterative step towards that philosophy and we can expect further changes and evolutions in that direction, or have I miss interpreted it?
Hi Russ.
Thanks for your comment. I should explain that the Deploy and Create teams as we call them both develop different things. Create teams are working on the core software and Deploy teams are working on projects in top of the core software. Those two teams have always existed. The change is the move of the IOC teams, so they can focus on issues relevant to their domain or job only.
Coming back to your other point. The idea is that a Deploy team is like anybody else creating their own solution with DataMiner, that could be someone outside of Skyline too. Focusing more on our Deploy teams being able working independently allows us to further enhance the usability of DataMiner as a platform in general.
I hope this clarifies things.