What is DevOps?
DevOps is an acronym for Development-Operations, where it is deemed that Product-Engineering (Development) & Operations teams should work collectively towards a common goal, by removing the iteration of enhancement-logging, internal-Trouble-Ticket and Bug-fixing flow to reduce the overall time from the Requirements Raised till it get Delivered and deployed into the Production-environment.To further improve the DevOps methodology, a new type of Tech-resources have been introduced; "The DevOps Team".
"A DevOps team comprises of Tech-resources who are capable of understanding the Business Requirements, Operation Challenges and also the Product Development. The main goal of DevOPs is to reduce the overall time between the Requirement Raised by Customer & the Deployment into the Production."
 |
| DevOps Formation |
Hence DevOps team essentially a blend of Business-Analyst, Operation-Manager/Engineer and Product-Engineer and a resource is considered to be the best fit for DevOps, if he/she is having each of these competencies available. That is the reason now a days, market is thriving for DevOps Engineers, DevOps Managers etc.
How DevOps Work?
DevOps team usually works closely with Customer/Client. They help the customer for ease of Operations, by delivering traditional Operation & Managed Services tasks, along with taking the new requirements or enhancements/ bug-fixes and then same team works to Develop, Test, Deploy and Deliver the new enhancements in form of a Configuration Change, new Build or release inside th production environment. |
| CI-CD Operations |
Hence DevOps essentially backed with an Agile Software Development model along with CI-CD delivery. By adopting Agile, it can be ensured to prioritize the most critical and immediate requirements and then developing the same at a faster pace. CI-CD delivery model ensures that time taken between "Code Written by Developer in Development Environment" & "Deployed inside the Production Environment" should be as low as possible. For CI-CD, a delivery pipeline approach is adopted, where a logical build delivery pipeline is maintained between the Vendor's Build/Release Repository and the Client's Build Repository. However, this pipeline is further extended at both the ends. At Vendor's end the Build-Repository is connected with Development to Test to Performance Setup and at Client's end it is connected to Test, Staging, Pre-production and Finally to Production Environment.
It is also important to make sure that the Test environment at both the end (Vendor & Client) should have automated test cases for regression, functional & performance, so that the release time can be minimized.
Why DevOps?
From the above sections, it is almost clear that main goal of DevOps is to minimize the Delivery time. To be more specific;"DevOps is used by the industry to minimize the time taken in process of Requirement raised by the customer to Writing a Code to Test to Deliver to Deploy!"
The other objective of DevOps & CI-CD is from the business perspective. Consider a scenario, where an operator releases an RFP for some immediate and some futuristic requirements. Now in a traditional SDLC/Waterfall model, the Vendors submit their proposal considering it a one time delivery and try to cover everything. It is very likely that vendors will not be having every functionality Out-of-the-Box available at that time and hence will consider the delivery timeline accordingly. For this case, let us consider they propose a timeline of 9 months. Hence operator now need to wait for another 9 months to get the requirements delivered and use them. Even if the most immediate requirements are available Out-of-the-Box in vendor's solution from day one. On the other hand vendor will invest a huge amount in product/ solution to develop the delta requirements and will not be having any cash-flow until the project starts. The another problem with this approach is that when Operator releases an RFP, they try to predict the futuristic requirements, however in many cases the actual requirements may change at the time of actual project delivery and at that time, Operator will suffer.
Now, in an Agile based DevOps delivery model, Vendor can work with Operator/Client to prioritize all requirements, in order of urgency and then can propose a project plan where customer can Go-live with the bare minimum immediate functionality within 2 months or less and by using a DevOps based CI-CD driven project plan, customer can have incremental delivery of new features after end of every sprint. If vendor can work smartly on this, they can show that all RFP requirements will be delivered within the same 9 months timeline, but not as one go, but on incremental basis and customer can get more and more benefits after each delivery. This is a win-win situation for both; Vendor and Operator. The Operator will be having their most painful area addressed immediately and Vendor will be having a Cash flow running from the Day-One of the Project and can use the project revenue for product development itself. In this model it is also possible to cater the change in requirements during the project delivery itself. After each sprint delivery, customer can come up with a more urgent requirements or they may ask to re-prioritize the whole feature-list. Customer may even decide that certain functionalities, which are part of future planning, are no longer required. This provides a great flexibility and maximize the return-on-investment done by Vendor and Operator.
Where to Apply DevOps?
"CI-CD and Agile development are the essential ingredients for successful DevOps model. Hence, when we talk about DevOps, we obviously mean DevOps + CI/CD + Agile."DevOps is most suited for the Solutions, which are close to the User, like User Interface, Engagement Framework, WebSelfCare, Mobile-Apps etc. These are known as IT solutions in Telco world. Since most of requirements in this span can be broken down into smaller features easily and hence can be delivered independently and incrementally, it makes DevOps a perfect fit for IT framework. For example, an operator wants to have a mobile app where user can View his profile, Change Plan, purchase a device, a SIM card and register online with Payment options as Credit-Card, Debit-card, Netbanking, Mobile-wallet and by Cash.
In a traditional Waterfall-SDLC, the delivering all of these requirements in one shot, will cost more than 6 months, easily. But if vendor follows the DevOps approach, they can deliver all the requirements incrementally, by prioritizing them, as per clients requirements.
Here these many requirements can be broken down into smaller features and then prioritized. Further all the requirements can be delivered independently on incremental basis as below:
1. A Mobile App for User's Account Summary
2. Option to change Plan
3. Option to Purchase new SIM with Payment only by Cash
4. Integration with one Payment gateway with Payment Method only by Netbanking
5. Listing of Mobile-Devices from One Vendor only
6. Listing of Mobile-Devices from 2 more vendors
7. Payment Method by Debi/Credit Card
8. Integration with logistic partner for Home Delivery
9. Payment Method by Mobile Wallet
10. Integration with more Payment Gateways
11. Integration with Market-Places (Amazon, Flipkart, Walmart etc.)
If we look closely, both Vendor and Operator are getting great benefit out of it. Vendor is having enough cash flow to use the same for Product development and Operator is having their most critical requirement addressed on the very first delivery, while ensuring a timely delivery of all requirements at a predefined sprint interval.
Where not to Apply DevOps?
Even though DevOps is a great industry practice, it does not suite well for every Telco Solution. Consider a case of a Network Element like PGW, where an Operator wants to have a support of Wi-Fi to LTE handover. Even this requirement can be broken down into multiple smaller features (or user-stories) and can be delivered to operator, but those can not be used as a feature in a production environment, since complete Handover support between Wi-Fi and LTE (and Vice-versa) will take at least 3-4 months of development time and minimum 1 Month of Testing and Integration/IOT efforts. Hence using a DevOps based CI-CD model will actually not give any benefit to the Operator, since it is unusable until the complete support.To clarify more, let us take another example of PCRF requirement. An operator requested to have a support of P-CSCF restoration inside PCRF. Now to support it a usual Development effort is minimum 1 month and then 15-20 days of Testing, Integration and IOT. In short it can not be delivered and used in production environment before 2 Months from the date of requirement raised.
Using DevOps for a solution segment, which demands a delivery cycle of more than 3 weeks, is not suitable and actually costs more to Vendors, since the cash flow is driven by delivery time in DevOps. For example, if a feature delivery happens after 3 months, vendor will have a cash crunch, for those 3 months and can end up hanging between Agile and Waterfall.
The another consideration is 'How critical the segment is?'. Upgrading a MobileApp or a SelfCare Portal is easy and takes very less time to complete and also it is not a business critical segment. If by some mean, the MobileApp is down for sometime or some features are not available, customer can still use the other services of the network. But if a critical network segment (like PCRF, OCS, PGW, Node-B, Transmission-Link etc.), is down during the upgrade, it is a direct loss of revenue, service and user experience to the Operator. Hence, frequently upgrading such critical elements is to be avoided.
Conclusion:
"DevOps framework looks very compelling to adopt, however just like all other methodology DevOps is also not meant for everything and if not adopted for perfect solution, it does more harm than that of Waterfall."It is crystal clear that DevOps is a great framework to adapt, but for the right segment, which is IT in case of Telco.
" 'One size CI-CD and DevOps is a perfect fit for all segments', is not only an immature statement, but also a Suicidal decision for both Telcos and Vendors!"
Based on my market analysis and Telco research, I have come up with below diagram.
 |
| Delivery Timelines for Different Network Segments |
This gives a perfect view what should be a typical timeline of an enhancement/feature delivery for different network segments. If we look closely, it is evident that the solutions, which are closer to user, have shortest delivery timelines and as we move away from the user interface and closer to Network Elements the delivery timeline increases respectively.
