Architecture changes are hard. An MVP approach to architecture can eliminate many of the problems current architecture design faces. Instead of PowerPoint marketecture (i.e., architecture in a nice picture, as marketing brochures), an MVP for architecture would enable architects to design the key components, test the feasibility, and identify any underlying challenges. This way they don’t have to wait until late application development stages to realize the underlying architecture issues.
In 2001, I was a part of the team that helped a major payment network re-engineer its mainframe based transaction process systems. Sixteen years later, in 2017, when I got the phone call from the client team that the same payment network company was now ready to re-architect the re-engineered systems again, I was shocked since I was probably one of the few people who still remember the 2001 reengineering effort.
Architecture Transformation Is Hard!
Over the last 30 years of computing, IT has gone through at least 3 major architectural changes. In the 90’s, companies moved from mainframe and green-screen terminals to PC based client server computing. In the late 90’s and early 2000’s, companies migrated again from PC based client server computing to Internet and Web and mobile computing. Companies are now undergoing a third major architecture change, migrating from on-premise monolithic net applications to modular, agile, cloud based computing, with heavy emphasis on AI and advanced analytics. Some would argue that computing has migrated from mainframe based centralized computing to client/server and Internet based distributed computing to a new era of data-centric computing.
Architectural transformation efforts are some of the biggest challenges an IT organization will embark on. The challenges are even greater if the changes are to made to existing core systems, vs. just creating new systems and platforms. As one of my CIO clients said, “Those application architecture modernization efforts are like replacing an airplane engine while flying the plane 39,000 feet above the ground”.
There are a number of key factors that drive the complexity of migrating system architectures:
- Uncertainty abound: Most IT staff haven’t dealt with major architecture migration efforts before. On one hand, people are excited about the future. On the other hand, with the limited experience around, there is great anxiety of how to make this happen.
- Limited skills available: Such application architecture migration often requires in-depth knowledge of both the legacy applications and the new technologies. It’s difficult to find staff who can handle both sides and understand the complexities.
- Scope creep: Not many companies are willing to fund new application architecture changes without any functionality increase. The architecture transformation efforts would then become significant upgrades of architecture AND functionality. The effort becomes a hairy ball of complex changes.
- Conflict of interest by third party advisors: Given the complexity of those changes, companies often engage third parties to help them design and develop the strategy. Unfortunately, many of the so-called advisors often are conflicted with their own interest in getting long term follow on work, vs. being objective and providing the unbiased approach on how to make this happen.
Past Architecture Design Approach Often Didn’t Work
In the past, to handle this, companies often relied on a central architecture team to create the blueprint for the architecture. While on paper this is a great approach, IT often ran into more problems. The central architects often relied on theoretical principles and may end up with an ivory tower design that is impossible to accomplish. The final design became nice looking PowerPoints that were never built in reality.
Given the speed of technology advances, it is also mission impossible for the central architects to predict what is going to happen in the next 5-10 years and try to design systems based on their foresight. The design would either be too theoretical and can’t be implemented or they became obsolete the moment the ink on the architecture design paper is dry.
Even when the central team did create a sensible design, given that many companies separate central enterprise architecture function from the solution architecture teams, the solution architects would often deviate from the top-down blueprint and take shortcuts to make sure they can deliver on time.
So is there an alternative companies can take with architecture transformation?
The MVP Approach to Architecture Transformation
Over the last couple of years, I have taken an alternate Architecture MVP approach to work with my clients to re-platform their core applications and design next generation technology solutions. My clients and I took an agile approach to architecture development and aimed to replace the nice-looking PowerPoint with real usable code that would serve as the foundation for future functionality development.
As we described above, traditional architecture design would consist of principles, descriptions of capabilities to be delivered, chunking of the architecture into individual components, and description of core technologies that would be used. Most of the output would be Word or PowerPoint documents that abstractly describe the future. It is difficult to understand, and the biggest challenge is that no one knows if the architecture with all the various technology components would even work.
The Architecture MVP approach, however, focuses on creating a real-life MVP based on the principles and descriptions. The MVP would focus both on the description of the architecture, and the real life feasibility assessment, based on actual code that is developed. Just like any other MVP, the architecture developed here would be a minimal viable product – which means that it won’t have all the bells and whistles. But it will show conceptually how this would work.
For a medical device company, my clients, my team, and I created an MVP for a cloud-based surgery data platform. Before the work started, we brainstormed together the key questions the architecture design should be able to answer and key feasibility issues that we need to test for. For example, for the communication between endpoints and the cloud, we needed to test if the new data transfer protocol can handle the volume. We also needed to test Edge computing since we were betting that EDGE computing would be essential for the future and we needed to be able to do AI on the Edge. Thirdly, we must be able to support HL7, using that as the core data exchange between the hospitals, our client, and various ecosystem partners.
Once the key questions and key tests were defined, we spent a month sketching out the answers. We debated daily and developed the first cut of the strawman architecture across application, data, and infrastructure.
We then assembled a number of teams to create an architecture MVP. The MVP was treated as a real product with the Chief Architect serving as the Product Manager. Individual product teams were assembled across edge devices, data platforms, and cloud infrastructure. We had bi-weekly sprints and monthly demo sessions to make sure all the components can be tested again. In 3 months, the MVP was created. The MVP was fully functional across the key components such as Edge computing, even though it didn’t have any real functionality and wouldn’t be able to support real-life volume and reliability requirements. But the MVP provided the foundation where future releases can build on.
As this example demonstrated, Architecture MVP is a great way to design new architecture and test key architectural concepts. This approach can support the migration of existing code also. For another industrial automation client, my team and the client were designing a new platform that migrated Microsoft Windows applications to a new IOT based architecture. In addition to designing the new platform architecture, the Architecture MVP also included the test of code migration. The teams took 5% of existing application code and manually migrated the code onto the new platform MVP. This allows the teams to fully demonstrate the feasibility of the future design.
One of the key issues for Architecture is the disjoint nature between Architecture and software development. The Architecture MVP method is like ArchDev, linking architecture and development together, similar to DevOps that connects IT application development and IT operations. The MVP can typically be done in 3-5 months, with one month dedicated to sprints that define the strawman architecture. The second and third month would focus on the sprints that create the code base for the Architecture MVP. For bigger efforts, a fourth month can be added to ensure we get a true “minimal viable” architecture product. The last month would focus on refining the strawman architecture and develop the roadmap on actual architecture completion.
Architecture is a difficult problem. Thus like all MVPs, it’s possible that the Architecture MVP would end up showing the architecture concept is actually not feasible in real life. But it is better to determine this after 3-4 months, vs. after 3 to 4 years of effort. If we want to fail, we better fail fast!
Architecture MVP is a real life methodology that has worked for a number of my clients. It enables clients to experiment and design architecture that is feasible in real life. I hope this works for you too!
