devopsy.kinsta.cloud

Author: Anshu Premchand

  • Shifting to Product-Centric Work in Utilities

    Shifting to Product-Centric Work in Utilities

    Large organizations across the services spectrum are transforming from project-centric operations to product-centric way of working. Customer centricity is driving this transformation, as product-centric organizations put customers at the center of everything they do. Such a transition is largely dependent on how information technology solutions are deployed in the said organization.

    This article looks at the importance of a product-centric way of working for utilities organizations, particularly the power sector, which is looking to transform customer interactions by revolutionary use of new digital technologies and solutions such as smart metering and smart homes.

    At the onset, power utility organizations should focus on shifting to a product-centric way of working in areas that show promise to deliver innovation and digital enterprise such as customer analytics.

    Fig. 1: Current State of Play in Most Power Utilities

     

     

    Fig. 1 outlines the current state of play at most power utility companies, where organizational silos and application silos lead to customer challenges in understanding the products and services offered, as well as productivity losses and an increase in reaction times to changes demanded by business and regulation.

    In most power utilities, silos exist in business units which are reflected in how the applications supporting those business units are organized and managed. This leads to duplication of effort, work and applications, as well as a waste of time and resources. Customers are often confused about multitudes of service offerings and various channels. There is also an inherent delay in responding to challenges thrown by changes to regulation and/or business environment.

    This is changing, though, and one can look at the “meter to cash” processes for a reflection of market realities and customer empowerment.

    In our experience, there are four key drivers of a move toward product-centric model:

    • Digital Core – to evolve, innovate as well as leverage cloud, DevOps and agility to support the business.
      • DevOps practices and agility from ideation to sunset.
      • Encourage innovation.
      • Digital ready systems.
      • Focus on Product value.
      • Lean planning and maintenance.
    • Intelligent Enterprise – to optimize the cost and delivery of services and encourage innovation.
      • Automation to support business agility of the power utility.
      • Autonomous operations to support power distribution and customer management.
      • Decisions based on insights drawn from customer and market data.
      • Focus on the innovation of products, services offered and customer engagement.
    • Experience Quality focused on improving customer experience.
      • Product centric service delivery.
      • Business agility.
      • DevOps practices.
      • Experience centricity.
      • Product and experience-focused metrics.
      • Command center that is aligned with the business.
    • Service Management and integration for scalability and unification of service delivery in the power utility while retaining a multi-supplier ecosystem as needed.
      • Continuous improvements.
      • Standardized deployment and integration management.
      • Collaboration in a multi-supplier scenario.
      • Service lifecycle management.
      • Information technology service delivery performance management.

    This transformation to a product-centric organization ensures that processes, people, workflows and decisions power the power utility’s ability to:

    • Customize services and offers.
    • Improved and faster response to customer requests.
    • Consistent and distinguished cross-channel experience for customers.
    • Boost productivity.
    • Eliminate waste.

    Shifting to a Product-Centric Model

    The product-centric model of delivery uses Agile, DevOps and Lean principles for strategic planning to ensure uncertainties and lack of information do not derail the delivery of services to end customers. A product-centric model places importance on relatively shorter horizons of budget and effort planning over massive planning at the beginning of a financial year. This is important, as a power utility is likely to be able to plan better for a quarter at a time rather than a complete year, particularly in the current economic climate. This not only ties well with the goal of business agility but also ensures improved planning and budgeting, as there is more information available about business goals a quarter at a time. The new teams organized around business capabilities, as shown in Fig. 2, then plan the product backlog, execute, test and deliver business value
    to business and customers continually.

    Fig. 2: Shifting from technology to business-aligned value streams or product-centric organization

    Power utilities also need to change and improve their technology-centric solutions to help with forecasting and data analytics. The product-centric organization helps with this goal by identifying gaps for closure and aiding the creation of self-organizing teams that then take on the goals of the organization to address all the identified gaps, including in areas of forecasting and analytics.

    Fig. 3: Organization design – a product-centric organization

     

    Fig. 3 shows a sample organization design for the product-centric model. The figure also shows the breakdown of the structure from business function to value steams to products or product groups and, finally, applications delivering value—all the while ensuring that the goal of customer-centricity is at the center of every decision.

    Governance and Metrics

    A very important part of creating and adopting a product-centric model of functioning at a power utility includes focusing on the governance of the transformation process, as well as business results accrued from the transformation. The acceleration and adoption of Agile and DevOps practices on the technology side can be tracked through qualitative adoption measures. This leads to product level performance improvement, resulting in better products and faster delivery, with the product delivery mindset focusing on customer-centricity, leading to trends in:

    • Faster time to market.
    • Improved business satisfaction.
    • Improved quality.
    • Reduced information technology cost.

    Other than this, following metrics and measures be focused upon:

    • Adoption Measures.
      • Adoption maturity.
      • Competency/skill index.
      • Operational excellence.
    • Product Team Level Measures – measured at team level per sprint.
      • Productivity measures such as team velocity and throughput.
      • Stakeholder satisfaction measures such as product owner demo satisfaction.
      • Quality measures such as percent automated unit test coverage and test effectiveness.
      • Business effectiveness measures such as business value delivered per feature and requirement readiness cycle time.
    • Product Group Level Measures – measured at product family level per month or quarter.
      • Lead time to change.
      • Cost of requirement change.
      • Release frequency.
      • Cost of rework.
      • Mean time to recover.
      • Application stability.
    • Portfolio Level Measures – measured at portfolio level per quarter or half-year.
      • Delivery satisfaction index.
      • Customer satisfaction index.
    • Team Satisfaction Metrics.
      • Team happiness index.
    • Coaching Effectiveness.
      • Coaching feedback.
    • Team’s Self Organization Quotient.
      • Product ownership.
      • Sprint health.
      • Team health.
      • Technical health.

    Potential Areas of Benefit for a Power Utility

    There are at least four core areas in which a power utility can expect to experience quantifiable benefits by transforming to a product-centric model of operations. They are:

    • Budget and Plan
      • Cost and time are the most valued commodities in a tightly run power utility.
      • A product-centric model ensures money, effort and time are allocated based on the validation of investment already made in an initiative.
      • Improvement in prediction of timelines, effort and benefits of an initiative because of cadence and timeboxing inherent to the product-centric model.
    • Managing the Capacity
      • The key focus is on alignment with business and continuous delivery of business value.
      • The cost of delay and the cost of waiting are also reduced.
      • Focus on value delivery with quantified business benefits.
    • Governance of Programs
      • The governance in product-centric organizations is about the exercise of control on the quantification of benefits.
      • The focus in a product-centric organization is on “building the right things the right way.” Rationalization of cost, elimination of waste and focus on business value are direct by-products.
    • Managing the Demand
      • Continuous visualization and management of demand is an area where benefits are accrued as needs and ideas flow into the strategy filter continually from several sources.
      • The product-centric model allows the continuous elaboration of light use cases to ensure value is correctly calculated and assigned to each use case.
      • The program, portfolio and product backlogs are continuously evaluated to ensure that there is a cost-benefit sense to each item.

    Conclusion

    Some of the benefits of a product-centric model usage at power utilities are stated below:

    • Customized electricity plans for efficiency, cost or comfortable consumption.
    • Improvement in reliability.
    • Creation of environmentally sustainable renewable programs of power for the more aware customers.
    • Incrementally move toward a “business as usual (BAU)” relationship with regulatory changes.

    A product-centric model at power utilities can also help bridge the data divide to improve data and analytics usage and enable creation programs in the following areas:

    • Services and products that the customers are most probable to use.
    • Optimized collection and prediction mechanisms to create plans to encourage timely payments.
    • Create pre-paid services.
    • Plans for direct control of load which allowed the utility to reduce air conditioning kind of machinery during peak usage and in return recompense customers.
    • Improve pattern recognition for delinquency and fraud management.
    • Cross-selling opportunities.
    • Targeted sales and marketing campaigns.

    This article was co-authored by Anurag Choudhry, Enterprise Architect, Manufacturing & Utilities BG at Tata Consultancy Services.

    — Anshu Premchand

  • Simplifying Through DevOps in Banking

    Simplifying Through DevOps in Banking

    There are a great many assets available on the internet that talk about what DevOps is and how far DevOps adoption has come. So we will not repeat the “what” and the “how far.” Instead, we will focus on the road ahead and future of simplification and transformation at banking organizations and the role DevOps is likely to play in the same—in all three areas of “Run the Bank (RTB),” “Change the Bank (CTB)” and “Transform the Bank (TTB).”

    Figure 1: Change-Run-Transform Bank – POA with DevOps Maturity

    In this article, we take a look at what shape we think DevOps-driven simplification in financial organizations can take in the near future and also some opportunities for such simplification. As depicted in Figure 1, with DevOps maturity, the siloed processes of CTB, RTB and TTB will come closer together, allowing common activities and processes to be carried out in one place. The others will get simplified and automated thereby reducing elapsed time of cycle from ideation to production and application management drastically. This will yield benefits not only in terms of cost and time, but also in terms of feature availability to business.

    Banking Focus

    In banking, the early adopters are leading the march with a lot of good practices such as standardized tooling for specific technology areas, orchestration, feedback loop setup, process and technology rationalization, etc. The focus needs to continue on the same.

    We think that the challenge that DevOps architects need to now focus on is to be able to use DevOps to help financial organizations bring down the non-discretionary spend by simplifying the previously ignored maintenance, operations and infrastructure realms. The core of this DevOps driven simplification is needs to be move cost of maintenance to its lowest possible and hence releasing funds to discretionary areas in “Change the Bank” and “Transform the Bank.”

    While the point of arrival for DevOps-led transformation should be “full automation” and “zero maintenance” but they are a bit far in the future because the return on investment (ROI) on the monies and effort required to make that happen needs to justify the same. We see the focus shifting to value delivered to business by transformation of an application or suite of applications. Figure 2 depicts the core repeatable activities of a DevOps-led simplification exercise while keeping in mind these improvement cycles need the setup of feedback loops at each stage.

    Figure 2: Repeatable activities for DevOps-led simplification

    This brings us to our next idea, that the road map to DevOps-enabled simplification needs to be paved with metrics and measures and these metrics cannot be randomly chosen. These metrics have to be actually measurable and be divided into two areas of business metrics and IT metrics as we explain below and need to be diligently tracked to aid course correction.

    For example, release orchestration processes for applications are mostly complicated, need a lot of manual effort, have strict compliance requirements as well as security mandates, need to be carried out more frequently nowadays because of shorter deployment cycles and have to manage ever-increasing complexity of component interaction (upstream and downstream). Now, release orchestration is also a very important step in the entire CI/CD pipeline. So standardization and simplification of release orchestration process makes immense sense. But how does one measure success and quantify improvement?

    As already stated, intelligent insights (metrics and measures) are important in this process for both business and technical team members so that everyone has single source of truth for current status and distance from end goal. This kind of automation also helps focus on the continuous improvement pillar of DevOps adoption by logging everything that matters, have frame-by-frame data for everything that helps. This collection of metrics aids analysis of success as well as failure thereby furthering the cause of continuous improvement.

    Continuing with the example of release orchestration, there are many important best practices that help ensure that wheel is not reinvented. Some of the important learnings that only practitioners will be able to let you in on are as follows:

    1. Tools that need scripting will not be able to help you scale and create low-maintenance solutions.
    2. You need to invest in tools/orchestration solutions that help you visualize, get intelligent insights in a jiffy and can report in a variety of forms and shapes.
    3. Tools need to be able to capture and track business metrics, too.
    4. You need to spend effort on organization level compliance and security.
    5. Strive to automate your most effort-intensive and/or lengthy processes.

    Each step on DevOps maturity scale will have many such learnings and best practices that must get shared across the length and breadth of the organization.

    DevOps and Banking: Future Trends Prediction

    Based on our understanding & knowledge of financial organizations, we believe that the following areas will see focus in the next few years:

    Figure 3: Trends in short-medium term in DevOps adoption

     

    Continuous Improvement within Federation

    • Technology teams will need to enable and encourage localized innovation within a federated boundary of toolsets that will, in time, bring Dev and Ops toolsets to near mirror images of each other.
    • By federation, we mean a detailed homogeneous blueprint that gives flexibility but within an overarching boundary of tools and procedures while encouraging continuous improvement.
    • This must also inform relevant stakeholders about areas for continuous improvement that make the most evolutionary impact to business and use metrics suitably to track and reward improvement.

    Outcome Management

    • We also think that DevOps adoption needs to be driven by outcome management with evidence of impact taking the driving seat for road map management.
    • Focus will be on point of arrival (POA) and continuous measurement of business and IT metrics for outcome management.
    • We also believe that Culture-Automation-Lean-Measurement-Sharing (CALMS) model of DevOps will find more believers.

    Evidence of Impact

    • Metrics and metrics-based course correction will become the Holy Grail in the simplification exercise. The metrics collection will need to focus on areas of both business and IT. The metrics and measures will need to be redefined as:
      • Business Metrics for business value delivered or improved such as new products / services launched, conversion rate, net promoter score (NPS), customer retention rate, CSAT, ESAT, etc.
      • IT Metrics for value improvement and value management such as cost performance index, reduction in defect debt, reduction in lead time to change, etc.

    Design Thinking

    • We believe that the next big disruptor in this space will be bringing design thinking into the mix to ensure that DevOps-led automation is more customer-centric and iterative.
    • We see focusing on test data management (TDM) across the organization as an important step to ensure continuous delivery.
    • In our opinion, the testing process will undergo complete rethink with support of processes such as risk based priority and risk based test case design, test bed splits, TDM and so on.

    KM, Training and Governance

    • Tools and processes for knowledge management, training and governance need to ably support the DevOps-led simplification.
    • These processes will need systemic focus to create and nurture self-learning technology teams.
    • Transformation of the way of working to rationalize processes such as collaboration for lean and improved handover of work packages.

    DevSecOps

    • Security will be extremely crucial in the process of DevOps-led simplification. All the automation, cloud adoption, pipeline creation, IoT adoption and more is throwing up many new security concerns, thereby leading to a focus on DevSecOps.
    • Security processes will potentially need to move their execution points up in the CI/CD pipeline and be divided into stages based on iterations sizes and deployment cycles.
    • Focus on shifting left application security and role-based security.

    Conclusion

    The next wave of simplification of IT spaces in banking organizations will be aided by DevOps. To look for opportunities, a systematic approach toward DevOps will help—it will be perilous to ignore detailed assessment of existing spaces that will detail the current state, point of arrival simplified state, road map for simplification and the key guiding principles for the transformation.

    Carrying out pilots and proof of concepts in DevOps is not a problem; the challenge is with scaling—in all areas: tooling, training and processes. The key is to manage the horizontal and vertical spread of same/similar toolsets that also help drive efficiency associated with scale and standardization. DevOps-led simplification will need changes to processes, technology and people management (culture). The current role structures might need to be demolished to ensure there are no fiefdoms and cross-functional teams handle all requirements of Dev-Test-Ops. Finally, all the changes need to be able to define the new way of working  so that Change-Run-Transform organizations can be brought together.

    This article was co-authored by Babu Unnikrishnan, Head, Banking & Insurance Technology Group at Tata Consultancy Services.

    — Anshu Premchand