I don't agree with this. It appeals to our sense of egalitarianism, but in practice I haven't seen it work out well.
Ideally one or at most a few people, who are also developers, owns the architecture, so that it is consistent. They should be senior developers who still work on real features in the code base to avoid architecture astronautism.
Consistency in architecture is more important than genius in architecture in most cases. Let a thousand flowers bloom elsewhere in your life.
I say it all the time. The maximum # of chefs who should be permitted in the architecture & design kitchen on day 1 is exactly one. You always want the person with the most experience and willingness to endure pain to undertake these efforts.
Building new, coherent architecture that your team will be willing to follow for years or decades is non-trivial and not something you can learn by going to college and/or consuming a bunch of bullshit tutorials from the internet. Architecture cannot be forked or cloned. It must be applied uniquely to the problem at hand.
To continue the analogy - You simply have to have tried to make that pasta dish so many fucking times that you become god of pasta dishes. You need to have customers (and employees) complain at you for 2 decades about various aspects of your cooking for you to truly understand what works and what doesnt.
> Consistency in architecture is more important than genius in architecture in most cases
Absolutely agree. This is why suggestions like "just use 1 big database for everything" are automatically a leap in the right direction for all involved. Only when this starts to get yucky should you turn on the clever bits of your brain.
The specific code arrangement is not that important, as long as the team understands some common domain model (types, properties & relations). The most successful architecture is one that the entire team can understand and communicate about without a senior developer babysitting them.
I'd argue you should never do architecture alone, unless impossible, and it should be done with people of the same level. Of people are different levels, architecture is NOT by consensus, the most experienced will need to make the call, otherwise too much damage can be done
Two people with 15 years experience will have experienced a different 15 years. Both are usually more valuable brought together.
If you make one of those people the "God of architecture" you're not only going to piss off the other one you will probably lose the benefit of their experience. If theyre not responsible for architecture they'll pay commensurately less attention to it. Thats a waste of a salary.
The only scenario I can think of where it to promote one above all others would really be worth it would be if you otherwise cant stop the team from bickering.
As for juniors - if anything I tend to feel like theyre too deferent even when encouraged to speak up and take ownership. The only exception is when they dont realize they are making an architectural decision.
Exactly. Any Senior Developer who's actually earned that title and has the battle scars to prove it knows that there is no perfect architecture, there are simply sets of compromises. It's trade-offs and compromises all the way down. There's always somebody who looks at some little bit of the overall architecture & design and complains that it's not perfect and then use that to extrapolate that the entirety of the architecture sucks.
Don't even get me started on Conway's Law. I'm so tired of people proposing "fixes" to architecture that simply can't be supported by the existing organization. Your architecture is crap if your organization can't support it, period end.
Your architecture is also crap if it doesn't meet the expectations of the stakeholders. So architects have to manage those expectations as well. Then there's always the developer who wants to use the latest shiny and new technology so they can put it on their CV. Architects have to manage all that and then some.
Yet the agilists preach that architecture is going to simply "emerge." Ha! The only architecture I've ever seen emerge is of the same nature of what emerges from one's rear end!
At the end of the day you need one person responsible for the architecture and design of the system. You just need to make sure that person isn't a diva and seeks and listens to feedback and concerns from the development team. Good architects are worth their weight in gold.
I think it’s important that everyone feels like they own the architecture. In practice, it means that everyone puts in ideas and the person or persons in charge only (gently) nix the ideas that don’t fit with their vision. But it’s important that everyone not feel stifled by a heavy-handed architectural vision that’s dictated from on high.
In tech, there’s often many right answers and a leader’s job is to ensure the team lands on one of them, not necessarily the leader’s favorite one. You’ll end up with far more inconsistencies if you have high employee turnover. Team cohesion is often more important than getting all the technical details perfect.
> I think it’s important that everyone feels like they own the architecture.
You can keep your _feelings_ ... takes a few iterations to spot this toxic bullshit. Be explicit. Not everyone needs to get a participation star. The hired developers that were tricked into a false development process will eventually call out this bs and leave. Depending how gullible they are may take them longer.
I dont need to feel like I'm being heard. I need you to hear me if you're going to ask.
Note that the comment you're replying to talks about nixing feedback that doesn't fit with the vision (there's still a ton of ways the cat can be skinned), not about nixing all feedback, which seems to be what you're reading.
I think it's similar in development, the lead architect or vp or whatever, drives the vision of the overall architecture, architects shape those big things and drive the devs toward that direction
I read it more as "everyone (in the team) should be responsible for the architecture (of their products)". So, it's the duty of every engineer (even junior ones) to get to know more about the architecture of their products or to come up with decent architectures for future ones. Of course, some engineers know more than others (or have better taste). That's fine.
It's pretty common nowadays that only the "tech lead" or the most senior engineers discuss architectural topics that affect the whole team, but the most junior engineers are left behind.
I'm the tech lead of a sizable team, and what you describe, leaving junior engineers behind, would be a sign of failure on me.
Large software systems are complex, and there is too much detail for any one person to dive deep into everything, so in my opinion, you discuss overall architecture with the team, but critically, you explain _why_ you are proposing a certain approach, because more junior people don't have this context. Then, you ask the other folks to help you go deep into investigations on whether your architecture is compatible with the details.
If as a TL, you are not teaching and nurturing your young 'uns, you're doing a bad job.
What if your young 'uns just do not... participate?
I am in a position where I am doing TL-level decisions, and try quite hard to demo, discuss, share the details and rationale. I write design proposals, documentation, do demo sessions, etc
But the information is just not flowing, and I notice how little the juniors participate in anything. And I don't exactly know what to put my finger on. It's probably some soft-skill I'm lacking, and that I do not know how to improve
But a part of me still feels that that perhaps the young 'uns are just... too fresh. Or that the approach is just too optimistic
This is where people management comes into play. It's really difficult to identify why someone isn't participating, until you get to know their work and personality. I have regular meetings with all the engineers to discuss their work, progress, what is holding them back, expectations for career, growth, stuff like that. It's impossible to completely separate tech leadership from people leadership.
In my experience, usually, lack of participation comes from a lack of self confidence in one's understanding of software development, and usually, finding something small and delegating ownership to a junior engineer, with some oversight, gets them to participate more. You have to let go of the notion of having something done perfectly and allow them to make their own mistakes, but don't let them make huge ones. This is the most common case. There are also people who don't care (can't do much here), or aren't very good technically.
One place I worked, there was an architecture. The intent was that every programmer on the project could reproduce the same diagram of the architecture on a cocktail napkin. The reason is so that all programmers can keep the architecture in their head, to help guide their work. If they have to go look it up, they probably won't.
To make this work, the architecture needs to be somewhat simple. Architecture astronautics fail the "everyone can keep it in their head" test.
I think they stole that idea (everybody has the architecture in their head) from Extreme Programming.
I work in big tech, and that's pretty much how it works here. We don't have "architect" roles, instead every engineer owns a certain part of the system. The difference is scale and complexity: a mid level developer might design a feature or microservice, while staff developers own the architecture of entire systems. Senior/Staff engs oversee the overall system and delegate ownership of parts or subsystems to other devs. Your concerns about consistency are addressed with things like design reviews and regular updates.
This works well, so long as it's the official policy. If the official messaging is "we need to incorporate everyone's perspective", but the actual policy is "you can implement any pattern you want so long as it's our pattern", it becomes unbearable.
The utopia described isn't real in the enterprise, and my experience of 15 years working as a Software Engineer is that 90% of engineers are really good at coding, but pretty terrible at systems architecture - often taking the path of least resistance for their small domain.
It may be unpopular to prefer a top-down approach, but in my experience architecture set by an architecture team who understand how the building blocks fit together, who have a roadmap and a set of common rules and tools (not loose principles or "guidelines") have been the most successful, sane, and enjoyable projects to work on. YMMV - and there are certainly some terrible "architects" out there whatever approach you take.
Related: I am convinced that you will learn more about a Senior Engineer at interview during a Systems Design task than any coding task. This is what sets apart great engineers from good engineers.
My experience is the opposite. The more architects there are and the farther they are from the nitty gritty coding the worse everything is. Setting common rules is useless unless they're being enforced. And to be enforced you need to actually be hands on in the code base.
>Senior Engineer at interview during a Systems Design
I also pretty strongly disagree with this. The right answer to systems design in 95%+ of cases is a single application modularized using language tools talking to a single DB. Most of us don't deal with the scale that requires a constellation of systems.
> And to be enforced you need to actually be hands on in the code base.
I think this might be a difference in opinion on whether we're referring to the architecture of a codebase or architecture of a system. They're different things.
> The right answer to systems design in 95%+ of cases is a single application modularized using language tools talking to a single DB.
There are still a ton of systems design considerations to take into account with a monolithic approach. Good architecture doesn't necessarily always imply a microservices architecture, I agree, but it doesn't mean all architecture concerns can be ignored - you just have a different set of things to optimise for.
>I think this might be a difference in opinion on whether we're referring to the architecture of a codebase or architecture of a system. They're different things.
Either way you have to be hands on. I'm not sure how you can be hands on with a system without being in the code but I suppose anything is possible.
>There are still a ton of systems design considerations to take into account with a monolithic approach. Good architecture doesn't necessarily always imply a microservices architecture, I agree, but it doesn't mean all architecture concerns can be ignored - you just have a different set of things to optimise for.
Not really. You need to pick a language/framework & decide on your module boundaries. After that it's mostly building out functionality in the right module following the path your language/framework lays out.
> Not really. You need to pick a language/framework & decide on your module boundaries. After that it's mostly building out functionality in the right module following the path your language/framework lays out.
You are in fact describing a specific architectural approach, which is not optimal for all situations. OP is considering a general approach to architecture and roles.
I was actually going for the opposite - but that's my fault. What I meant was wishy-washy "guidelines" are often ignored or considered optional. Put in place tooling (rulesets) and processes that make it very difficult to architect a poor system.
>Successful architects in agile organisations no longer see their role as exclusively making architectural decisions. They see their role as ensuring good architectural decisions get made. Mostly by team members, sometimes with support from the architect and rarely by the architect themself.
This paragraph resonated well with me. Someone does need to make sure good decisions are made (and by extension, how we define "good" and "goals" for the architecture), but the team should understand the how and why, and be part of those discussions. IMHO, this elevates the team as a whole.
It was replaced by corporate gatekeepers. Now instead of having an architect you go to before you commit to a design, you simply do whatever you feel like, often without even having an idea what the end result is supposed to look like. You spend 6 months working on it and then right before you go live, you have to pass it in front of the gatekeepers, and they say, "What the fuck is this disaster? No, you can't launch, Jesus Christ." And then the cycle repeats until it's not a tire fire.
Nobody on an agile team today thinks to ask the Systems Engineers, DevOps Engineers, Architects, etc, whether their design might need changes. They have been told they alone are responsible for building the thing, so they steam right ahead. There is no adult in the room to get them to do due diligence, so it just doesn't get done. So Architects are now just a silo of red tape.
What is frustrating about architecture to me is that it’s so rare to actually find a team with the discipline to care about it in code review. It’s easy to talk about it abstractly and whatever but when someone spent two weeks and throws a PR up on Thursday night expecting it to be merged the next day and they used the wrong design pattern, didn’t structure their domain model correctly or at all, and/or lacks clear interfaces, separation of concerns, etc. there’s no time for architecture and 99/100 times the PR gets merged. You know the story.
And it’s not totally bad, albeit still frustrating. All the good architecture in the world doesn't matter if you can’t build a product that people want to use. Similar to design.
I’ve been at a place once where people held others accountable to architectural concerns in PR. The reviews took longer and honestly it was exhausting at times but also probably one of the periods I developed most as an engineer if I look back at my career.
All this leads me to the conclusion that there’s a time and place to entertain the finer details of code structure and system architecture. And it’s not when you don’t have a product. It’s only once you have a proven business that needs to be concerned with the scalability, understandability, ease of teaching others, modularization and ability to reuse, etc. that these things even start to become smelly.
!Final note that a greenfield product must still be designed and engineered and build, but that’s not architecture. Architecture adds aesthetic qualities (that are ideally practical and functional as well) to a system.
One way to solve that issue is to agree on the design pattern ahead of time before writing the code. Learning to think about the abstraction ahead of time is a powerful skill, but can be very uncomfortable to some people. There's a thing where we just allow people to say "I need to get my hands dirty, I can't effectively plan it ahead of time because I'll just end up changing my mind anyway," and nobody questions that reasoning or pushes back. The concept of "learning styles" has mostly been disproven. It's just a muscle you have to work, thinking about abstractions ahead of time without writing code. Writing helps a lot here.
Anyway, if you're able to iterate on the design pattern before writing code, it can often only take a day or two, and then you don't have to spend another sprint re-writing the whole thing or whatever. Code reviews become a lot quicker/easier now as well, because you don't have to think about other design patterns while reviewing code, just the pattern already agreed on.
> Popular agile methods like XP, Scrum or Kanban don't explicitly include an architecture practice or process.
Stands to reason. They provide thoughts about organizing people, not tech. However, they also do not explicitly state that you should throw software engineering out the window, so one can reasonably assume that engineering practices still apply.
not really. if there is no mandate from above, no time set aside, and everyone job is to keep their nose down and finish their sprint - no architecture gets done. no design discussion gets done. no testing gets done. no scheduling gets done. no vetting of dependencies gets done.
If there is "an above" then the aforementioned named wouldn't apply as they are explicitly about organizing people within a flat organizational structure. While it is true that within such an organization you may end up with people who feel they need to put their nose down and ignore software engineering principles, the Agile Manifesto is quite clear that you need the right kind of people to make it work and thus if you end up in that situation you aren't operating in line with the thoughts provided...
...which, indeed, is a likely outcome as implementation is really hard, especially in a constrained developer market where you can't just select the best of the best as you please and are often left to hire the warm bodies you can find. However, it remains that the thoughts provided encourage you to stay away from this, even if doing so in reality isn't quite so simple.
I've floated through a few agile shops...in fact I've been basically fired for insisting that we test a greenfield distributed system with a novel consistency solution
I kind of don't care what the authors of the manifesto said - no one seems to do it that way
Like I said, following through with implementation in accordance with the thoughts is really hard. Maybe even impossible. However, the conversation here is explicitly about the thoughts presented, not what happens in practice.
Agile does not take reality into account. Estimates become deadlines and turn into death marches. The watering hole is poisoned and culture dies a painful death. That is because customers and business owners footing the bill don't do Agile.
Everyone is excited during sprint#1; by sprint#10 the finger pointing and scapegoating begins
I hoped the link would whine about modern building architecture, but instead it seems to try to fix the Agile mess of lack of planning. I didn't find and concrete advice though, becouse the author seems to think "velocity" is a good metric that trumps planning.
"To stay relevant in today’s fast-moving world, architects must focus less on making the most important architectural decisions, and instead focus on building an environment where everyone makes better decisions."
Ye sure ... as powerless as a Scrum master to actually make decisions but to nagg about process I guess. No one in charge of the tech but still micromanaging managers coming for you. Architects that don't make drawings. God a distaste Agile. Why are apologists still trying.
"Diversity tickets available" means that there are discounted/free tickets available for people who couldn't otherwise afford them, and are from backgrounds that aren't well represented. At least for events I've been involved in that's more nuanced than "women etc", and could just as easily mean an open source contributor who doesn't have a corporate sponsor to buy a ticket for them, but does have an interest in the subject.
> "To stay relevant in today’s fast-moving world, architects must focus less on making the most important architectural decisions, and instead focus on building an environment where everyone makes better decisions."
In the days of cloud-hosted, microservice-based web applications, "architecture" in the infrastructural sense becomes less relevant. It's just a cloud server serving HTTP requests, having seamless access to vendor-provided elastic data stores, message queues, etc.
What remains relevant, though, is the "software architecture" – how you structure your data, what kinds of abstractions do you build over that data, is the data model suitable for the task at hand, etc.
Part of the problem there is "in the infrastructural sense".
Architecture is not about infrastructure at all. Infrastructure provides the constraints that the design must accomodate within its functional and non-functional requirements.
It's how you use that infrastructure. Is it event-sourced, CQRS, eventually consistent? How are your services structured? Around resources with state transfer and media types, or more RPC? That's the architectural choices.
in my experience, having access to the aws dashboard rarely indicates mastery of the platform and knowledge of which tool is best for the job. it is incredibly common to lift and shift on premise workloads to ec2 with an rds instance to save the cognitive load of application refactoring. this creates a different flavor of infrastructure complexity without taking full advantage of the services on offer.
Our company used SAFe. There is no provision to create actual specification. Things are planned, but there is no time allocated to it in the process. Work items somehow magically appear to be ready in the work queue for developers to work on them, with only acceptance criteria.
From the comment it's hard for me to understand exactly what you experienced, but Architecture is a very specific roll within SAFe.
One of the biggest aspects is to avoid "Big Up Front Design" or essentially over-engineering things when you probably don't have all of the information yet. This carries across multiple aspects of SAFe and usually creates conflict in people who want to be handed a complete specification.
For some people, it's a mindset change. For me, it makes sense. I don't want to be handed a complete spec written by other people. I want to be handed a best guess with requirements that I, as the person who will be implementing it, can refine, provide feedback, ask questions and help get to a better implementation.
It assumes the people closest to the problem space (you) will have the best understanding of how to solve the problem.
Architecture is one of my biggest beefs with Agile. Combination of lack of processes and documentation and faux egalitarianism is particularly deadly.
I have an experience in a relatively big corporation. Before Agile (around a decade back), it was more or less waterfall, we documented what we wanted to code as a feature, how it should work, did several rounds of review, and then we coded it to that spec.
Today, I am lucky if we have time to do the spec before coding. The most important thing is to have stories in our project management tool, which contain no real information about the specification. Customer validation is paramount but the technical soundness is mostly lacking.
I had many discussions with Agile proponents about this problem, with different suggestions, but it never changed our actual processes (or general lack of thereof).
If I had to make an analogy with house construction, it would go as this. In the old days, we did what is usually done, you have a picture of a house you want and from that, architect (or engineers) create actual blueprints, engineering documentation, which describes what is to be built. Then based on that you create estimates, timelines and manage the project. (And in real construction, they actually also create "as-built" documentation, for maintenance.)
Today, it's like no actual engineering documentation is created. So basically, product owner draws a picture of the future house, gives it to each of the workers (not to mention another problem of Agile, lack of specialization, there is no distinction between masons and welders and plumbers and electricians), and tell them, look this what you should build, go ahead and somehow do it.
What usually happens is they all start frantically working at something, and before you know it, you have ceiling on side of the house 10 cm below the other side. Or two sets of electrical wiring.
Now it's important to understand I am in no way dissing the workers (or coders), on the contrary. This happens despite (or maybe because) they are all very smart and productive and well-meaning. I certainly think that architect throwing design over the wall to be "coded" is an anti-pattern. People need to cooperate, but there needs to be process, reviews and documentation, otherwise it's gonna end up real messy. And the calls for "team responsibility" seem to be rather utopian to me.
Also, I am very much in favor of Agile as a project management method, especially Kanban (see also Steve Yegge's Good Agile, Bad Agile) - of course if you don't need deadlines.
But I don't believe, as Agile seems to claim, that you can build a two-story house (something that requires a foundation, which is famously not customer facing) by quickly iterating on a tent or a wooden shed. At some point, you need to demolish it all and build the damn foundation. The product management cannot excuse themselves, we don't know whether we end up building a bungalow or a skyscraper, just be flexible. The engineers need to know, in advance.
Which brings me to an interesting point. There is an old wisdom, that the problems you find earlier in the design cycle are easier (and less expensive) to fix. Agile claims, that it's easier (and less expensive) to write and refactor the wrong code, than to properly discuss and review architecture. I call BS on that. (The other point that Fred Brooks makes is there should be a responsible design leader, i.e. architect. This is not contradictory to egalitarianism - developers should be involved in the design of the features they will work on and they should all try to lead the design of a feature from time to time.)
To conclude, I think with Agile, SW engineering has gotten much more away from actual engineering than it used to be. I think this is fixable, but people need to accept that proper engineering documentation (AKA architectural specification) is required, and stories and acceptance criteria are no replacement for that.
models help even with agile. Check out IcePanel: "System design for your whole team, with sync with reality" ref/ https://c4model.com , https://icepanel.io
I don't agree with this. It appeals to our sense of egalitarianism, but in practice I haven't seen it work out well.
Ideally one or at most a few people, who are also developers, owns the architecture, so that it is consistent. They should be senior developers who still work on real features in the code base to avoid architecture astronautism.
Consistency in architecture is more important than genius in architecture in most cases. Let a thousand flowers bloom elsewhere in your life.