OpsDev is Coming

Developers, end users, investors, analysts and the competition were all eager to learn what Apple had in mind to maintain its leadership and market share at the recent WWDC in San Francisco. No new mind blowing product was announced, and Apple’s stock price actually fell. But there was a common theme that recurred throughout many sessions: user experience. Apple is continually aligning all products and apps so a user with multiple Apple products can have a seamless experience while switching from one device or app to another without losing the user’s context of what they are doing. Instead of focusing on the product features or product specs, the company focuses on its customers’ experiences. Apple has a knack for this kind of thinking. While its competitors are touting the large number of megapixels for their cameras and the number of cores in its newest smartphone model, Apple is comfortably showing beautiful, inspirational pictures taken by the iPhone without even mentioning any of the phone’s technical details. We all know that we no longer can live our day without a smartphone. Plenty of tasks that used to take a lot of time — because the information was not accessible from our fingertips — are now accelerated to the point of instantaneous gratification. For example, in order to find a good place to eat in a new town before owning a smartphone, I used to try to think of people in my network who had previously visited and asked them for a recommendation. If I could not think of anyone, I would ask the hotel receptionist once I got to the hotel. That meant I had to go to the hotel first even though I was extremely hungry. And I had to pull out the Google Map that I had printed way before I had left for the airport and boarded the plane to find my way to the hotel. Today, I can just pull my iPhone, turn on my Yelp app and once I find the place I want to go, I can then use my Waze app to direct me to the restaurant. And even better, Waze can recommend taking a detour route because the most direct route has a massive traffic jam due to a major accident. Then, I can use my OpenTable app to make a reservation at the restaurant so I can ensure my table and, at the same time, collect the open table rewards point(s). Now, Apple thinks that our lives can be even more efficient. Instead of using so many different apps to accomplish the series of tasks to get me to a nice restaurant in a new town that I have never visited before, the company envisions the day that I use Apple services to accomplish the same goal without having to open multiple apps. This vision requires a new product or service design paradigm. Any company that wants to offer a capability to be included in the Apple service to offer the personalized user experience must think OpsDev instead of DevOps. Let me explain.

Enter OpsDev

Let’s assume we are building the following service for an appliance company that makes smart refrigerators. Here is outlined sample outline of user’s experience: Your car recognizes you as you climb inside. The smart refrigerator at home has notified your smartphone to stop and pick up some groceries. It gives you three options. The first supermarket requires no detour, but it does not have your favorite flavor of ice cream in stock. The second supermarket has a bit of a detour, adding 10 minutes driving time, but it has all of your favorite brands for the items in your shopping list. And lastly, the third supermarket will add 15 minutes driving time, but has all your favorite items in stock and additionally offers a discount coupon that will save you $12 off your grocery bill. Once you pick the supermarket, the car displays the most optimized driving route on its multimedia infotainment system. In the not-so-distant future, as companies attempt to capitalize on offering an integrated personalized user experience, several data sources and services must be integrated together: the grocery list from your smart fridge, inventory data from supermarket chains, coupon data from food companies and supermarket chains, traffic and geospatial data. These different data sources are provided by different providers and hosted in the different data centers. To access them, you will need the different credentials and the different processes and the different APIs. The designers for this personalized service must understand the different service level agreements (SLAs) from the different data sources and services because the user experience will be impacted if the integrated service has issues retrieving the right information in a timely manner. As a retailer, you don’t want the end user to make the extra 15 minute drive only to find out that their favorite products are out of stock and the grocery bill is actually $20 higher because they cannot use coupons and or because they were forced to buy substitutes. As you can see, the delivery of such personalized software services impacts the design paradigm and now must be inverted. While DevOps tends to start with the developer-led challenges (e.g., code review and code standards, build management and continuous integration), it ultimately sits in the wheelhouse of operations teams once the application is promoted into production; OpsDev begins with the end in mind. Once we understand the interdependencies of the different data sources and its availability, we can then design the component that ties everything together. Additionally, the smart fridge software is constantly updated. New sensors are being enabled to offer the different kind of data. The personalized service must also keep up with the new kind of data so the service can offer different personalized services. The frequency of software updates for the personalized service may be driven by the software updates from the other services that this personalized experience depends upon. So the designer must develop an automated system to receive update alerts from the services that it depends on and immediately make recommendations on which component of the service will be impacted by such update, and when the personalized service must be updated in order to be synchronized with the rest of the services.

