I definitely see these forces at work at my current gig. In our context the lines separating what should be domain-specific boundaries are blurry. The main system is a monolithic codebase which was developed with a "wild west architecture" for over a decade before engineering leadership realized the tech debt was interfering with feature development. We've tried to draw domain boundaries but that initial lack of discipline meant that things were too far gone to easily separate them, and senior leadership has never been willing to invest in paying down this debt.
The points about shared tech and infrastructure hit pretty hard because it's a single monorepo deployed to homogeneous application servers. When we do bump up against issues with infrastructure we almost always end up building one-off shims. Our architects call them Microservices.
Code contribution is messy too. For any given feature, core functionality is typically owned by one team along with some of the downstream effects. The rest of the downstream effects are owned by other teams scattered across different verticals and often continents. It's rarely safe to change the core functionality of a feature by itself. Dysfunctional politics leads to projects getting delayed because of miscommunication and different priorities, and we can't risk encroaching on someone else's fiefdom. I recently burned a lot of political capital doing just that because a critical deadline was at risk.
That was a helpful read, thanks. My company (also in Melbourne!) is probably one stage of growth beneath this. We have “verticals” and “teams” but don’t really have the layer in the middle yet (“domains”).
As we’ve grown from only a few teams, to multiple verticals, we’ve tried to jump straight from unclear boundaries and implicit APIs to fully versioned services and packages.
Thinking about these as solutions to communication problems, where the problems differ in degree depending on the number of teams interacting with it, is a useful way of framing the discussions.
Hopefully it brings some clarity to discussions about when the light-and-loose methods are okay, and when the more heavy processes are justified.
The proposal seems to be that software design guidance correspond to existing hierarchical organization structure. A formalization of Conway's Law [0]. The more people in the hierarchy that coordination touches, the looser the coupling.
On the other hand, how many times recently have we seen comments here to the effect: this reads like it was written by a high schooler with an axe to grind.
He is obviously shorthanding Software Architect or Information Architect here. It clearly has nothing to do with actual buildings or other civil structures and he isn't using the legal label either (eg. "Licensed Professional Architect" in California).
I think that while your common sense is correct, the title of just "Architect" is protected legally.
To become a licensed Architect, one must have a degree from an NAAB-accredited program, complete 3,740 hours under the guidance of an Architect, and complete a long and difficult 7-part exam.
He can call himself a Software Architect, Information Architect, Technology Architect, or any other variation — but he is not allowed to call himself just Architect and can be sued for doing so.
This type of pedantic and overzealous gatekeeping, with no benefit to the public, got slapped down in US District Court. You can't just take over basic English words.
I mean, either way the guys not in the US, and the sites owned by an English guy ( who to be fair, does now appear to live in the US, so the entire thread makes no sense unless you start from the position that the US owns all of English language.
> the title of just "Architect" is protected legally.
Only if you're using the title to represent yourself as a certified architect, and no one in the public is going to be confused about what a software architect does and hire them to build a bridge. Otherwise, no, it's not legally protected and even then it varies by state.
I can legally start a match making company and have the title "Architect" without facing any legal consequences.
First: It's a blog post; it's not an advertisement for architectural services. "Legally protected" isn't going to stop something that isn't legally recognizable as an infringing use of the word.
Second: Reading about three words of that blog post is enough to make it clear that, whatever we're talking about, we're not talking about architecting buildings - and only in that sense is it legally protected.
There are things that are worth being offended about. This isn't one.
Former registered artichoke here: AAdip, RIBA & HKIA
No offense taken. Nonetheless may I mock the ways some people puff themselves up?
Botcher describes himself this way:
> Evan is an experienced architect and technology leader, working to make organisations more successful at delivering and sustaining technology. He spends his time traversing the communication and decision making pathways of organisations at scale and helping people manage complexity.
> Formerly a technical director at Thoughtworks, Evan is now the Head of Architecture at business management platform MYOB based in Australia.
Anyway, fingers crossed that Botcher does not botch things up too much as an architect in an accounting firm.
The laws prohibiting that are actually themselves probably in violation of federal case law (1st Amendment based), in case you want to follow your pedantic thread to the end
Not exactly a regulated profession like engineers or architects, but if computer guys want to call themselves computer attendants you go ahead smart guy.
what is your stance on software "engineer" as a title? is it ok because of the _software_ qualifier? i feel like this guy just abbreviated his title given the domain of readers.
In my jurisdiction (indeed in my entire country) it's illegal unless they're actually recognized by the engineering licensing org.
The only people who are allowed to call themselves engineers without being recognized professional members of the engineering association are a type of plane mechanic with federal certification which supersedes provincial law that restricts who can call themselves engineer.
Where I live it would be illegal for them to call themselves engineers unless they were professional engineers as recognized by the provincial engineering certification body which was created a law passed by the provincial legislature.
The provincial engineering org does have a computer designation, so they could get licensed and have it official if they were computer engineers, but I'm not sure about software.
The points about shared tech and infrastructure hit pretty hard because it's a single monorepo deployed to homogeneous application servers. When we do bump up against issues with infrastructure we almost always end up building one-off shims. Our architects call them Microservices.
Code contribution is messy too. For any given feature, core functionality is typically owned by one team along with some of the downstream effects. The rest of the downstream effects are owned by other teams scattered across different verticals and often continents. It's rarely safe to change the core functionality of a feature by itself. Dysfunctional politics leads to projects getting delayed because of miscommunication and different priorities, and we can't risk encroaching on someone else's fiefdom. I recently burned a lot of political capital doing just that because a critical deadline was at risk.