Is digital transformation the panacea?

Every enterprise is in some stage of “Digital transformation” today. The new ones are born digital anyway. But, is transforming the enterprise digitally enough to maintain their competitive advantage? Does this automatically bring the organizations closer to the business? The answer is NO.

Today’s digital world is shaping the way customers, markets and even employees think, write, share ideas, experience the world leading to changed buying behaviour. The options, before the stakeholders, are vast. Customers change their needs fast even building up some en route. How efficiently can the enterprises understand these changes? The key to success is whether they can make use of this digital transformation into delivering “Personalized experiences or realities” on time. An example is the Japanese e-commerce site Zozotown. Its mobile app is paired with Zozosuits to take customer’s body measurements. They can then order individualized clothes online.

Whilst this is on the customer side, what about employees? Employees should become more like “Human + workers” ready to embrace and apply digital technologies to enhance the way they work and deliver products or services.  Both the entire organization and the employees must keep pace with digital maturity. If either one is incompatible, it may pull down the enterprise ability to differentiate.

The markets are no longer fixed or in a single location. They may not even exist today. Welcome to the world of “digital”, “on-demand”, “At the moment” multi-market scenario. Some may last for a while. Others may not. Enterprises must act keeping this in mind. The underlying processes and structure can be monolithic but the entire firm must be nimble and ready to shape-shift in a moment’s notice. For this, the organizations can and should use appropriate AI tools that help predict preferences and changes in the customers’ thinking.

The essence lies in how the enterprises can effectively use the digital technologies to harness the virtual markets simultaneously building “Trust” with customers, employees and business partners.

Skills for shaping the digital enterprise

In the world of digital transformation happening, how do we see the roles emerge? Does the old definition still hold good? Here is a brief view.

Most organization will become “digital” in some way or other. When they change from a monolithic to a digitally agile unit, usually a saviour is recruited and he or she is called CDO (Chief Digital Officer). But things do not end there. Rather it is a start. The entire organization should become digitally nimble. For that, we also need to see how the roles encompass some of these aspects. Mind you, today’s world will not be strict 1-1 mapping. We will find that CHRO and CMRO should work together in incubating labs and the would be their joint KPPs.

CHRO (Chief Human Resources Officer) - Starts with identification of digital gap and engages in acquisition of such talent to fill the gap. Target is for the CHRO to own the “digital experience” and initiate a culture of “incubation labs” that foster and nurture talent closely allied to business as the enterprise becomes digital throughout.

CMRO (Chief Marketing Officer) - Starts with setting up marketing related digital aspects. Target is to own the “digital experience” along with CHRO. All start up labs / eco-systems for building products and experiences should be the mainstay.

What about CTO (Chief Technology Officer)? The vision of CTO means a nice team of geeks who set the enterprise architecture standards for the organization. Of course, the starting point is development of digital architecture. Target will be to own digital product labs.

The all-pervading CIO (Chief Information Officer) will be responsible, initially, for defining and managing digital infrastructure as part of the enabling function of IT. The entire portfolio including the actual digital infrastructure of the organization as well as the target channels of interaction should be governed in the end.

The CDO (Chief Digital Officer) is the digital evangelist at the beginning. He or she should lead the digitalization initatives as well as the incubator labs.

Chief Data Officer is responsible for modelling digital standards and driving data access. All the development of data-driven products and usage of digital to fuel more data and innovation will become de rigueur.

In summary:

1. Culture will change form strict compartmentalization to porous boundaries. Roles and KPPs will impact each other and will require working together not only across functions but also with various service providers and other technology partners.
2. A common set of traits will form the bedrock of digitally nimble organizations. They will include digital thinking and lean principles. The mindset will move from a generalist to digital generalist taking into account the “domain” knowledge specific to the industry.
3. Finally, every one in the new era cannot be a risk avoider. No reward for such a strategy. They will be encouraged to take calculated risk, try out new things rapidly harnessing data from different channels, discard things that do not work out but in the process go towards what is likely to work.

Changes happening in Insurance industry impacting IT service providers

Usually people associate technology changes more with banking sector.  about insurance? Global insurance market is valued at $5 Trillion. How the people use insurance and even think of it have undergone a tremendous change. The expectations are different and so is the service catalogue from the providers. How is the technology shaping up the industry?

