A Dual Transformation approach to evolve legacy IT into a modern digital technology organization

By Gokhan Metan, Ph.D., Vice President of Enterprise Data Science and Engineering, Centene Corporation

Throughout my professional career, I have been lucky to work in several companies across five different industries and get the opportunity to learn unique aspects of each business. Despite their uniqueness, these companies had something in their common denominator; they all had their respective legacy IT organizations that were slow and old-school, and pulled down by the heavy weight of accumulated tech debt and organizational bureaucracy. As businesses come under pressure due to the limitations of their clunky IT departments, they typically attempt to transform and revitalize this technical and critical enabler organization. However, many of these attempts either fail entirely to deliver what is intended to be accomplished (i.e., modern, and efficient IT function) or, at best, make marginal improvements relative to all the time, energy, and resources expensed on the overall transformation. This unexpected outcome begs the questions of “why do these transformations typically fail on their promises?” and “how can we approach the problem fundamentally differently to achieve a better transformational outcome?”

Before we dive deeper into our discussion, we’d like to emphasize that our view on this topic is more on the framework of approaching the transformational problem than anything else. Transformation requires change, and change is not easy. Our view on failed or ineffective IT transformations is not revolving around the competency of these organizations, but rather how they could be set up for success in a better framework.

Back to our main topic… The detailed diagnosis to the first question, “why”, for the most part, heavily depends on the specific organization under the microscope and the circumstances in which the transformational activities are carried out. One contributing factor why transformation efforts fall short is because the organizations are so focused on the high level needs – or put more bluntly, the mandate – for change rather than the dynamics of what and how to change. As a result, the initiatives turn into a frenzy of activities that look like great progress with a sense of urgency on the surface, whereas the reality is a myriad of value-deficient activities executed with intense anxiety hidden deep inside the staff. We believe a different approach, based on the work of Scott D. Anthony, Clark G. Gilbert, and Mark W. Johnson Dual Transformation¹, could result in more systematic change with successful outcomes while combating against strong headwinds of change and achieving a solid digital transformation. Before articulating our points any further, it is necessary to introduce the Dual Transformation concept quickly for the sake of our readers’ understanding. As economists very well know, the most powerful way to introduce a framework is through simple visual (how many of us can ever forget the supply-demand curve!?), and that’s what the authors of the book already has done for us. Figure 1, borrowed from the book Dual Transformation¹ explains the idea in three components: Transformation A, Transformation B, and capabilities link C. Transformation A is about repositioning today’s business to maximize its resilience and reduce its waste. Transformation A, in our IT transformation, will therefore refer to the changes to legacy IT organization. In this model, Transformation A applied to the legacy IT will attempt to solve the same problems the department typically owns, but in a different (i.e., more efficient) way. On the other hand, Transformation B is about creating a new technology engine for the company. It will not only be about solving new problems, but also solving them in new ways. This transformation will create a totally new tech department, treated as a new business, in co-existence with the legacy IT, which itself will be going through transformation A. Finally, the capabilities link will establish the connection between the two to transfer hard to replicate capabilities from the core (A) to new tech organization (B). For instance, cyber security assets, policies and practices that are well established and invested in the core IT function might be a prime candidate for capabilities link and made available to new tech departments shaping up through transformation B.

We list a sample of key considerations in Table 1 to shape each component of dual transformation in an IT transformation setting. Various other considerations can be formulated for the specific needs of each business and corresponding IT transformation. The beauty of the Dual Transformation framework is the clear delineation of responsibilities (as clear as it could get) and boundaries of core IT transformation and the new tech organization. This helps the senior leader overseeing both transformations to better manage the dynamics between A and B more effectively without losing sight of the end goals. Once both transformations reach a mature state and end goals are mostly accomplished, the two departments could also be merged into one, completing the transformation journey and resulting in a revitalized IT/Tech capability for the company. Although this does not necessarily have to be the end state, it could be the path if it makes sense for the organization. The most critical point is that Transformation B, which deals with solving a new problem in a new way for the organization, should be owned and pursued separately, not within the boundaries of core IT transformation. Otherwise, these problems will likely either be attempted to be solved in old ways (instead of new ways) hindering innovation and efficiencies, or won’t be solved at all due to the tech debt and bureaucracy of core IT dragging progress down to a complete halt over time.

Transformation Component	Key Considerations
Transformation A (core/legacy IT)	Redefine the scope of core IT – shrink the boundaries to maximize resilienceMove only critical scope to B, where the migrated responsibilities are within the span of control for B to solve the “new problem”Core IT to provide support to B adequately enough, but not excessively
Transformation B (new tech department)	Hire the right talent externally that are best suited to lead the Transformation B. Avoid “nepotism” or other forms of biased internal talent moves into B that can derail the formation of “new business”Move a healthy mix of critical talent (SMEs and technical talent who knows the business) internally from A to BLet B own and solve for the new problems business is currently suffering from, which is the basis for transformational change

We will now focus on a narrow transformational use case to make an example of how the framework would be applied practically and how it would differ from a traditional approach. Our goal is to make the concept of the dual transformation approach more concrete in our readers’ minds before concluding our discussion.

