How should one define “architecture” as opposed to “engineering”?
I’ve always seen the seniority of a engineer as a question of how big a problem they can solve on their own.
Roughly, to convey the idea:
You can give someone new to programming small, contained tasks with lots of explicit instructions about how the task needs to integrate with other pieces
A mid-level dev is someone who can take a description of some portion of an application, and make it work within the context of that application.
A senior dev can build a medium-sized application from scratch, within the technical constraints of a shop.
A more senior dev can do that, and make technology choices along the way about what technologies to use to make it work well.
…but those aren’t hard and fast rules. And some people come out the gate as “senior” IMHO, even if they have to spend some time with a different title.
What the architect is asking is to view the problem even more generally than that. If you had to put together a number of applications to make the system work:
- What applications and services will you need?
- What pieces interact with customers, and which interact with each other?
- How will they communicate?
- Where will they store data?
- Where are the risks of failures?
- How will you provide reliability?
- How will you provide security?
So, in a sense technical architecture is like a building architecture. It’s the layout, or the plan. It shows whats needed for the various parts, how they hold together, and just as importantly why.
(BTW, I’ve had a similar growth curve explained to me for architects, ranging from architecting a family of related applications or a set of very complex features, to setting technical direction for a group, to making strategic technical decisions for an entire organization.)
That said, I think most engineers at all levels have to do some “architecting” as well. It’s not a bright line. It sounds like if you focus on the Big Picture first, and not get hung up on the implementation details, you’ll be more in line with what he’s looking for. BTW the ability to see the Big Picture as well as the Little Details is a huge asset in this industry, so this sounds like a great opportunity.
…Here’s an analogy. Let’s say you’re asked to create a Magic Black Box. As an engineer, you’re expected to obsess about the inner workings of the Magic Black Box. But as an architect, your focus is different. You might peek into the box out of curiosity, but you’re expected to obsess about everything around all the Magic Black Boxes.
Similar to that analogy, you might think about the architecture role as viewing the whole system as the magic box. So if take a Gigantic Glass Box and you put the customers, the client apps, the firewall, the service tier, the database, and even the devops guys inside, then as architect you’re to obsess about how to make that huge system box work well.