Here are 3 important changes driving this sector.

All encompassing digital transformation – New models / Personalization

Like any other industry, this has shaken the leaders as well as laggards. No one could afford to be complacent. The overall impact is very positive for both the organizations as well as the customers. Customers’ expectations are changing: They expect very specific bouquet of services, expect services anytime anywhere and through any channel. EY estimates that 80% of customers want better communication with the insurance organizations. And this communication has to work seamlessly across channels!

Big Data And Analytics will play a huge role. Are today’s insurance organizations equipped for collecting all data online and real time? Have they made changes to their organizations as well as the processes in order to make use of the data? Can they offer a single user based insurance and personalized premium based on the data available online? What are the ways to collect data in order to get a competitive advantage?

If 80% of the premium is lost due to distribution costs, imagine the power of digital models. Perhaps they will make the intermediaries redundant in the entire value chain. APIs will redefine insurer-insured-InsurTech relationships. Insight-driven offerings will be the buzzword! An insurance company, in Europe, partnered with Panasonic. The latter’s sensors provide alerts to both the insurer and its customers using which issues are resolved quickly. Drones are here to stay and will become increasingly used for many purposes. Some of them are assessment of property damages, accurate estimation of property, analysis etc. In order to assess Hurricane Harvey’s damages and settle the claims faster, leading auto insurers used drones. In Australia, many big loss claims were settled within 90 days using drones.

Insurtech modernization

The system of records, especially the legacy systems, need to be transformed and operating costs minimized. RPA (Robotics Process Automation) and SaaS are being extensively used. Many companies buy products and customize them so much so that it loses the product flavour. This can only increase the costs of maintaining such systems. Companies are looking at  standardization as a means to cut costs.

Some of these are likely to encompass the following:

• AI and automation to cut down costs
• Focused application for digitalized customer experience and focused approach to problem-solving.
• Implementing a global Blockchain for a more secure and safe information sharing channel.

Partnerships

The collaboration between insurance and InsurTech firms will happen faster. The result will be new revenue models, higher profitability and reduced costs. If we look at the InsurTech firms’ growth, it happens in almost all the areas such as auto, cyber security, home etc. These call for increased technology capabilities which may be difficult to develop by the traditional insurers or would take a longer lead time. The latter is not acceptable in the competitive world. This could even be a win-win for both. Reaching out to large customers could become easier using InsurTech companies.

References

https://www.businessinsider.in/the-insurtech-report-how-financial-technology-firms-are-helping-and-disrupting-the-nearly-5-trillion-insuranceindustry/articleshow/60258913.cms

https://www.itnews.com.au/news/qbe-deploys-drones-to-assess-insurance-claims-452739

https://www.nationwide.com/smartride.jsp

https://www.cbinsights.com/research-insurance-tech-trends

https://riskandinsurance.com/5-tech-trends-for-insurers-to-watch-in-2019/

Dear customers, Rationalize your SLAs…

You go and ask an ISP (IT Service Provider) of any customer especially in the field of FS (Financial Services).

You: Hi, tell me about your delivery quality.

ISP: Welcome. We are at the top of the delivery excellence curve in the eco-system of my customer. All SLAs are green for the last … years. We are very proud.

You: Good. How many SLAs (Service Level Agreements) do you measure and report?

ISP: We pride ourselves in reporting more than 100 SLAs covering all aspects.

You: Wow! 100+ All your SLAs are green. Can you vouch for no degradation in the performance of your customer’s service to their end-consumers?

ISP: We can’t say that. Whatever we do, we are GREEN.

The above is not an uncommon conversation that can be experienced today. SLAs are good and needed. But what started off as a measurement mechanism is not what you see. It has become muddled, saddled with increasing number of measures and is being religiously reported. The only problem is that who consumes and what useful information is derived from it? What has happened in the last few years?

