Architecture Lessons from Two Digital Transformations

I have been fortunate to lead not just one, but two digital transformation projects as an Architect. And I would say I got lucky under many different counts. First piece of luck – one of the projects was a failure! 

How can that be lucky you ask? Read on.

There were other strokes of luck too, and each shaped how I think about architecture today. The fact that I’m here, reflecting on both, is proof that I learnt a lot. My goal is to share those insights, so they serve anyone navigating their own transformations. 

One project was in healthcare; the other was in finance.

One was with a large enterprise, the other a mid-sized firm. 

One offered flexibility, thanks to being in the Research department. The other was rigidly premeditated, with the ‘climax’ already decided by the executives. 

Let me break each down, what was the project about, what I did and what I learnt. You’ll see why one failed while the other succeeded and where architecture made all the difference when leveraged right, and was a liability when ignored. 

The One That Went Right

A major hospital chain set out to digitally transform, looking to move to cloud, leverage AI/ML for advanced analytics. But they were also understandably cautious, concerned about security, regulations, effectiveness and cost. 

At the time, I was with a large sized and well-established organization known for its healthcare expertise. 

The project was being done by the Research wing of the organization, which meant, we were free to experiment, work in a “startup-like mode” and most importantly have the “fail-fast” approach. Interestingly, the organization had an already established Scaled Agile Path, which meant we were a Value Stream, with Value Stream Owner, Architect and Release Train Engineer lead management team driving nearly ten scrum teams, each with cross functional skills, supported by a Scrum Master and a Product Owner. 

Our first step was understanding the geographical spread of the client, here primarily across North America, and addressing their data security. We are talking HIPAA compliances, data privacy, de-identification of personal and medical data etc. They were very open to the cloud concept, but factoring the size of data generated was an important design pattern.

A single ICU patient, monitored every 5 minutes for 2 days generated 576 data points just for heart rate! Now multiply that across vitals, across patients, and we are working with massive volumes! Our design strategy then tuned a hybrid approach – data on-premises, application on-cloud.

Use of AI for pattern detection in disease progression, patient response to treatment, ML for trend detection, forecasting ICU demand, predicting readmission of patients were the value propositions we, as a research-based value stream, were offering to our customers. Designing these models to run across the hybrid infrastructure, with distributed data centers, was both a challenge and a very key architectural decision. 

The approach was always, “Lets work in a start-up mode”. Try a concept, show it to the customer using an extremely simple working model, even a jupyter notebook for that matter to demonstrate a model, analyze if it can be expanded to meet their requirements and if not, just scrap it and begin the next iteration. 

This discipline ensured that weren’t wasting time and effort in the wrong activity, and at the same time getting closer to building what our client was looking for. 

What was interesting was the extra innovation week we got each PI (Program Increment) cycle, to actually record our findings that were unique, into Intellectual Property building material. This led to several patent submissions in the 1 year that we spent on the project. 

The outcome was strong; the client accepted the solution, and we transitioned implementation to the engineering division. 

The Transformation That Taught Me More

I next joined a digital transformation effort as an Enterprise Architect for a niche financial institution. The company was operating in a much smaller market, for a much smaller customer base, on a much smaller portfolio of products and services. Having been around for over a century, it is no surprise that much of their infrastructure was outdated and applications were deeply legacy. 

The prevailing mindset was that of “Don’t touch what isn’t broken”. This approach, though seemingly practical, reflected a deeper inertia, rooted in a cash-strapped culture and leadership priorities that often leaned towards prestige over progress.

Over the years, the organization had acquired others in an attempt to grow its customer base. These mergers and acquisitions lead to inheritance of a lot more legacy estate. The mess burgeoned to an extent that they needed a transformation, not now, but yesterday! 

That is exactly where the Enterprise Architecture practice comes into picture. Strategically, a green field approach was suggested. A brand-new system from scratch, that has modern data centers for the infrastructure, cloud platforms for the applications, plug and play architecture or composable architecture as it is better known, for technology, unified yet diversified multi-branding under one umbrella and the whole works. 

Where things slowly started taking a downhill turn is when they decided to “outsource” the entire development of this new and shiny platform to a vendor. The reasoning was that the organization did not want to diversify from being a banking institution and turn into an IT heavy organization. They sought experienced engineering teams who could hit the ground running and deliver in 2 years flat. 

A secret we all know is that IT service providers survive on long term contracts with their clients. When this vendor then chanced upon the cash-strapped client, they drew out a long 7-year transformation plan. Not only did the organization commit at a steep price but also hired senior leaders from the vendor for fancy roles like “transformation director”, “head of cloud”, and similar.

For the vendor, this was a well-paying engineering contract, not a mission. The new hires, still loyal to their previous employer, focused more on maintaining the engagement than on building internal capability. It was not that passionate “this is the IT strategy that is going to ensure robust and secure solutions and products that makes the organization stand out to customers, investors and regulatory authorities” or “this Architectural North Star is going to increase sales because it addresses these technology aspects”. 

And thus, it is fair to say: maybe it will be profitable in the long run. But as a digital transformation, it failed. 

Lessons From an Architect

Looking back, here is what stood out, having a mission and vision, understanding the “why”, aligning architectural choices to the client’s true needs – that’s what makes a transformation robust. Money may buy “projects”, but it’s principles and thoughtful technology choices that pay off in the long run.

Comparison Table (Success vs Failure)

What I Ask Before Starting Any New Digital Transformation

1. What is the “why” behind this transformation? Do business and tech teams share the same understanding of it?
2. How measurable are the architecture visions? Are they aligned and clearly tied to the outcomes? 
3. Who owns the transformation? 
4. How much space do the tech team get to experiment?
5. Will this be really scalable or are we just trying to get through a short-term gain?

If I then summarize this experience in one sentence, I’d say “success or failure, an architect is always taking away tech lessons from everything”. That’s the value they bring to the next project; that’s the experience that makes an architect an architect!