It's All Around Scope
We've all heard about different architectural patterns, from layered monoliths to microservices. And they all have their place. The thing that gets me is that many people look at enterprise architecture and think it's fundamentally different than other types of software architecture.
It's not exactly the same, but then, no two architectures are the same. If they were you'd end up with the same results, maybe with a different color scheme. Kind of like the way you can use different themes and make a presentation different. You're not changing the content at all, but it looks different. For some folks that might be enough, but I don't know about you, but I'm always solving new problems, so the old solutions won't work. They may be similar, and there's lots to learn from the past, but it's not just a copy. The same can be said for the role of enterprise architect vs writing a design doc for a function or library. But those are topics for later.
Today's topic is the difference between enterprise architecture in particular and software architecture in general. I maintain that it's really just a matter of scope. Both should be SOLID. Both should be DRY. Both should remember YAGNI.
Done right each of the parts of your microservice will follow the same principles as the overall system, just at a different scale. A set of concurrent go routines and a channel switch is an event based architecture. Calling different interfaces inside a single executable is (logically) the same as using calling the API of another part of your microservice architecture.
In either case you need to look at constraints. Constraints like storage, bandwidth, and execution time. One might be dominated by network bandwidth and latencies, while another might be dominated by bus bandwidth and L1/L2 cache hits, but the idea is the same. It's just a difference of scope.
In either case you need to understand requirements. And not just the explicit requirements, but the non-functional requirements (NFRs) as well. Some of the requirements might be different, but you still need to meet them. The "-ilities" are a thing for both. And it might feel like there are more requirements from the business/marketing/sales/finance departments in enterprise architecture, but I promise you, if you build a library that's too slow/takes too much memory/doesn't have the right feature set someone is going to let you know.
What do you think? Is enterprise architecture fundamentally different from any other software architecture? What did I miss? Let's discuss in the comments.