• The eco-system has more than one vendors.
• Very rarely does a complete business process start and stop with one vendor. Different vendors act on different parts of the value chain to complete a service.
• More vendors result in more hops of process flow. Each hop adds complexity to measurement, governance overhead and lead time.
• SLAs have become more operational and reflect the process capability of the ISP and have nothing to do with the business outcome of the customer. A system has an availability of 99.99%. It is possible to have one minute outage and meet the SLA. If that one minute happens to be during a critical window, business suffers. On the other hand, an outage at some other time may not impact business.
• The amount of time spent in recording data, reporting and managing can fund a fully-fledged vendor department!

What should the customer do?

1. Have a focused 1-2 week exercise. Look at your vendors and different services.
2. Understand your business capability and map the IT processes/vendors against each. Identify the critical points in the value chain.
3. Start developing SLAs to match with the “success criteria” of IT as a whole. For this, assume you are the only party in control of all IT resources/services.
4. Do not waste time in operational SLAs vouching for the process capability of the vendors. If you have selected a vendor compliant with certain process standards, it is the responsibility of the ISP to comply with it. So long as the MSA (Contract – Master Services Agreement) covers it, that should be fine. However, retain the option to ask for artefacts that couch for compliance.
5. Call for a workshop with the ISPs and set about how each one can take the SLA you have devised. It comes in many different flavours:

• Flavour #1: Every ISP can take the SLA and apply it with respect to its domain/services. For example, consider a resource ramp up time of n weeks. It applies to every ISP and can work with their portfolio.
• Flavour #2: The SLAs have to be taken by each ISP; however, the target value should change as the quantum and type of work done by each ISP vary. Consider the fact that 20% of the IT staff are considered “KEY” and there is a whole host of definition behind what is “KEY” including longevity in the account, skills, capability, offboarding procedure etc. Customer’s IT has a target of 25%. But the same % may not be relevant for an infra service provider vs high end application service provider. The values should reflect their role and volume of work.
• Flavour #3: This is the most complex. The completion of a business capability requires services from different ISPs. Here, the respective ISPs should take the entire SLA as it is and have a responsibility to work together and ensure all of them complete the task within the overall time. This will call for a high maturity discussion, understanding and a passion to work with multiple vendors in order to deliver a business outcome. Once agreed, the ISPs will ensure they work seamlessly, find ways to inform one another well in advance, have planning sessions, find ways to reduce the hop etc. If any ISP is not willing to take, you really need to re-examine the fundamental reason behind. Or it is perhaps time to re-examine the relationship with the ISP.
• Flavour #4: This is similar to the variant #3 but with a difference. The single business capability can be broken into distinct steps with each step owned by an ISP. Here,  the ISP take that part of the SLA (After breaking it down) that applies to them with a specific target value.

After agreeing on this, focus on:

• Propagation of the same across all users/stakeholders
• Laying down of the measurement and reporting system to be used and
• Developing an automated system for tracking and reporting eliminating the need for a voluminous governance around this.
• As a guideline, any set of SLAs more than 20 measures may not augur well.

Finally, a word of caution: If, as a customer, you find too often lifting the phone or dropping an email to ask for an SLA report or spend days validating the data in the SLA report or get happiness in organizing SLA meetings, you have slipped into a danger zone. 

CIOs and CTOs: How frequently do you perform a health check up of your portfolio?

An IT landscape, like any other real estate, grows and changes continuously. In the process, it accumulates technical debt, grows equally well in both legacy and modern technologies, redevelops functionality, creates redundant systems and keeps tweaking many products to suit the BAU scenario. On top of it, if the organization acquires another company, the diversity of the portfolio multiplies. In the entire melee, no one bothers about keeping a proper count of inventory or documentation or health of the portfolio.

Very few organizations invest in a portfolio assessment exercise and fewer do so periodically. No doubt, such an exercise is time consuming and expensive. But, the benefits of a proper exercise, if done well, will help the organization to take decisions faster. Not knowing the extent of technical debt or the inability of the agility of the portfolio will creep up more and more work in every IT project and eventually pull back the organization’s ability to develop new differentiating products or services.

Now the industry is moving from on-premises to cloud; legacy to differentiating technologies; from systems that are obsolete or about to go out of support to open sources; separate development and support to DevOps; waterfall methodology to agile; sedate landscape to one that evolves and learns. Consequently, the focus of such assessment exercises should bring out these factors in the form of metrics.

