15 ms·
Behaviours to avoid in a software architecture role
- bob1029 6y ago#2 is probably the most important. How you model the domain is the most foundational part of any software system. If everyone on your team looks at your domain model and thinks "yep that makes total sense", then it is very likely the rest of the project can be made to go smoothly. If the meaning of a Customer or User in your system is ambiguous, or has certain nuances privy only to the architecture team... this is where you run into massive problems on more complex systems. Taking this a little bit further, having a clean model of the problem domain also makes other downstream aspects easier. Business analysts can start expecting certain types to have certain properties and you can leverage things like SQL to dramatically speed up projection of business facts without involving developers.
- arethuza 6y agoI once spent a long time trying to work through all of the complexities just for what "Customer" meant in one fairly large organisation. Pretty much all followed from one chap asking "if a customer consolidates it finance team from being at each of their 40 sites in one country to 1 shared service centre, do we lose 39 customers"?
- bob1029 6y agoIdentifying bounded contexts is a critical part of organizing extremely complex systems. You might have a Customer model that supports all contexts of usage, but in a certain bounded context you could know that only certain things from that type are applicable. There are a lot of ways to model this explicitly, but sometimes just having a clear document that expresses what these contexts are and what is involved in each is sufficient. This also alludes to the benefits around separating your functions from your data. If your domain model is just data and the functions live elsewhere (i.e. within a separate abstraction representing each bounded context), then you have tremendous amounts of flexibility with how the system is composed on top of the model.
- deleted 6y ago[deleted]
- steve_adams_86 6y agoI agree. This is the classic “you don’t understand it if you can’t explain it” problem. If you don’t have the domain nailed down in plain speak, there are risks to productivity - especially if an entire team is involved. Business logic becomes open to interpretation at implementation time. That means a different solution for any developer who happens to implement it, and each one potentially incorrect and unable to interface with correct code in its own way. I’ve set myself up for failure this way, essentially by assuming things would just fit into place as more of the project became clear. That’s a really bad way to work, haha. But you learn as you go.
- TameAntelope 6y agoIt's why "naming things" is one of the hardest problems in CS! It's hard to work with someone who doesn't get that.
- craftinator 6y agoI consistently have to argue with my brother about this, who started developing in the 90s and has a perfect memory for mapping terms to abstract objects. He argues that at some level, every construct is just assembly that shuffles bits around, so nomenclature doesn't matter (he also grew up with Perl as a first language...). My argument is that it makes his code unreadable without a graph unraveler.
- bjornsing 6y agoYou only need one maxim for software architecture work: “Implementation ruins architecture!” :P
- hertzrat 6y agoMaybe what you mean is “everyone has a plan until they get punched in the face” ? All good architecture starts with that idea in mind, so you optimize for making things as decoupled and changeable as possible.
- hellohello1 6y agoHey that's my portfolio! 100 products written by 100 people in 100 different ways. 100 people left and I'm the one left trying to unfuck 100 products.
- abiogenesis 6y agoI don't think there was an architecture to speak of in the first place in your case.
- willvarfar 6y agoAnd nothing about business needs and wants, working with stakeholders and all the rest? I’ve seen both newly minted and seasoned “architects” fail again and again because they think in terms of technology not business.
- theptip 6y agoThe article explicitly covers that one: > 2. Don’t ignore the domain It’s part of the role to become a domain expert. This knowledge can be used to act as an effective translator between business and engineering.
- willvarfar 6y ago-shrugs- I don’t get that from that paragraph, but I guess it depends on how one thinks the author means “domain”. I’m used to meeting “domain experts” who know all about the corner cases in the current implementation. Often they are the people who argue with the suits and it never ends well for them.
- mateo411 6y agoThat doesn't sound like a domain expert. This sounds like somebody who is pretty familiar with the current implementation. A domain expert understands the business use case and the market. I would say they can act as a good Product Manager.
- theptip 6y agoIt's specific jargon in the Domain Driven Design community; "domain" == "business domain". Some of the links in that section of the OP give more detail. I recommend DDD in particular, it's a great architectural framework, though it's a bit dense and hard to approach. A good starting point: https://martinfowler.com/bliki/DomainDrivenDesign.html https://martinfowler.com/bliki/DomainDrivenDesign.html
- cek 6y ago21 years at Microsoft led me to have great disdain for "Software Architects". 5 years at Amazon led me to fall in love with the concept of a community of Principal Engineers. The Amazon Principle Engineering tenets are amazeballs. Exemplary Practitioner - Principal Engineers are hands-on and lead by example. We deliver artifacts that set the standard for engineering excellence, from designs to algorithms to implementations. Only by being close to the details can we earn the respect needed to be effective technical leaders. Technically Fearless - Our company's startup culture does not admit the luxury of conservatism. Principal Engineers tackle intrinsically hard problems, venturing beyond comfortable approaches when necessary. We acquire expertise as needed, pioneer new spaces, and inspire others as to what’s possible. Balanced and Pragmatic - Principal Engineers are pragmatic problem solvers. We apply judgment and experience to balance trade-offs between competing interests. We simplify processes and technologies while advocating a long-term view. Illuminate and Clarify - Principal Engineers bring clarity to complexity and demonstrate smart ways to simplify. We frame each problem in its customer and business context and boil it down to its essence. We probe assumptions, illuminate pitfalls, and foster shared understanding. We accelerate progress by driving crisp and timely decisions. Flexible in Approach - Principal Engineers adapt our approach to meet the needs of the team, project, and product. We solicit differing views and are willing to change our minds as we learn more. We recognize there are often many viable solutions, and that sometimes the best solution is to solve a different problem, or to not solve the problem at all. Respect What Came Before - Principal Engineers are grateful to our predecessors. We appreciate the value of working systems and the lessons they embody. We understand that many problems are not essentially new. Learn, Educate, and Advocate - Principal Engineers are constantly learning. We seek technical knowledge and educate the entire organization about trends, technologies, and approaches. We combine vision and discretion to drive fruitful and even game-changing technology choices. Have Resounding Impact - “Deliver Results” is a low bar for a Principal Engineer. Without seeking the spotlight, Principal Engineers make a lasting impact that echoes through the technology, the product, and the company. We amplify our impact by aligning teams toward coherent architectural strategies.
- Geminidog 6y agoI share your disdain for "Software Architects." I'm curious on your reasoning though. Can you expand on why you hold disdain for "Software Architects"?
- offtop5 6y agoI'll add another one, don't openly confront the CTO. Basic things what you should learn at your first job somehow get lost upon experienced software engineers.
- NDizzle 6y agoEven when they have indefensible positions? When the idea doesn't hold up to ~2 hours of research?
- TameAntelope 6y agoEspecially then, because if that's the case then you know there's more to this story than just what you're experiencing in that moment.
- vmh1928 6y ago2+2 = 5 situations.
- TameAntelope 6y agoIn my experience it's rarely (read: never) that clear, is my point. When it's that "obviously" wrong, there's almost certainly something you don't understand.
- pc86 6y agoExactly. If you're arguing with your boss's boss's boss, who has worked at the company for five years and the industry for two decades, and you think you've unraveled their entire argument by reading a few blog posts, you're wrong approaching 100% of the time. Best case scenario is that you've missed something specific to your company, or industry, or the current technical implementation, or some obscure contract the previous CTO signed that they're still trying to get out of.
- bluefirebrand 6y ago
- sjg007 6y agoPeople downplay software architects but I've found it's a critical role. You have to interface between business and stakeholder requirements, modeling the domain effectively, engineering management, product processes and then reality. A lot of business logic ends up encoded in the software so you really want to isolate it as much as possible so that when change is needed you know where to look. That and you have to create a lot of documentation and train new developers and stakeholders. So it's really a job where you spend 95% of your time contextualizing, writing and communicating to others. It's a bit like doing continuous self reflection of a project. It's kind of a thankless job, do your job well and it's like flowing water and nobody notices you. Do it badly and things dam up quickly.
- Geminidog 6y ago> You have to interface between business and stakeholder requirements, modeling the domain effectively, engineering management, product processes and then reality This is the Technical product managers job. The architects role is suppose to be an extreme high level view of purely the technical side of the business. From my own anecdotal experience "architects" who try to fulfill the role to the definition end up being mostly useless.
- pc86 6y agoI'm biased, as an architect, but you can't be a good software architect if you don't know the domain very well - both the industry as a whole, and your company specifically.
- nitrogen 6y agoI've had my worst experiences in teams where the Product and Engineering were completely siloed. Things go a lot more smoothly if there's a bit of overlap. Also, many orgs don't have a TPM role, so that falls on Staff/Principal engineers and engineering managers. In fact, roles should be fluid and slightly overlapping, as every team and every org will have different needs.
- rmah 6y agoBack when I was starting out, what your describing was called an "systems analyst".
- christiansakai 6y agoIs software architecture role the end game for SWEs?
- joncrane 6y agoI think FIRE is the end game for SWEs.
- christiansakai 6y agowith the housing cost I think it is impossible to do FIRE even with SWE salary.
- sharadov 6y agoYou can, just don't FIRE in a western country.
- hinkley 6y agoI would say that something you need to know about yourself by the time you reach your FIRE goals is what you want to do with the extra 10 hours a day once it's not working for a boss. Even if that means adding a couple years onto your plan. Because if you know the answer to that question, many of those answers don't require a tier 1 market. And since you're doing it late in life, it might occur to you that if you move to the mecca of beer making or kayak building, you'll be competing with people who are way, way more experienced than you are. Maybe you want to live in a 'rising star' city of a 200-600 thousand people, where your relationship with the community can be more reciprocal, but you can still find a decent turkish coffee and bulgogi tacos. That place is going to be tons cheaper than where you are now.
- hinkley 6y agoThis is not a rhetorical question: Do you still want to live close to SV when you're not working there anymore? Your burn-down rate for your retirement fund is predicated pretty substantially by the standard of living you maintain after you retire. If a lot of your day to day activities become indefensible once you can't justify it based on work concerns, then your costs may be lower. Look, for instance, at all the fancy cars that real estate agents have to drive to exude competence. They end up leasing a high end car, when maybe all they want is a 2013 Subaru Outback for activities and half a closet of clothes from Duluth and Patagonia that last forever. Once you pull on that thread, then moving to an exurb might make sense too.
- lovehavetodo 6y agoSoftware architects is a critical role. Need someone with higher level knowledge of the system to make sure every decision makes sense.
- hinkley 6y agoSoftware architecture is a critical responsibility. There is more than one way to get that taken care of, and it tends to work better when the people who are responsible still have their hands in the code. I've seen too many pure architects spout off about how the system works and not notice the meaningful glances among everyone else at the table. That's how you wanted it to work. We couldn't make that work (possibly because Information Theory or physics) so we did something else.
- zug_zug 6y ago>> 4. Don’t just seek architectural consistency I don't know what the author has in mind, but I plainly disagree when stated as a general rule like this. Examples: Try to get every server on the same OS by default, same packages, standardized networks, health check at the same path, prefer the same port, deployed with standard jenkins jobs, use a standard versioning scheme, use the standard branching model, standardize logging, standardize error-handling, standardize datastores, use standard login/security.
- nelsondev 6y agoThat’s “Dev Ops” consistency, not architectural consistency. Insisting on architectural consistency might mean every service needs to use a relational database, and have an exposed API. But a pub/sub or map reduce, may not fit neatly into that architectural model.
- chromanoid 6y agoGreat talk by Stefan Tilkov on the topic: https://youtu.be/AkYDsiRVqno?t=273 https://youtu.be/AkYDsiRVqno?t=273 - Why software architects fail – and what to do about it
- zmmmmm 6y agoAs with other commenters, I feel like Software Architecture is a bit of an anti-pattern. Software just isn't like buildings in the end. The analogues of space and physics of materials etc are not solid enough in the software world that you can have someone disconnected from the "builders" lay out the whole building and then hand over the designs to be "built". As with agile approaches etc., there is a need for a far more incremental and iterative approach needed for most software projects and even if in practice that is how the architect role works, it is unhelpful to have it named in a way that implies a "waterfall" type process that you would see in building design. I think most of the advice in the article is actually reflecting this sentiment and in my organisation I am deliberately not creating roles that bear "architect" in the title. The software industry should move on from this term, I think.
- yjftsjthsd-h 6y ago> that you can have someone disconnected from the "builders" lay out the whole building and then hand over the designs to be "built" Agreed that this isn't going to work. I wouldn't write off the whole notion of having architecture and architects, though; I've known a handful of architects who absolutely improved the systems they worked on, but they were deeply involved in the whole process and part of their job was precisely to alter the system as needed.
- GoblinSlayer 6y agoRight, you just throw together angular, babel, webpack, bootstrap, typescript, spinners, redis, zeromq, recaptcha and nosql - and that's your blog's "architecture".
- rswail 6y agoI'm an old fart that is a programmer that now has a fancy "architect" title. I think I can distill that 30 years into the following: 1. Nouns are more important then Verbs. (that's what DDD is about) 2. Everything is events (if your Nouns aren't doing anything, there's nothing to be done. When they do something, that's an event). 3. A Noun's state is the sum of all the events that occurred and the way the Noun responded to them. All the rest, microservices, network partitions, RDBMS vs NoSQL, containers, etc etc is irrelevant to the business. If you don't get those 3 points right, then you don't deliver the business value and you've failed. Architects are about translating the business into those Nouns and Verbs and explaining them back to the business and to the developers that are building the automated bit of that business.
- blub 6y agoI've been in software architect roles on and off during my career (currently I'm on) and I feel like I've read similar discussions to the ones in the comments many times over the years. But no matter how you cut it, you can't escape software architecture when doing software development. One may call the architects principal engineers, gremlins or senior developers, the role may be covered by one person or multiple and the end result may be better or worse, documented or undocumented - in the end someone worked on the software architecture. Depending on the organization and its needs, the role may be strongly focused on technical aspects or straddling engineering and product management. A company with very specialized roles will want architects to take care of the architecture, whereas one with more flexibility might require that they also work on requirements, talk to customers, mentor developers, manage a product, etc. Some of these combinations are less than ideal. Every time I did application architecture I was also writing code, but that's not easy and may be an anti-pattern. Typically architecture tasks (especially the documentation) are neglected under time pressure and the people revert to doing what they know best, which is coding. Application architects should be very familiar with their application domain, applicable algorithms, idoms and patterns, etc because they're essentially part of the development team. Now I'm closer to the "architect that doesn't code" stereotype, doing systems architecture. And indeed, I do not write any code besides small applications I use to validate my assumptions or evaluate and analyze solutions. I don't remember writing one line of production code in the past years and this is neither unusual nor problematic. I work with several development teams, ensuring that their components stay technically coherent and fulfill the requirements of the system. I start by translating business requirements into technical requirements and then work together with each team observing their progress, iterating over our solutions until we are feature complete. Specifically this involves intra-component interface design, software design (in my case - how components behave and interact with each-other and the platform), architecture documentation, application architecture review, code review, etc. And meetings, tons and tons of meetings with development teams, POs, project managers, testers, lead architects, etc. I do find that working close to the metal grounds you as an architect. Whenever I do too much diagramming and abstract concept design I feel like I'm losing something important and this is where testing your concepts comes in. But there's no general rule about what developers expect from architects. I've had teams in the same projects expect a finished concept while others were happy to implement something by themselves with minimal to no input from me as long as the external preconditions were being met.