In Part 1, Francesco Abbruzzese and Gabriel Baptista discussed the evolving role of software architects in the age of AI. In this second excerpt from our conversation, we shift focus to the architectural decisions shaping today’s enterprise applications—from cloud-native resilience to security by design, edge computing, and long-term maintainability.
Q: Cloud-native computing is reshaping enterprise systems. What architectural practices should teams adopt to ensure resilience and adaptability?
Gabriel:
In the near future, I believe most applications will be cloud-native. Some systems might run on the edge, but even those will likely rely on the cloud in some way. That means everyone working in software today needs to think cloud-first.
When it comes to resilience and adaptability, we’ve dedicated several chapters in the book to those topics. The development cycle is faster than ever, and new tools and practices emerge constantly. So we need architectures that can keep up.
It starts with writing clean, observable code—code that’s tied to retries, performance metrics, and real-time feedback. If you’re building enterprise applications, there’s no room for downtime. The architecture needs to be designed from day one with 24/7 operation in mind.
Francesco:
In my view, cloud-native really means distributed computing, with added adaptability. The core idea is that your system must remain reliable even when distributed—and that means getting communication right.
You need to adopt the right architectural patterns. Use orchestrators like Kubernetes, implement automatic scaling, collect metrics, and adapt your system based on those metrics. Modern microservices follow the theory of reliable communication. Messages can be delayed, but not lost. That’s essential.
Microservices often work like an assembly line—processing and transferring data step by step. Any failure in that chain can break the system. So we go into depth in the book on the foundations of distributed computing and microservice design, because they’re central to resilient cloud-native architecture.
Q: Considering how sophisticated modern threats have become, how can teams integrate security by design principles throughout the architecture?
Francesco:
Security by design is not a separate topic—it’s a way of thinking. It has to be part of how you code and architect systems from the very beginning.
First and foremost, education is key. Teams need to understand the correct way to do things, rather than trying to invent their own solutions. You also need to choose your team carefully—skills and mindset matter.
Code reviews, especially by security experts, are very effective. They help catch vulnerabilities and ensure best practices are actually followed.
Another important point is to rely on trusted, well-tested libraries and stacks. Don’t try to build your own authentication system—use the tools that already exist and have been proven to work.
Gabriel:
I agree completely, and I’ll add a few examples. Architects should be familiar with OWASP guidelines—especially the top 10 vulnerabilities in APIs. These are things every architect should study and apply.
In terms of implementation, think DevSecOps. Add static analysis tools to your CI/CD pipeline. They’ll flag security issues early and help the team build more secure code.
And as Francesco mentioned, library choice is critical. One of the biggest risks in software security today is using outdated or vulnerable third-party components. So staying up to date isn’t just a maintenance task—it’s a security measure.
Q: What strategies should architects use to ensure long-term architectural integrity?
Gabriel:
Architecture isn’t something you set and forget—it evolves. But if you build with the right principles in place—resilience, observability, security—you’ll know when and how to adapt it.
My advice is to start simple. Not every project needs the most complex architecture from day one. Monitor your system continuously and evolve when the data tells you it’s time. Cloud platforms make this much easier than it used to be.
A good pipeline also makes a difference. From analysis and code review to testing and release, your workflow should help you understand whether your application is doing what it’s supposed to—and whether it needs to change.
Francesco:
Yes, and I’d add that using Domain-Driven Design and microservices is key. These patterns make it easier to change just a part of the system without affecting everything else.
If your architecture is modular, each microservice can use different internal designs. That flexibility is powerful. It lets you evolve small pieces of your application instead of rewriting it entirely every time something changes.
Good monitoring helps, too. If you know how your system behaves in production, you’ll know when it’s time to adjust.
Q: How do you see the integration of edge computing and increased data-centricity shaping the future of enterprise architecture?
Francesco:
The future is definitely in collecting and using peripheral data to make better decisions. That means your application has to work with data coming from different sources, at different levels of detail.
But there’s a tension here. On one hand, each microservice should manage its own data—sometimes because of geography, sometimes due to business constraints. On the other hand, we need consolidated data for decision-making.
That’s where worker microservices come in. They can aggregate data from different sources and transform it into a useful format for analysis.
The key is to structure the data in a way that makes it meaningful and usable. Consolidation is going to be central to future systems—and AI and statistical tools will help us get there.
Gabriel:
Edge computing is going to affect every industry. Decisions will be made closer to where data is generated, and that data will need to flow back to central systems for deeper analysis.
This reinforces the need for distributed systems. You don’t want to send all raw data from the edge—you want to send decisions or key insights. That means architectures need to be designed from the ground up for distribution and selective data flow.
Patterns like microservices and DDD are going to be more important than ever.
Q: How can architects ensure their designs contribute to real business outcomes—especially in high-impact industries?
Francesco:
It starts with changing how we think about requirements. Don’t just gather what users ask for—ask what adds value to the business. Every requirement should be evaluated through that lens.
DevOps is key. It gives you feedback quickly, so you can measure whether your architecture is delivering the value it’s supposed to. Combine that with modular architecture—like DDD and microservices—and you’ll be able to make precise changes that maximise business value.
The goal is to avoid having to rewrite large parts of your system. Instead, make small, well-targeted changes that align with business needs.
Gabriel:
That’s exactly it. DevOps creates a tight feedback loop. When you have a solid architecture and a good DevOps cycle, you can move faster, deliver better outcomes, and adapt to what the business really needs.
With that in place, it becomes much easier to maintain alignment between the technical and the strategic—and that’s what turns a system into a success.
To hear the full conversation—including insights on developer mentorship, working across distributed teams, and lessons from real-world enterprise projects—watch the complete video interview in our playlist here.
United States
Great Britain
India
Germany
France
Canada
Russia
Spain
Brazil
Australia
Singapore
Canary Islands
Hungary
Ukraine
Luxembourg
Estonia
Lithuania
South Korea
Turkey
Switzerland
Colombia
Taiwan
Chile
Norway
Ecuador
Indonesia
New Zealand
Cyprus
Denmark
Finland
Poland
Malta
Czechia
Austria
Sweden
Italy
Egypt
Belgium
Portugal
Slovenia
Ireland
Romania
Greece
Argentina
Netherlands
Bulgaria
Latvia
South Africa
Malaysia
Japan
Slovakia
Philippines
Mexico
Thailand