Based on my experience, here is a primer in the form of FAQ on such an exercise:

What is such an exercise called?

It is typically known by various names. Some of them are APA (Application Portfolio Assessment), APR (Portfolio rationalization) or APO (Portfolio Optimization) or APM (Portfolio Modernization).

How frequently this should be carried out?

Once in three years is a minimum. This should be modified depending on the growth of the organization in terms of IT systems, inorganic acquisition of other entities etc. If the pace of change is more, once in 2 years will be better.

What is the duration and involvement of such an exercise?

The duration can range from 1 to 3 months depending on the quality of the IT assets and configuration data base maintained. Involvement from Product owners, Enterprise architects, procurement and senior management will be required. This initiative should be owned and driven from the CTO’s office.

Let’s talk about the outcome of a typical APA exercise.

Once we understand the output, the activities to be done, during the exercise, can be inferred easily. For the purpose of clarity, let’s look at the output as consisting of two parts:

1. Part-1 is about metrics that indicate the health of the landscape across various dimensions
2. Part-2 is about resulting initiatives and recommendations.

What does Part-1 focus on?

This has 2 sets of metrics. First set focuses on hygiene factors; the second set on value added parameters. The hygiene set should address, at the minimum on the completeness, quality and currency of data pertaining to the following 7 dimensions:

