How can you prepare for the future of system architecture?

I believe that continuously learning helps enhance our professional growth and career prospects. Staying curious and investing time in learning though activities such as reading books, blogs, participating in online courses, following industry experts and leaders allows us to keep growing in system architecture. Applied learning and practice solidify our understanding and help us grasp how the concepts work in real-world contexts.

Indeed, knowledge is power and a starting point for architectural transformation. However, obtaining the knowledge isn't easy because we have limited time to do many things. An hour-long podcast is still 30 minutes, even on 2X speed. Many of us sacrifice personal time to be in sync with the industry, which can lead to burnout. I found two options that helped me get in sync. First, take a technology radar, or CNCF Cloud Native Landscape, and spend no more than 10-15 minutes to understand each technology or product and what is behind it in terms of business and technical differentiators. Second, learn from others quickly by asking the right questions, and don’t be afraid to ask dumb questions because it will save you a lot of time.

I believe "studying real-world scenarios" should be highlighted in this section or perhaps even deserves its own dedicated section as it has greatly helped me in architecture design. By looking at practical situations that show the best ways to do things, the problems that can come up, and the lessons learned, I've gained a much better understanding of how to create successful and creative architectural solutions.

When learning new techniques I always ask myself - what is the purpose of this solution? In which cases it is suitable? Why this, not anything else?

Learn from the one who is decorated by war wounds than the one with shiny armor. Learn from the ones who really attempted large scale work. Learn from others mistakes too!

In the rapidly evolving world of technology, the future of system architecture promises unprecedented scalability, resilience, and adaptability. To be prepared, professionals should focus on mastering cloud-native principles, understanding the nuances of microservices architectures, and delving into edge computing. As architectures become increasingly distributed, a keen understanding of network design and zero-trust security models becomes paramount. Continuous learning is essential, given the accelerated pace of advancements in AI and quantum computing which could reshape our conventional architecture approaches. Moreover, soft skills, particularly the ability to grasp and cater to business needs, will be crucial.

I think this is the core of the article. The "right architecture" isn't just about the technology. The people, the project, the resources available, the time constraints, etc. have a lot of influence on the architecture. A lot of systems with poor architecture have provided a lot of value to a lot of users (and have made a lot of money). And a lot of systems with amazing architecture have failed entirely. The question I ask most when making an architectural choice is, "does this provide the most value to my users?" Sometimes, the answer is contrary to my preference. When that happens, I build only what I need to build now but build it in a way that's easy to change in the future.

To embrace change, I believe the best approach is to dissociate technology from design, as much as possible. Between both, definitely technologies are the ones that change faster and more frequently. So, if your design is efficient at both solving problems and allowing different technologies to implement them, strategies at macro level will remain the same and you will stick to the overall original plan.

imo, good architecture is measurably secure, resilient & flexible; and doesn't happen without a good architect. A good architect is able to adopt new patterns, processes & technologies. To do so requires someone who is comfortable with change and the foresight to manage it's impact. It is the same today as it was

Keep it simple. Do not boil entire pacific ocean for a hot shower, rather switch on the geyser. Address one problem at a time. Prioritize what's most needed.

Architect according to industry accepted standards. Do not create bespoke protocols, structures and the like where standards exist. Also, model things as they truly are in the domain(s).

The fundamentals are the same for a longer time than technologies. But the most core things that are all the time same are business needs transition and readiness for changes. Think as if your task is to translate the business needs to technical decisions. Think about the future - what are the challenges you or the stakeholder forsee. These two ideas are all the same and actual information about technologies and patterns is always accessible from various sources.

With the rapid growth of various technology stack and tools, it might seems overwhelming to keep track on the latest trends and practices. The important thing is to get know that they are there. It's important to add as much as tools as you can to your toolbelt, even if you are not a master in all of them. "I know about the things I don't know" is better then "I don't know what I don't know".

Unlike other aspects of our industry, architecture fundamentals change slowly. Some architecture standards defined in the 70s are still commonly used today so it's a safe bet that mastering architecture fundamentals should be a professional priority.

Architect truly needs to be a jack of all trades. It's usually better to have some knowledge on many things than have deep knowledge of few things. Understanding the whole and how everything works together is the key here. So, using hour or two to understand new technology or concept is usually enough to apreciate that such thing exists and know where to find more information when needed. Deepening the understanding comes naturarly during projects, but widening the knowledges takes effort.

Follow OCP, open closed principle. Open for extension. Closed for modification. Build it easy to replace a block, component, module.

Connected teams, outcome based design, and transparency are key to efficient system architecture design. This requires a “whole of engineering” approach where stakeholders use a commonly understood language to communicate expected behaviour and outcomes. Even where a function is not traditionally considered to be “engineering”, such as legal/regulatory/compliance, they still have inputs and considerations into the overall system architecture engineering function and need to be able to take part using the commonly understood language to express their outcomes. Transparent outcomes are inherently testable, they provide clear direction for delivery teams to execute, this reduces understandings, improves efficiency, and shortens time to market.

Whatever your technology role is, or will become, try to put the human at the center. Yes your engineering skills are awesome, yes, it ticks all the “ity” boxes for architecture, but if humans cannot or will not use it, you can bet there’s a reason. This problem may have been something that could have been averted through human centered design. “What?! Human Centered Design, is just for UX folks, right?” Trust me, you can do better, but you need to explore, listen, experiment and learn. No matter how technology-smart you think you are. ????

Learn and keep applying documentation techniques. Keeping track of changes and conveying information at different appropriate abstraction levels, in a consistent way, is a skill that will never grow old. Try to automate documentation generation to the maximum possible extent. The output of tools and practices like C4, DDD, BDD will yield excellent value when fed into an always up to date knowledge base.

Data privacy should be an integral element of the system design process. In a world where DATA is the new GOLD, today's data privacy practices are often akin to leaving the vault's door ajar, risking the security of our most precious information. To secure our digital treasures, we must fortify our data defenses with robust encryption, user empowerment, transparency, and ethical data stewardship.

Reduce Cognitive Load Cognitive load is “the amount of information that working memory can hold at one time” as defined by John Sweller’s Cognitive Load Theory. Sweller continues, “Since working memory has a limited capacity, instructional methods should avoid overloading it with additional activities that don’t directly contribute to learning.” It is imperative that leaders weave the Reduction of Cognitive Load into Feature Development, Project Planning, Architecture, and DevOps as fundamental to success as an outcome. Not only will doing so lend agility to delivery, it will free working memory, increasing the capacity needed for learning, innovation, and preparation for the future of your system design.

The most important skill a solutions architect has: putting the business at the center of everything. Most times we want to design that top-notch system with most recent technologies and fancy patterns, while forgetting to check if the company can afford such project, its maintenance after deployed, how much value it delivers to the business, and so on. Develop your ability to look from the C-levels perspective, and start criticizing how many resources your solution requires to solve problems, and if it can be cheaper/simpler without dropping any requirements. Most times, C-levels prefer cheaper solutions that must be evolved in a few years but deliver value to the company much faster