Ready to pull the ripcord on VMWare? On Nov 6, join my friends over at CAST and AWS to learn how software intelligence can speed up and derisk the move to best-fit cloud services. Register today!
In the complex ecosystem of software development, the role of a software architect is critical in shaping the direction and success of product development. Software architects wield significant influence that extends well beyond writing code or making isolated technical decisions. Software architects can use their unique position to shape product development and drive organizational success.
The Conductor of the Software Orchestra
To understand the influence of a software architect, let’s consider an orchestra. In a symphony, each musician focuses intensely on playing their instrument, much like developers concentrate on their specific coding tasks. The conductor, however, has a different role altogether. They don't produce any music directly, yet their influence shapes every note played.
Similarly, a software architect may not write much of the product code, but their influence touches every aspect of the software being developed. They provide the vision, coordination, and guidance that transforms individual efforts into a cohesive, harmonious product.
Breadth vs. Depth: The Architect's Perspective
One of the key ways architects influence product development is through their unique perspective. Unlike developers who often need to dive deep into specific areas of code, architects maintain a broader view. They understand how different components interact, how changes in one area might affect others, and how the entire system fits together to meet business and user needs.
This breadth of vision allows architects to:
Identify potential issues before they become problems
Suggest optimizations that improve overall system performance
Ensure consistency across different parts of the product
Align technical decisions with broader business goals
By maintaining this big-
The Podcast
Coming this fall!
Learn more about our recently announced podcast. Want to be a guest? Looking for sponsorship details? Want to simply know when it launches?
In world of software development, the role of a software architect often appears to stand at the top of the technical leadership ladder. With that responsibility comes an even greater need for continuous learning and adaptation. As someone who's spent years in the trenches of cloud architecture, I can tell you that the moment you stop learning is the moment you start becoming obsolete.
The Shifting Sands of Technology
Let's face it: the tech landscape is changing faster than ever before. What was cutting-edge yesterday is run-of-the-mill today and potentially outdated tomorrow. As a software architect, you're not just responsible for understanding these changes – you're expected to anticipate them, evaluate their impact, and guide your organization through the stormy seas of technological evolution.
Consider this: five years ago, who would have predicted the current explosion in AI and machine learning capabilities? Or the rapid adoption of serverless architectures? As an architect, it's not enough to simply keep pace; you need to stay ahead of the curve.
Learning: Not Just Nice-to-Have, But Mission-Critical
Here's a hard truth: self-study and advancement aren't just nice-to-haves for an architect – they're critical responsibilities. Your ability to learn and expand your knowledge directly impacts not just your own growth, but the growth of your entire project, team, and company.
Think about it this way: how can you make recommendations on technologies to meet new business requirements if you're not up-to-date on the latest available options? Your learning isn't just about personal development; it's about ensuring your company remains competitive and innovative.
Strategies for Continuous Learning
So, how do you stay on top of this never-ending wave of change? Here are some strategies I've found effective:
Hands-On Experimentation: One of the best ways to learn is by doing. Set aside time to write software using new tools and techniques. Try out new cloud services
Not all applications are created equal. Some are built to process transactions and maintain state, while others focus on delivering content, data, or experiences to users. For software architects and engineering leaders, distinguishing between these core application types is critical for making sound decisions about scalability, infrastructure, security, and data management.
Why?
Because how you design, build, construct, and operate your application is different based on your customer use patterns. Experiential applications are applications that provide an experience to your users. The longer the experience goes on, the more value your customers get from your application and, hence, the more valuable your application is to them. What are some examples of experiential applications? Look no further than your social media feed. By its very nature, social media provides experiences to their customers. The value of social media is directly related to the amount of time their customers spend in the application. The longer the user is around, the more valuable the service is to them. For the application owner of a social media application, this translates directly to more eyeballs watching more advertisements. More ads mean more money.
But not all applications are experiential. There are other types of applications, called transactional applications, that have the exact opposite expectation. They want their customers to get in, do something, and then leave again. Their customers are happier — corresponding to seeing more value — if they can get in and out of the application quickly. The more time they spend in the application, the less productive they are, and the less value the application has.
This is the exact opposite of experiential applications.
What are examples of transactional applications? Many e-commerce applications, such as Amazon.com, are transactional applications. When someone wants to check the status of an outstanding order, they want to g
Another critical principle in maintaining a safe and secure application running in the cloud is understanding the Principle of Least Privilege. The Principle of Least Privilege is an industry-standard security principle widely known to reduce the impact of bad actor attacks.
The idea behind the principle of least privilege is to:
Grant an entity the minimum permission it absolutely needs to perform its operations.
Grant no more permissions than that.
This principle applies to cloud infrastructures and on-premises infrastructures alike. It is a critical best practice for building a safe and secure cloud infrastructure.
Let’s take a look at an example. Figure 1 shows two services communicating via a message queue. Service A inserts messages into the queue, and those messages are read off the queue by Service B.
Figure 1. Two services with two permissions.
We see that Service A has a set of permissions assigned to it to access the queue, and Service B has a set of permissions assigned to it to access the queue.
What should those permissions be for these two services?
For Service A, the permissions granted should be:
Access to this single queue. No other queue should be accessible from this service.
This service should be able to write messages into the queue, but it should not be able to read or remove messages from the queue.
For Service B, the permissions granted should be:
Access to this single queue. No other queue should be accessible from this service.
This service should be able to read and remove messages from the queue, but it should not be able to write messages into the queue.
No other permissions should be granted to either service.
Why don’t we just grant both services full access to the queue? We don’t because if the service has an error or failure, or if it gets compromised by a bad actor, we don’t want it to be able to damage any more of our system than possible. Suppose we, for instance, give S
If you’ve ever spoken out to your iPhone and said “Hey Siri, what’s the weather in Seattle, WA”, or spoke to an Amazon Echo device and said “Alexa, turn on the bedroom lights”, you’ve given an AI a set of instructions for it to execute. You’ve given an AI a prompt.
In the Alexa case, the phrase is converted from an audio snippet into text, and that text is sent to an AI system — Amazon Alexa in this case — for it to determine the desired actions. The output of that process is a set of actions that must be executed (in this case, turn on the bedroom lights), and those tasks are then carried out by your home automation integration.
In the Siri iPhone case, the phrase is similarly converted to text and sent to the Apple Siri AI system for processing. Siri determines it needs to figure out the weather in Seattle, and issues the appropriate commands to get that information. It then converts that weather information into an appropriate response and responds with “The weather in Seattle is rainy and 52 degrees”.
Yet sometimes you don’t get the answers you want. If you’ve ever said the following to your echo device:
“Hey Alexa, what’s the color of chocolate?”
and gotten the response:
“Nestle’s chocolate bars are wrapped in a blue wrapper with gold foil”
you know the frustrations involved in a mis-understood request. You thought you gave the AI a clear query, but the AI was thinking something totally unrelated to what you were looking for. You were looking for an answer about the different types of chocolate and the colors available for those different types, yet you received information about the brand colors of a particular chocolate bar wrapper.
These are all examples of AI prompts, but they are all extremely simple examples. In sophisticated AI systems, longer and complex prompts can be hundreds, thousands, or even tens of thousands of words long
As modern applications grow more complex and valuable, their security becomes increasingly critical. Yet many organizations still operate with a flat security model—one breach and attackers gain access to everything. This approach is like building a house with a reinforced front door but paper-thin walls. How can you improve your application security to reduce your risk of attack? Use isolation zones. Isolation zones aren’t just a best practice—it’s the difference between a minor security incident and a catastrophic breach that makes headlines.
How Do You Use Security Zones?
When creating the production operational backend infrastructure for a modern application, it’s generally considered best practice for security purposes to split the application infrastructure into multiple security zones. This is so that a security breach in one area can still be limited to impact only the resources within that one zone. Done correctly, this can take a security breach that might otherwise be a massive impact on your application integrity and turn it into a much smaller, perhaps insignificant breach that has minimal impact.
There are many ways to architect your security zones, but a typical model involves three standard zones. In this model, the three zones are called the public zone, the private zone, and the DMZ.
The three zones have the following purposes:
Public zone. This is the zone that is connected directly to the internet. It’s exposed to traffic coming from the internet and, as such, is the least secure zone and the most vulnerable zone to compromises. The only services that exist in this zone are the services that absolutely must be connected directly to the internet to give access to your application. Examples include API Gateways, traffic managers, firewalls, load balancers, and similar services.
Private zone. This is the zone where the vast majority of your backend application exists. All of your data is stored in databas
Both you and your cloud provider have a critical role in keeping your application safe. It’s a principle of security known as the Principle of Shared Responsibility. It describes a model for assigning ownership of various security aspects between the cloud provider and you.
It’s a principle that has been championed heavily by AWS, but it applies to all cloud providers in all situations.
The key to the principle is an agreed-upon set of responsibilities for keeping the application safe for each cloud service you use within an application. Each individual service and each individual service provider have a different set of responsibilities — and hence a different set of assumptions — about who is responsible for each action. To build a secure application, you must understand the assumptions made by the cloud provider, what they are responsible for, and what you are responsible for.
To illustrate this, let’s look at an example. Let’s look at the AWS EC2 service. The AWS EC2 service provides virtual servers for your application to utilize as it needs. Keeping the virtual servers secure involves a multi-layer security model. The different layers of security responsibility for this service are shown in Figure 1.
Figure 1. Principle of Shared Responsibility as applied to the AWS EC2 service.
When you operate an application running on one or more EC2 instances, you create an agreement between you and AWS to manage the application’s security on those services. For the EC2 service, AWS is responsible for the following security aspects of operating your application:
Facilities security. AWS is responsible for maintaining the security of the physical data center and the physical plant that operates that data center.
Hardware security. AWS is responsible for securing all of the hardware necessary for running the EC2 service.
Network infrastructure security. AWS is responsible for the networking between systems and the hardware
The software development landscape has shifted dramatically. In 2024, a whopping 62% of professional developers use AI in their development process. This has done wonders for the productivity of an average software developer, and has led many people to assume this means that either we need fewer software developers or, more likely, we can get more and better software developed with existing staff.
However, there are issues with this shift.
Last year, I read and loved the 2024 GitClear AI report on the downward pressure that AI has put on code quality—and the corresponding increase in code complexity. I wrote on this topic last year in my newsletter.
This year, the 2025 GitClear AI Code Quality Research report analyzed 211 million lines of code across five years. This report shows that as AI usage has increased this last year, the issues with the developed code in large and complex systems have continued to increase as well.
In short, as AI is used more and more in the software development process, we’ve seen a corresponding increase in complexity and code size. The result? Developers are spending more time refactoring code and less time writing new code.
The Growing Epidemic of Code Duplication
The 2025 GitClear report discovered something unprecedented—for the first time in recorded history, the frequency of “Copy/Pasted” lines exceeded “Moved” lines in code repositories. This represents a fundamental change in how our industry builds software.
Why, exactly, is this true? When a developer “moves” code, they’re typically refactoring it—rearranging existing functionality into more reusable modules. This is the hallmark of good software architecture and something that all but the greenest developers do regularly. Unfortunately, it’s also something that AI software agents almost never do.
You see, code that is “copy/pasted” represents duplication, which directly violates the DRY
Software Architecture Insights is a regular newsletter providing insights into architecting your modern applications at scale. Modern digital businesses continually struggle with building new and innovative applications that also maintain high availability at cloud-scale.
Software Architecture Insights gives you, well, insights into how tech leaders and software architects function effectively. Learn how to build, operate, and maintain applications at scale, innovate new features and capabilities, and keep teams fully engaged. All while effectively managing IT complexity and technical debt.
Insightful Knowledge and Experience
All of the articles presented in Software Architecture Insights come from thought leader Lee Atchison. Lee has over 36 years of industry experience, including seven years working at Amazon and AWS building the framework that modern digital applications use today.
Lee has been widely quoted in multiple technology publications, including InfoWorld, Diginomica, Cloud Native Now, DevOps Journal, CIO Review, Software Engineering Daily, and Techstrong Live. Lee has written several books, and he’s been a featured speaker at events across the globe. Lee’s helped companies from Amazon to New Relic, Disney to Major League Baseball, Uptycs to Ory.
And he can help you, too.
How do I start?
Quite simple. Just click the subscribe button below, and you'll start receiving content from Lee regularly. We respect your privacy, and you can unsubscribe at any time.
Subscribe
This page was created by