1. Inventory (List of applications and related details like description, technology, # users etc.)
2. Mapping (Business capability or function to Platform Platform to IT application and IT application to Infra)
3. Product Usage (Product Name, associated details, Extent of customization of the product, Vendor)
4. License (Vendor, License, ILF – Initial License Fee, RLF – Recurring License Fee, Contract expiry date etc.)
5. Documentation (Required documents for understanding the system, required documents for providing support/development of the system)
6. Technical debt (a quick assessment in the form of KLOC – Kilo Lines of Code or Cost)
7. Cost related (Various cost elements including but not limited to resources, service provider, product vendor, license vendor, compute, network, storage, cloud etc.)

The second  value-added set should focus on the ability of the IT organization to closely align with business and quickly respond to the changing needs without undue lag. What are the areas to focus here?

Cloud readiness – Cloud is great leveler of the landscape and imposes more uniformity and standardization without compromising on the business capability. How much of the landscape can be easily shifted from on-premises to cloud?

Platformication readiness – How are the IT systems and infra being developed? Do they lend themselves to a vertical clean cut enabling business, application, data and infra layer to go towards a platform or a utility model? Typically the top 30 to 40% of the landscape that are key to the business should fall into this bucket.

System of innovation and differentiation – All the systems can be bucketed into system of records (back office, core, legacy that undergo little change), differentiation (the middle layer that gives opportunities to differentiate the services) and innovation (the key ones that are integral and unique to the organization’s capability). As the landscape matures, more and more systems should move from records to differentiation and differentiation to innovation. That way, more and more of the landscape will lend itself to agility and help in a faster turn around.

DevSecOps readiness – How are changes implemented in the portfolio? How is support provided? Is there a wall between them? What type of people are being used across the landscape? What is the release periodicity? Is the entire IT operating on a single cadence even if many methodologies are followed? How is security principles embedded in the life cycle? Today’s world is taking the landscape towards a common set of cadence with no blockers to the ground.

Skill readiness – The organization should adopt a uniform system across its internal as well as external employees / contractors / service providers to denote the skill and competency. Dreyfuss or SFIA can be adopted. This help in talking the same language, drawing up training plan, cross-skilling of people, providing a career path etc.

Tell us about Part-2 of the outcome

Once the above is complete, various metrics can be collected that can provide a useful basis for arriving at a set of recommendations. We can classify the recommendations into 3 categories:

Category-1: Hygiene initiatives

All the hygiene factors, mentioned in part-1, should be ranked on a scale of 1 to 10 (10 being high quality, complete and up to date). Wherever the score is below 5, a program plan for bringing it to 8+ should be provided. If the score is > 5, either a separate plan or as a by-product of a major upgrade/project should be specified.

Whatever it is, by a certain time line, all the hygiene factors should be brought to 8+. Even if no modernization is undertaken, this is very important. Otherwise, this will drag the entire development and release.

Category-2: Extrinsic initiatives

These should address factors like the following:

1. Data centre Consolidation (Number and locations)
2. Service Provider Consolidation (for a given IT spend, how many service providers should exist? 
3. Scope for consolidation; Dependency vs Risk vs Savings)
4. License Optimization (Optimization of licenses across the organization, management of RLFs, negotiation with vendors etc.)

Category-3: Intrinsic initiatives

These arise from within the portfolio and enable the organizations to move to a certain state. Every state should be characterized by the set of value-added factors mentioned in part-2.

Some of these could be:

• Categorization of applications into those that can be decommissioned, migrated and modernized and consequent programs to implement the same. All the initiatives (a functional migration, technical reengineering, refactoring etc.) should be ranked according to the RoI, Time taken to implement and risk including cost of change across the organization. Implementing such initiatives will lead to reduced application intensity, reduced technology spread etc.
• Program plan for increasing the cloud usage
• Program plan for bringing the entire organization into uniform DevOps or DevSecOps
• Program plan for eliminating niche, obsolete and other technologies that will soon go out of support
• Program plan for baselining the skill, productivity and measurement across the landscape

Tell us about the stakeholders

These exercises should be driven by the CxO through an appointed PO (Program Owner). A ToR (Terms of Reference) of such an exercise, objective, timeline and involvement and support of different stakeholders should be drawn up and roadshows held one to two months before the exercise. The program should be part of the CxO’s steering committee. A dashboard indicating how the health and agility of the portfolio evolves during the next 3-year is a must.

How to address technical debt in an evolving IT landscape?

Can you wipe out technical debt from your enterprise landscape? Can you always remain one step ahead? These are tough questions that require a calibrated answer. Before answering, we need to understand what is meant by technical debt, why it occurs and ways to manage them.

The first realization should be that technical debt is bound to happen no matter your toll gates and quality check.  The second is an organized program should be initiated, at periodic intervals, to estimate the size and manage its growth. The third is that not all technical debt is bad.

Like a financial debt, if not managed or contained, it would grow to such an extent that it affects the time to market, sink the morale of employees and cease to make the IT shop attractive. Technical debt accrues interest in the sense that it can generate new debts and make it progressively difficult to manoeuvre the development. Tech debt will always be there.

What is TECHNICAL DEBT?

In simple terms, it is the marginal (incremental) work required to complete the software development in order to address the drawbacks. It doesn’t apply only to those projects that are in development stage. It follows even when it is in BAU (Business As Usual). Technical debt holds the organization back from introducing new functionality quickly. We can get an estimate of the debt as the time or money required for refactoring. This refactoring could result in change in design, cleaning up of bad code or porting to a new technology.

What causes technical debt?

The experts cite 4 major reasons for introduction of technical debt.

Cause #1 - Poor Conception: It is the rush or speed in delivery that causes poorly designed software.

Cause #2 – Poor Scheduling: Underestimating the time to develop a product or complete a project often is the culprit that introduces technical debt.

Cause #3 - Bad and inconsistent development practices: Various developers working across different modules tend to introduce their own practices that affect the design and possibly rebuild the logic independently.

Cause #4 - Outdated Technology: As technology evolves, software standards become higher every day. With each improvement, new technical debt can arise.

Types of TECHNICAL DEBT

Type #1: Intentional debt – The software engineers almost always know the right way to code something and the quicker to way to do it. In many cases, the quick way also turns out to be the right way and in others, it may not be. To quickly deliver a project or a product, the functionality will be achieved but not in the best possible manner.

Type #2: Design tech debt – Do we spend time thinking ahead? Or Do we future-proof our design with quicker delivery? As systems become richer with more functionality, the developers may find implementing a new feature very difficult. It may be easier to refactor the original design if it was constructed in a suitable manner. If not, what do you do? Be ready to bite the bullet and get into significant refactoring.

Type #3: Obsolete debt – As many people work on a system, it tends to evolve in a rotten manner. Some symptoms like copy-paste and cargo-cult programming can be easily seen to identify this type. This is directly incurred by the developers. This is one debt that we should avoid in a consistent manner.

Another way to look at this is using the following quadrant that classifies using two dimensions – deliberate or accidental and manner of introduction of such debt.

How to manage this?

Type #1 – Record the debt as backlog at the time it is incurred. This can be revisited later.

Type #2 – Whenever the system is in steady state BAU, allocate some time to look at this type of debt and see if any refactoring has to be done.

Type #3 – Continuous refactoring is the solution to address this. Very experienced and strong teams tend to take time to understand the design of the system before they work on it. When they work, the improve the design incrementally and clean up the bad code en route.

Measures / Signs of technical debt:

Source Code Formatting: It is a common measure. Insisting on the right tool as well as template during and before the SDLC can reduce this type.

Low Test Coverage: It is a measure of code quality. A very low level of the test coverage reduces the certainty of the accuracy of the software's behaviour and makes it difficult to solve problems when they occur.

Lack of Modularity: This generally results from a poor code design. Some code sometimes serves different business logic. The more codes developers write, the more lack of modularity can bottleneck. It is harder to manage software that has logic all over the codes and have parts of codes handling several logic.

Code Complexity: Complexity can be measured in several different ways, but it measures the dependence and path length to perform an operation. A long path leads to complex code.

Lack of the Documentation: Documentation is part of software development best practices. The software is often driven to evolve. It is important that the written code is always understood at all times by everyone who may be involved in the development process.

One approach is to perform a static analysis of code using tools that support the analysis. The following is a list of the most popular tools used: Coverity, SonarQube, Checkstyle, Closure Compiler.

There are two ways of measuring technical debt. The first one is to get a ratio of technical debt according to code volume, and the second one is to use directly the estimates given by the tools (like SonarQube), along with the list of technical debts and their references to the code, SonarQube gives an estimate in days or hours needed to fix this debt. For the ratio approach, we can use the initial estimates or even better, the overall time needed to develop the software so far and extrapolate the value according to the technical debt ratio. The time needed for the development is very accurate so measuring technical debt from ratio can give an accurate estimate of the work needed to fix the issues.

How to Reduce or Eliminate Technical Debt

Being agile is the best way of managing technical debt and reducing it when it appears. The sooner we address the issue, the less interest we'll have to pay over time. To address technical debt, software development teams can use the following approach.

The Quickest to Solve: Fixing debts that take little time to fix is an excellent way to eliminate technical debt gradually. Debts like code formatting can be solved in a little time, making up a template and apply these templates to all the codes that have been developed so far, then integrate these templates in the tools used by the developers.

Priority: It is also important to address issues by priority. All issues that can lead to more significant issues should be addressed quickly and should be prioritized to avoid accumulation.

Technology Update: When outdated technology leads to technical debt, it is important to update the software to the newest versions of the frameworks, application servers, databases etc. It is even important to include every stable evolution of a framework used for instance to always have the latest update and to bring small change without breaking the software.

Refactoring: Reviewing the software architecture and refactoring codes often can be useful when we don't want to end up with duplicate code or codes that lack modularity.

The quadrant, shown, can help to categorize the technical debt to identify which ones to fix first. There are many such approaches. Coming to agile processes, how to estimate / eliminate technical debt? It should be entered in the product backlog as a user story and should be prioritized like any user story. The prioritization should take into account the impact of not managing technical debt identified at the beginning of a new iteration. When deciding which stories to include in the next development iteration, we should analyze whether postponing technical debt correction for the next iteration is more or less advantageous in the long term. As a rule of thumb, we should address every critical issue as soon as it is identified.

Closing remarks

We have to learn to live with certain amount of technical debt. A good IT shop will always have a handle on the measure in terms of either the time or money needed to fix the accumulated debt to a manageable level. Understanding of different types of debt and the rate at which the organization accumulates will help in introducing specific measures to eliminate or minimize such debt.

References:

https://www.agilealliance.org/introduction-to-the-technical-debt-concept/

https://hackernoon.com/there-are-3-main-types-of-technical-debt-heres-how-to-manage-them-4a3328a4c50c

https://www.atlassian.com/agile/software-development/technical-debt

https://www.bmc.com/blogs/technical-debt-explained-the-complete-guide-to-understanding-and-dealing-with-technical-debt/