More Extremes and Pendulum Swings
In the past four years or so, I’ve been fortunate enough to work on numerous projects involving modern infrastructure. I’m referring to 100% cloud-based storage/network/compute environments used to drive customer-facing products. Some of these infrastructures were transformational (moving from legacy data centers to the cloud) and others were green fields born in the cloud from the get-go.
New Technology
The internet and world wide web aren’t that old, yet the technologies of today are radically different from just ten or so years ago. Once monolithic web applications have given way to microservice architectures with elegantly decoupled user interfaces for both HTML5 web user agents and mobile native applications.
A decade ago, it would have been hard to imagine the world of today. JavaScript runs everywhere; both on the frontend as well as on the backend. We’ve moved from document object model (DOM) designs to single page app (SPA) architectures. Developers must familiarize themselves with many more technologies and standards such as CORS, CSPs, and JWTs.
New Development and Release Processes
In addition to lots of new technologies, we’ve also introduced new development and software release paradigms. Development teams are (thankfully) moving away from big-bang release trains and gravitate towards smaller, more frequent releases via continuous integration and continuous deployment (CICD) frameworks.
Infrastructure itself (storage/compute/networking) is also radically different. In the “old days” there were servers; physical and virtual. Now there are containers and lambda functions driven from ephemeral (and immutable) production infrastructure described entirely as code. In other words, the definition of infrastructure itself is now a programmatic pattern that is checked into a source code repository, just like a product feature!
Roles Change
New technologies and new processes necessitate new roles as well. Former system administrators are encouraged to make the jump to DevOps. QA people may find themselves centralized in a QA team, co-located within dev teams, or oscillate between the two over time. Scrum masters, product managers, and UI/UX designers are also new faces at the table.
Modern EA for Modern Needs
In this brave new world, one may believe enterprise architecture is no longer needed. And why not? We have self-sustaining pods of product management, engineering, and design experts who can competently pump out features to customers at a rapid pace. However the holistic perspective enterprise architecture brings to the table is still valuable; perhaps more so than ever. It’s true that pod-style teams working on loosely-coupled microservices allot more autonomy than ever before. Yet it’s still dangerous for teams to work in complete isolation; especially when working on a common product.
Some examples of how enterprise architecture lends value in modern development environments follow.
Harmonizing Multiple Dev Streams
What constitutes an application? Is it the backend microservice? The front-end UI? Perhaps both web and mobile native UIs? All of the above?
What happens when two different teams work front-ends that are similar, but not the same? (Perhaps one team is using React version 15, and the other is using version 16.) Do end-users download different UIs for each “page” of the app?
How are APIs versioned, migrated, and deprecated? Do we have universal service registries to ensure developers aren’t writing conflicting service routes?
Software configuration management is yet another area of interest. Should there be one Git repo per microservice? Do we use GitFlow for structuring our master and feature branches?
From harmonizing versions of SPAs across teams to standardizing Git repo structure, enterprise architecture has entered a whole new world. Fortunately, the cross-functional discipline and rigor of EA can seamlessly carry over into this newer, faster-paced landscape with some lightweight adaptation.
Final Thoughts
As with any transformative endeavor, progress and change takes time. Teams are often eager to move quickly, but may underestimate the magnitude of altering development methodologies, release management, team structure, and of course technology stacks.
Trying to move a huge monolithic application to many smaller microservices while learning the ins-and-outs of all the aforementioned areas is staggeringly difficult. Instead, start with one microservice. There’s nothing wrong with cutting one’s teeth on something small.
Contact David Torre to learn more about building an enterprise architecture program.
