Fixing Enterprise IT to Enable Digital Transformation - A Framework

August 3, 2018 By Jon Lehtinen

Author's note - This post was originally written on June 7, 2017.

Digital Transformation, or the adoption and integration of digital technology to transform how business operates, gathers data, makes predictions, and delivers customer value, continues to be a hot topic. Based on this Microsoft survey of over 1700 companies across the globe, 66% of organizations are in some phase of their Digital Transformation- either planning their strategy, implementing the transformation, or (in their opinion) already acting as a market disruptor.

That said, 96% of companies report that the "Level of Transformation Required in [their] Current IT/Digital Infrastructure Environment" as either "high" or "moderate." If 66% of companies are already mid-transformation, this points to a huge failure to revitalize enterprise IT delivery in the ways needed to support a Digital Transformation.

Over the last three and a half years at GE, I ran a team we called "SSO Integrations." We provided integration services for applications and APIs into our authentication and authorization service. As a result of establishing, growing, and finally collapsing that team, I developed a model for applying radical technological change in an intransigent enterprise environment. This model accelerates the pace of Digital Transformation and capability of enterprise IT service delivery by:

Retiring technical debt and accelerating the adoption of modern enabling technologies
Reducing costs of services and time to value for customers
Achieving automation/customer self-service without excessive disruption of the business expectations of the service
Converting a technology service into a technology product

This model was proven by modernizing and automating authentication services at GE. It took us about three and a half years to go from a manual web access management-only configuration shop to full customer self-service using standards-based identity protocols (namely OAuth, OpenID Connect, and SAML). This was accomplished while supporting various special projects and our normal "business as usual" work, and without any leadership direction to drive toward an automation/customer self-service strategy. In short, we worked on pivoting the service from what it was to what it became because getting our authentication services modernized and automated would position us to be ready for the future of Identity & Access Management, not to mention position us as an enabler of Digital Transformation. Assuming such a directive were to come leadership as part of a broader modernization strategy, the timeline for a similar full conversion for any enterprise technology to a self-service product could be reduced dramatically.

Reflecting back on what we did, I see three distinct phases to this framework.

Phase 1: Baseline

The Baseline Phase is the status quo of an offered technology or service in the enterprise. In my organization, this represented the "this is how it has always been done" method of operating. This is the time to define the service. What the service ends up looking like will depend upon the organization and the current maturity of service delivery.

Step 1: Determine what the service is.

To clarify this, consider Active Directory. Some organizations have teams that offer Active Directory-specific services, and do things within the context of what "Active Directory the tool from Microsoft" can do. For this case, it may be natural to define Active Directory Services as the service being offered. But if Active Directory were just one tool among a suite of directories, and a group is responsible for the aggregate capabilities of all those tools, then it may make sense to offer the capabilities of the Active Directory tool as part of a broader Directory Services product or service. Again, how one ultimately defines the service as part of this framework will be majorly informed by the current organization and service delivery structures.

Step 2: Assess the current state of the service.

This step outlines the current stakeholders and engagement processes, and ensures an understanding of the underlying business mechanisms that facilitate the service. If nothing else, figuring out what, if any of these pieces the service is missing will give the team a priority item to define as part of the service definition that comes later.

Step 3: Assign accountability for each aspect of service delivery.

Just like Step 1, Step 3 will look very different from organization to organization. The important thing is that all the stakeholders come to a consensus on what piece of the current service offering they own.

Step 4: Clearly outline the current-state service offering.

Finally, the team defines and documents the service library. This includes the types of engagement, such as requests, incidents, changes, and feature enhancements to be submitted, and the SLAs, if any, for those items in the library. A clear engagement process for each of those engagement types must also be documented, and accessible to customers.

At the end of Phase 1, a team will now be able to offer a complete picture of what the service is and how a customer can use it. Phase 1 ultimately retires "process debt" and converts processes that until now may have been tribal knowledge or poorly understood; now the offering can be utilized effectively in its status quo state in the enterprise.

Phase 2: Expansion

The Expansion Phase outlines growing the status quo offering into a performant service, while laying the groundwork for conversion to automation and Self-Service.

Step 1: Grow customer confidence through consistent execution.

The magic words here are "standard and repeatable engagement process." Though it may seem overly bureaucratic to emphasize process on the path to Digital Transformation, in organizations where a service was not consistently delivered or its engagement process not clearly understood, the offering of a clear service library, front door to use it, and consistent timeline for completion grows confidence in the capability of that technology service and team. Confidence drives adoption, which in turn drives recognition of value. An organization that fails to consistently execute on their standard quo offerings will struggle to convert to an automated process as customers will have no notion of the value of the working service even if it were delivered at no monetary or time cost via automation.

Step 2: Drive service enhancement through the right enabling technologies informed by customer engagement and user stories.

However the service may have been defined, if it is based in dead-end technologies that are not cloud-aligned, standards-based, or scalable, then it will not facilitate Digital Transformation. As part of Expansion, introduce the right tools that align to the strategic vision of transformation and automation into the service offering. Naturally, just what those tools or enabling technologies are vary depending on the service. By adopting additional customer engagement avenues, like collaboration portals and open office hours, teams can get user stories that they can then match with the right technology to drive both automation and customer value.