Short description of use case: Acme is a multibillion-dollar corporation that started 40 somewhat years ago and has a tremendous growth through organic and M&A growth. The company’s IT team has built its first- and second-generation data warehouses to support growing needs for data. Despite substantial expansions and investments in data infrastructure, the current state is not meeting business needs (i.e., data assets are rigid and do not reflect business logic, requiring data analysts to write and maintain complicated SQL queries, data issues are quite common, and any new data asset takes months to bring to analysts’ fingertips etc.) It is agreed upon by the C-level executives that it is a priority for the organization to invest in data infrastructure and data assets that will transform Acme to compete with its competitors more efficiently and technologically. Although the C-level execs agree on what needs to be accomplished, they are not aligned on the how. Two approaches are in the table: 1. “Single” Transformation – IT owns the change and investment decisions; 2. Dual Transformation – IT follows transformation A, a newly formed Enterprise Data organization follows transformation B. The question is how each approach would play its course out? Table 2 provides a thought experiment on how these two alternative directions would likely shape up.

Stage	“Single” Transformation – Core IT drives transformation activity	Dual Transformation – IT follows transformation A, a newly formed Enterprise Data organization follows transformation B
Strategic Planning and Distribution of Accountabilities	Chief Technology Officer (CTO) delegates the work to the VP of Data Infrastructure. VP of Data Infrastructure starts the work with a series of internal discussions and presentations, reviewing the current inventory of assets, tech and where other industries are shifting towards. Teams start articulating what a new data infrastructure should look like. Several vendors are invited to pitch in their products and solutions. Series of sessions are held for over 3 months to gather as much knowledge as possible for an informed decision.	Chief Strategy & Transformation Officer (CSTO) assumes responsibility to oversee both transformations A and B, and accepts the responsibility of arbitrator between the two leaders as disagreements arise. CSTO hires SVP of Enterprise Data (SVP ED) to lead transformation B and the newly formed organization. SVP ED and CTO frames up the roles and responsibilities of their respective transformations. Transformation A will focus on minimizing the current data infrastructure footprint and eventually sunsetting it. The efforts will focus on reducing the tech debt and sustaining business needs in the short term. Transformation B will own a new data strategy and assets development. New infrastructure will be co-owned execution-wise, but the choice of tech and strategy will be SVP ED’s responsibility to decide. CTO will bring in his top talent on security, network, and on-prem assets. SVP ED will hire the talent on the short list such as cloud engineers, cloud architects, and analytics engineers.
Execution	After months of deliberations, the data strategy is still in the air. Some believe the need for another data warehouse but on the cloud using columnar databases, some argue whether Inmon vs. Kimball should be the choice, others highlight the benefits of datalake. While the debate is ongoing, a decision is made to lift and shift the existing on-prem data assets to the cloud to show progress. Team starts allocating resources for this work. The current tech debt, lift and shift, ongoing presentations and vendor demos start to take a toll on the team. Lack of clear data strategy and the mounting workload is now demoralizing staff and the initial excitement fades.	First decision focuses on data strategy. An assessment of Acme’s appetite for the next 10 years to play more offensive in its industry requires a data strategy that is more flexible, reliable, and cost efficient. A tailored data strategy is developed based on this offensive/defensive appetite tradeoff and utilizing the Data Mesh framework. Winner suppliers for cloud and various tech stacks are selected in line with the data strategy and needs of the enterprise. These tools are selected regardless of the existing tech available since transformation B is making the decisions independent of the past attachments. Talent transferred from the CTO organization joins the new organization along with the fresh new talent hired and sets the execution in motion. SVP ED and CTO work closely to remove barriers and maintain the transformation’s momentum.
Early Wins & ROI	Some early wins are accomplished but at a steep cost as teams were working on steroids to keep up with the excessive pressures of the workload. Despite the short-term wins, the lack of a clear data strategy limits the scalability of the solution, thereby leading executives to be hesitant to sign up for more ambitious goals. Under pressing demands, the team comes up with an estimated investment to support three key initiatives for Acme. Investment figures were bloated by a factor of 3x due to inefficiencies and doing things in the old way. Senior executives have a hard time justifying the investment asks to pursue the transformational activities. Teams try to move forward with previously approved budgets, but they could only accomplish marginal results running on fumes. Progress comes to a halt with mixed outcomes after two years of starting the transformation journey.	First few data products came to life within the first two months of the execution. Transformation A focused on forming up upstream data product teams, whereas Transformation B focused on mid-/down-stream data products through data democratization with the power of modern tool stack such as Fivetran and dbt. Interoperability standards are co-developed by both organizations as key capabilities link. Lakehouse structure is leveraged to develop a flexible data infrastructure in line with the offensive/defensive appetite of the organization. After successful early wins with the new data products, the organization set its eyes on more ambitious goals. Three key strategic objectives of the company are chosen as the areas for directing data infrastructure/data product development. Within the next year and a half substantial development took place, and data needs for two of the three key initiatives are fully satisfied with the third one at 70% completion.

Technological innovation and the accompanying transformation needed for achieving innovation, is a challenging journey with various landmines along the way. Making the decision to transform is already a hard one, but even harder is executing the transformation itself over multiple years by constantly ensuring to remove any road hazard that can derail the change efforts. Therefore, leaders accountable for such critical work would be better served by starting with a robust transformation framework such as the one described in Dual Transformation. We strongly recommend the leaders in the field facing such challenging transformational accountabilities to further educate themselves on the Dual Transformation framework. Maybe it can help serve your goals one day, and this article would merely serve its purpose by socializing the idea with my fellow colleagues…