What is OpsDev?

OpsDev means that the dependencies of the various application components must be understood and modeled first before the development process begins. In addition, the consideration for infrastructure stability, environment modeling, security and audit/compliance measures are first and foremost. Application components are stubs and they do not need to be in their final forms. Secondly, the environments in which the components will be deployed for production must be modeled. Thirdly, the processes to deploy the various components to the target environments must be automated as much as possible. By doing the above, the design and development teams can replicate the application and environment models, and automated processes in the development and test phase in a consistent way. By easily replicating the production environment and processes in development and test, the design, development and test teams will know the production constraints and parameters very early on, such that they develop the applications with those constraints and parameters in mind. In the traditional model, a lot of time is wasted troubleshooting applications that have been approved by QA in the staging or production data centers. And often times, the deployment must be cancelled because the approved applications are dead on arrival in the staging or production environment because the environments are slightly different. Furthermore, in the OpsDev approach, a release pipeline that orchestrates the deployment of applications to dev, test, staging and production environments will not only accelerate the overall process of deployments in various environments through automation and parallelization, but it will also improve quality by minimizing error-prone manual tasks. The release pipeline can aggregate several commit pipelines that make up a release. A commit pipeline is the individual application pipeline that orchestrates the continuous integration and continues testing. A release may contain several applications developed by several project teams. Each project team can have its own commit pipeline. The collection of commit pipelines from the different teams for the different applications can be aggregated into a release pipeline. The release pipeline will understand the interdependencies among the applications and will marshal those applications into staging and production environments. The release pipeline can have manual and automatic approval gates to make sure that the release is approved and is going on the right deployment schedule. From the OpsDev approach, the release pipeline can be integrated with ITSM (Information Technology Service Management) and APM (application performance monitoring) solutions. The release pipeline can seek for an approval by sending the electronic bill of materials of the soon-to-be deployed applications to an ITSM solution (“service desk”) and open a change request ticket. The IT director will get the notification of the upcoming deployment via their ITSM dashboard. The ITSM solution can then marshal the request through the ITSM review and approval workflow. Upon the approval by the IT director, the ITSM solution can send the signal to the release pipeline to schedule the deployment. Upon successful deployment, the release pipeline can inform the ITSM solution about the successful deployment by updating the status of the corresponding change request. The release pipeline can also be integrated with an APM solution. The release pipeline can deploy the applications in the staging environment and kick off the APM solution to monitor the performance and load testing. The APM can report whether the applications can meet the SLA. If so, the application can move forward with the deployment into the production environment. Otherwise the release pipeline will be stopped and an alert will be generated about the failure of meeting the target SLA. In the production environment, the APM solution can monitor the transactions, performance and load. When it reaches a certain threshold, the APM can notify the release pipeline to add more server capacity by deploying more applications in the data centers. Upon receiving the request from the APM, the release pipeline will create a change request to the ITSM solution. Upon the approval from the ITSM solution, the release pipeline deploys the same set of apps to more servers to bring in more capacity. When the capacity is no longer needed, the APM can notify the release pipeline to turn off some servers and return the servers to the pool for other uses. As you can see, the proliferation of IoT and user-experience-based mobile apps, companies cannot afford to develop products in the traditional development paradigm because of the increased interdependencies of SaaS services and application components (software in devices, software in data center, and mobile app and web app) that make up a single cohesive user experience. Apple, in its crusade to make our lives more efficient by encouraging Apple developers to think of user experiences first and offering the integrated Apple personalized services, may accelerate the mind shift from DevOps to OpsDev.   This post originally appeared on IoT Agenda