Application and Architecture Modernization - Where do we Start?

Hint: Start with the user and the user needs

Having dedicated a significant portion of my career to application and architecture modernization projects, I've experienced the full spectrum of outcomes. Some projects have been triumphs, while others have been monumental failures. As a Principal Engineer at the NY Times, I'm immersed in one of the most exhilarating and demanding modernization projects, a journey I'm most eager to complete.

Sometimes, when the problem is so complex, it can be overwhelming. And it doesn't matter at what point you start looking at the problem space—whether you were there when the company first decided its strategy on how to modernize it and where to spend the dollars or if you are looking at the problem space after the strategy is already set in place.

Reflecting on my past work in the application and architecture modernization arena, I've discerned a recurring theme. Projects that prioritized understanding the users and their needs from the outset had a significantly higher success rate than those that treated user needs as an afterthought during testing.

Often, it takes more work to focus on the architectural complexity alone. As Architects, we like to take comfort in familiar things. We've spent many years studying software design and architecture and still learning daily. Domain-Driven Design, Loose Coupling, Cohesion, and what style of architecture must we use for the given problem context: Layered Architecture, Vertical Slice Architecture, Micro Services? What are the different communication styles between these components and services: RPC, and Messaging? And what about the cloud: Azure, AWS, GCP? The list goes on and on. When we start looking at the System, we see services, components, databases, and all of the technical and infrastructure parts. These parts make sense for us, the techies.

One of my favorite Systems Thinkers, Dr. Russ Ackoff, said this, and it's stuck with me: "It is much better to do the right thing wronger than the wrong thing righter."

If we focus all our efforts only on these technological aspects of modernization, we could lose sight of why we are building or modernizing the System in the first place. What's the point of spending months and months creating all these services and components if the users who use the System are still stuck with the same problems? Can we call it modernization if we have replaced all of the legacy parts with new shiny things built with the technology of today if the users don't see any benefits in the behavior of the System?

We can take a systematic approach to modernization by first understanding the System's users and their needs. Once we have determined this, we can see how today's System fulfills those user needs. What are the components and services involved? Do these belong to the same team or different teams? What are the pain points from both the user perspective and architectural perspective? A visual approach works best to do this well and bring about a shared understanding of all parties involved.

I've learned and used many diagrams to describe the System: Data Flow Diagrams, UML, C4 Modeling, State Flow Diagrams, Sequence Diagrams, etc. These diagrams represent the parts of the System in a very techy, component-specific way. And then there are the arrows! In some of these diagrams, you have arrows that crisscross boxes and more arrows pointing to more boxes, which gives my brain a headache! But how do we connect these to the actual user using our System? I've learned that you can do both! We can be very intentional in the techy parts of the architecture while still starting with the user needs.

All the stars in the universe aligned for me and brought me to work closely with Olivia Cheng on the same modernization project briefly at the Times, and I was introduced to new ways of thinking from the realm of design about how to think about the user and user needs. My first introduction to Service Blueprints. Since then, I've been experimenting with the Service Blueprints approach for the past two years by tweaking the original concept from the design world and adding some architectural elements to the mix that help understand how the existing components work together to fulfill a user's need. So far, it has proven invaluable to my modernization work in understanding the System's current state of how a specific user need is being fulfilled.

Does this sound interesting? Come join my hands-on workshop at New Crafts on May 16th if you're in Paris. If not, stay tuned—I plan on writing a whole lot more on this topic in byte sizes!

A huge thanks to my dear friends Chris Richardson, without whom there probably wouldn't be a domainanalysis.io, and my dear friend Diana Montalion, who've been both constantly nudging, encouraging and nurturing my writing habit!