Behaviours to avoid in a software architecture role
danielwatts.info
Behaviours to avoid in a software architecture role
1–10 of 174 posts
Re: Behaviours to avoid in a software architecture role
#2#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.
Re: Behaviours to avoid in a software architecture role
#3You only need one maxim for software architecture work: “Implementation ruins architecture!” :P
Re: Behaviours to avoid in a software architecture role
#4#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 wh…
I 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"?
Re: Behaviours to avoid in a software architecture role
#5And 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.
Re: Behaviours to avoid in a software architecture role
#6And 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.
The 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.
Re: Behaviours to avoid in a software architecture role
#721 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.
Re: Behaviours to avoid in a software architecture role
#821 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 implement…
I share your disdain for "Software Architects." I'm curious on your reasoning though. Can you expand on why you hold disdain for "Software Architects"?
Re: Behaviours to avoid in a software architecture role
#9I'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.
Re: Behaviours to avoid in a software architecture role
#10I'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.
Even when they have indefensible positions? When the idea doesn't hold up to ~2 hours of research?