Step 3: Determine what is required for a MVP of Self-Service.

The team now has a defined service that is strategically aligned with the right technologies for supporting Digital Transformation, and customers know how to use it. Now it is time to think of what features would be needed to offer a minimum viable product of that service through Self-Service or automation. This Self-Service product does not need to offer parity to everything the team can do through the established engagement process- it just needs be feature complete enough to meet the most common use cases. This is the time to strategically select those technologies that align themselves to the goals of Digital Transformation, and leave legacy or proprietary solutions to the manual process.

Step 4: Release the Self-Service product for use in parallel to traditional service engagement process.

When it is ready, the team releases the Self-Service product and socializes it through the established customer touchpoints outlined in Step 2. The stronger customers may opt to use Self-Service over an engagement process as it is asynchronous. Teams can sell the advantages of Self-Service, but they must not allow a dip in manual engagement quality. Self-Service is a benefit of the service, not a requirement for its consumption at this point.

Step 5: Iteratively improve Self-Service product capability, attempting parity with the traditional engagement process.

Through the standard and repeatable engagement process, and the additional customer communications channels established, the team should have an understanding of the type of requests customers make. For however long as the enterprise has the appetite, this is the time to gather the most common user stories and develop the features in the Self-Service product that increase its parity to the manual engagement process. In our case, this period lasted 18 months for my SSO Integrations team, though what is right for other organizations will vary. All the while, the team needs to sell Self-Service as the instantaneous way to get engagement with the technology service. Eventually, people will give it a try.

Phase 3: Conversion

Finally, it is time to ween the enterprise off of manual service delivery. This Conversion Phase completes the modernization of a legacy or manual IT service, and signals a service's preparedness for Digital Transformation. Institutional inertia, though anathema to Digital Transformation, will be the largest hurdle to accomplishing the conversion to Self-Service. As such, this is when influencing skills will need to be on full display as to gather the buy-in and support of leadership and horizontal technology teams in executing the final Phase of the service's modernization and automation play.

Step 1: Use business drivers to incentivize use of Self-Service product.

Customers who are now accustomed to engaging a team for a service or using a non-strategic technology in the service library will be content using those processes and technologies indefinitely. Rather than force adoption of Self-Service, make it attractive to use compared to manual engagement using levers customers likely understand- chargeback models and SLAs. Price the manual engagement for legacy technologies high, and price strategically aligned technologies low. Most importantly, offer Self-Service as the free alternative to manual engagement. Intransigent project managers and technology teams who use the service will overcome lots of inertia when they have the opportunity to save on project budget, and the organization benefits by broadening the adoption of modern technology and Self-Service.

Step 2: Set end of life for the traditional engagement process.

At the right time, announce an end date to the manual engagement process established in Phase 1, and announce that the service will be solely available through the Self-Service product. The team can use the feedback and alarm from the customers to determine what last minute features, if any, need to be added to Self-Service to enable a smooth transition. Once the end date passes, strictly enforce Self-Service as how the service is now offered. Change takes time to be accepted, and making exceptions early in the cutover can undermine the entire strategy. Sound judgement on any exceptions and leadership support when pushing back on customers temporarily agitated by the change in process will help the change stick over the long term. The end goal is modernization for Digital Transformation, after all; some short term friction in service of that higher goal is a low price to pay.

Step 3: Begin managing Self-Service product through established customer touchpoints.

Now that the service is only available via Self-Service, and the only technologies offered for the service are the ones aligned with a Digital Transformation strategy, teams can pivot from service delivery and engagement to product management. The team can be repurposed to focus on developing feature gaps based on the user stories gathered through the touchpoints established during Phase 2. If the team relied on manpower to accomplish effective service delivery, the pivot to Self-Service offers some cost-out opportunities.

Step 4: Iteratively improve the Self-Service product based on impact and prioritization of features from user stories.

From here on out, the team should operate like any other product management organization- gathering user stories, prioritizing those features which provide the largest value, and iteratively improving the capability of the Self-Service product.

Having gone through this process, an enterprise technology service will now offer the right enabling technologies for Digital Transformation without the encumbrance of technical debt. This yields cost savings as the enterprise reduces the environments and vendor tools that were once supported. Couple that with the cost reductions that come from running a narrowly-scoped Self-Service product, and the organization benefits from reduced cost of service while promoting an instantaneous service delivery experience for customers. Despite the enormity of the service change, this framework ensures that customers are well socialized to the new methods, technologies, and engagement processes as to make sure they have already begun self-selecting into the new Self-Service framework before making the old way of service delivery disappear.

All of of this in confluence makes for an enterprise IT service that will not be counted among the 96% that will require significant change to enable an organization to realize its Digital Transformation strategy.

I will be speaking on how I executed this framework for the authentication services in GE at the 2017 Cloud Identity Summit in Chicago, Illinois. If you have questions, critiques, or differing opinions, I hope to catch up with you there. If you can't make it, I am always available on Twitter.

This article was updated on August 3, 2018