Enabling Application SaaS Operations using Development for Operations (DfO)

As most application software companies move to a SaaS based solution, the changes required for this strategy can be dramatic. One of the fundamental change is relooking at operations. Unlike on-premise where the product was given to the customer and the responsibility of running the software was with the customer's IT team, this responsibility falls on you. While the new stream like DevOps (Development and Operations) can help you in the short run to put out fires, a dedicated focus on development for operations should be in your strategy, specially if you have a delay between developing features and pushing to production. The goal is to use this as one of the stream to feed into the Development for Operations (DfO).

Application SaaS

A prospect buys your software to become a customer, from then onwards the single point of contact for the customer is the Operations (Ops). This journey can start with being a prospect if there is a trial period. Various operational agreements between the company and customer are met by Ops. A common organization structure for Ops is to have dedicated teams for Level 1 (L1), L2 and L3. L3 usually involves an Engineering team along with Product Management to provide a hot fix to resolve the issue.

Development for Business

This is the current setup in most companies, the entire focus of development is to service the business of the customer. The entire team of Product Management, Engineering, and Learning is dedicated on servicing the needs of the customer. This is depicted as the above the line specifically targeted at the customer.

Development for Ops

This is the one that most companies have in different forms that need to be elevated to a dedicated team. Sometime they just buy a software and assume it would provide these features without realizing that any software need to be tailored to your product. If you look at the picture while a dedicated team was present to satisfy the features of the customer, the operations team of L1, L2 and L3 would also need a dedicated team to satisfy the features that they would need in order to satisfy the needs of the customer who reach out to them.

The predominant features needed

• Keeping the lights on
• How to setup a customer and keep them receiving the latest features?
• Why a designed feature given to the customer is not working? Namely how fast can they identify when a feature is not working and why?
• How fast can it be remediated so that customer can continue their business?
• How can we make sure that this is resolved so that it doesn't occur again?

So one should setup a parallel team similar to the business feature team to make sure that operations features are done with its own Product Management, Engineering and Learning representatives. Since the priorities for both the teams can vary as "Development for Business" is going after the market while the "Development for Ops" is trying to delight existing customers, it's recommended to keep them separate. If the maturity of the teams have reached a state where this distinction can be managed; then merging of teams can be considered.

DevOps Pitfalls

While bringing DevOps can provide a few of these features temporarily, mixing operations with development would eventually take its toll and fail.

The predominant reasons are

Clash of Mindset: Operations by definition is 24x7, the prime focus of operation is not to resolve but to remediate (resilience) so an engineer would switch between these sides, not to mention the odd hours. The engineering rigor required to release a feature that could affect multiple customers is not the same as remediating or resolving one customer.

Policing the Police : since it's the engineer who needs to find and fix the issue, there is little incentive to make the finding easier so that this can be self serviced by others including peers.

If you currently have this setup, use this team to get the current happenings in operations and push these features to Development for Ops team.#

Interplay between Ops and Development for Ops

There should be a tight interplay between these two teams, the customer for development for Ops is the Ops. The release cycles could match the operations till the product reaches an acceptable operating status. The Ops is dedicated and focuses only on operations using the features developed by the Development for Ops. The Development for Ops is dedicated and focuses only on developing features for Ops.

The Development for Ops should first focus on features to make sure that Ops can do the resilience before providing features on resolution. This is required as if this is not done to enable the Ops engineer, the Development for Ops engineer would be spending time putting out multiple fires instead of spending time to resolve. So the goal is to make sure the Ops engineer can easily find the issue and remediate for resilience.

The features developed should have the same rigor with QA as the features developed for business. The learning representative in this team is to make sure that the Ops team members are properly trained on these features and are ready to be deployed in front of the customers.

Disclaimer

This is my personal view. The thoughts expressed here represent my own and not those of my employer.