Software Architecture, all you need to know [pdf](share.composieux.fr)
share.composieux.fr
Software Architecture, all you need to know [pdf]
https://share.composieux.fr/white-book-software-architecture.pdf
13 comments
Don't you think that centralising the responsibility of the architecture design is an antipattern?
For what I saw normally architects can't keep up with all modern techs and if they do, it still takes the ownership of the solution from each domain (FE, BE, DevOps etc).
Wouldn't it be better to have tech leads design the architecture/solution together?
I work in the public sector of Denmark, we’ve spent the past 15 years trying to get some cross-sectoral standards up and running. We’re getting there on data services as well as authentication and indexes of data, and that means we’re starting to build systems that work together everywhere.
Very few actual technologies have been dictated in this process. We have architectural standards for how data should be handled and how information flows are supposed to function, but no one dictates what technologies you use to build or deploy your system.
We do have some, like I said, like a national standard for how we authenticate users and handle their rights using something called OIOtokens. They work with standard federated services though, so you can use key-cloak if you’re into Linux or ADFS if you’re into Windows (95% of the public sector) or something else that does federated SAML authentication.
Our dataservices similarly aren’t dictated to use X, simply instructed in how information is supposed to transfer. So you can use SOAP, REST, GraphQL or whatever floats your boat, as long as the information fits the national architecture standards.
You couldn’t do any of this without centralisation. On a lower level, most suppliers adopt the national standards into their own, and then add to them within their own companies or organisations, but that works perfectly fine, because everyone knows the patterns for sharing data and information.
Very few actual technologies have been dictated in this process. We have architectural standards for how data should be handled and how information flows are supposed to function, but no one dictates what technologies you use to build or deploy your system.
We do have some, like I said, like a national standard for how we authenticate users and handle their rights using something called OIOtokens. They work with standard federated services though, so you can use key-cloak if you’re into Linux or ADFS if you’re into Windows (95% of the public sector) or something else that does federated SAML authentication.
Our dataservices similarly aren’t dictated to use X, simply instructed in how information is supposed to transfer. So you can use SOAP, REST, GraphQL or whatever floats your boat, as long as the information fits the national architecture standards.
You couldn’t do any of this without centralisation. On a lower level, most suppliers adopt the national standards into their own, and then add to them within their own companies or organisations, but that works perfectly fine, because everyone knows the patterns for sharing data and information.
I would say that a good architect, and a good development process, certainly involve collaboration between numerous stakeholders. The solution architect, tech leads, product owners, QA, etc., all have a voice and should all be talking to each other quite a lot.
That said, it's good to have somebody who owns the overall vision of the technical architecture, and can be a tie-breaking vote, or exercise veto authority over things when needed.
All in all, I believe the main job of the solution architect is to define, and defend, the "skeleton" of the solution, and then let everybody else hang their respective pieces off of that skeleton. Done right, the skeleton should be just prescriptive enough that any "component" attached to it will work smoothly with the others.
That said, it's good to have somebody who owns the overall vision of the technical architecture, and can be a tie-breaking vote, or exercise veto authority over things when needed.
All in all, I believe the main job of the solution architect is to define, and defend, the "skeleton" of the solution, and then let everybody else hang their respective pieces off of that skeleton. Done right, the skeleton should be just prescriptive enough that any "component" attached to it will work smoothly with the others.
Well said.
You're right! Having a council of tech leads is absolutely a viable approach to designing overall architecture.
With that said, it seems to me that each tech lead might individually suffer the same problem you have wisely identified - architects failing to keep up. As a result, it's perhaps possible that you might wind up with a committee of tech leads that have useful expertise in their domain but minimal knowledge outside of it.
My experience with design-by-committee is that it can be challenging to get a quality design out of one when members have broadly shared expertise, backgrounds, and interests. It's very possible that putting a bunch of people with different expertise and interests in a group and asking them to design something might get you a far superior design! It may be worth considering that it could also produce one with one with opportunity to adopt a unified vision.
My experiences to date have been that you're absolutely correct - a council of tech leads is unquestionably invaluable for their ability to supply critical technical detail to an architectural project. It just may be worth considering having an owner for the architecture itself, rather than having it be subject to the vicissitude of community ownership..
With that said, it seems to me that each tech lead might individually suffer the same problem you have wisely identified - architects failing to keep up. As a result, it's perhaps possible that you might wind up with a committee of tech leads that have useful expertise in their domain but minimal knowledge outside of it.
My experience with design-by-committee is that it can be challenging to get a quality design out of one when members have broadly shared expertise, backgrounds, and interests. It's very possible that putting a bunch of people with different expertise and interests in a group and asking them to design something might get you a far superior design! It may be worth considering that it could also produce one with one with opportunity to adopt a unified vision.
My experiences to date have been that you're absolutely correct - a council of tech leads is unquestionably invaluable for their ability to supply critical technical detail to an architectural project. It just may be worth considering having an owner for the architecture itself, rather than having it be subject to the vicissitude of community ownership..
I have seen this only when working in European companies. For some reason, these roles exist which is not bad in it self. However the majority of the architects I encountered are completely hands-off on the development part which causes lot of problems like teams that are not empowered to move fast and ridiculously complex architectures in MVP stages of products.
This is the art in being a good architect. Let the chaos reign for a while and then tighten control when necessary. Start with a skeleton and let the teams flesh it out and sometimes break a bone. But once you can benefit from architecture start to enforce your architecture.
PS: European. German to be exact. We love to plan and over engineer.
PS: European. German to be exact. We love to plan and over engineer.
Agreed - this results from the Last Responsible Moment principle: https://blog.codinghorror.com/the-last-responsible-moment/
An effective architect assesses _when_ they should constrain choices to achieve the -ilities.
For instance, in projects aimed at learning about the customer or market, you might reasonably defer many traditional architectural goals (maintainability, modifiability, perhaps even secury), while in projects aimed at creating durable long-term value in a well-understood space you probably wouldn't.
An effective architect assesses _when_ they should constrain choices to achieve the -ilities.
For instance, in projects aimed at learning about the customer or market, you might reasonably defer many traditional architectural goals (maintainability, modifiability, perhaps even secury), while in projects aimed at creating durable long-term value in a well-understood space you probably wouldn't.
> However the majority of the architects I encountered are completely hands-off on the development part which causes lot of problems like teams that are not empowered to move fast and ridiculously complex architectures in MVP stages of products
I agree with your observation but IMO there is no causality, it's a matter of competence of the architect; and the architect is (should be) in the team, not outside.
I agree with your observation but IMO there is no causality, it's a matter of competence of the architect; and the architect is (should be) in the team, not outside.
No, I do not think so. The software (but not the solution/enterprise) architect is a technology expert. For a solution architect it is less important to know all details of a technology but more about understanding the technology landscape. Software Architects are best embedded with the teams (basically your tech leads) but Solution Architects have to consider things which are beyond the understanding of the team (and then carry that into the teams).
In my own experience as an architect, it is the other way around. I can invest in new technology knowledge while we keep our dev teams at 100% workload. When they idle the company practically loose money and cannot deliver to the market (and I know that this is stupid for an individual). This usually results in a situation, that if a team comes with a tech solution, the architect team already has a good rationale about it.
In my own experience as an architect, it is the other way around. I can invest in new technology knowledge while we keep our dev teams at 100% workload. When they idle the company practically loose money and cannot deliver to the market (and I know that this is stupid for an individual). This usually results in a situation, that if a team comes with a tech solution, the architect team already has a good rationale about it.
[deleted]
This looks like someone’s sophomore college assignment. There is almost no practical advice here except defining buzzwords at a high level. Most critically the section on microservices contains only the most basic information and shows no real world experience.
I think this is an internal paper addressing other contributors, explaining the architecture roles, core techniques, etc specific to this company. This is not a 101 in architecture.
It is not a full
It is not a full
„all you to know“ is very ambitious and misguiding phrase for such a shallow presentation. It’s not even close, without ubiquitous language, SOLID, different programming paradigms etc. Distinction between software, solution and enterprise architects is questionable: there are other definitions of those roles.
I've worked for Fortune 50 sized companies, as Chief Architect, and I've worked for some amazing software engineering companies in a similar capacity.
Doing software architecture for the business side of the house, traditional IT, at any company is next to impossible. We are at the mercy of the business and the business doesn't care about standards, efficiencies. or anything, except making the quarterly estimates. The business is very supportive of all efforts right up until they decide that it might impact quarterly estimates, and then everything is out the window. When operating in such an environment there is no way software architecture, or security and compliance has a possibility of success.
On the Engineering or product side of the house especially for software product companies, software architecture is easy, and welcomed.
It all comes down to who you work for and what you are doing.
Doing software architecture for the business side of the house, traditional IT, at any company is next to impossible. We are at the mercy of the business and the business doesn't care about standards, efficiencies. or anything, except making the quarterly estimates. The business is very supportive of all efforts right up until they decide that it might impact quarterly estimates, and then everything is out the window. When operating in such an environment there is no way software architecture, or security and compliance has a possibility of success.
On the Engineering or product side of the house especially for software product companies, software architecture is easy, and welcomed.
It all comes down to who you work for and what you are doing.
What are some of the best books you'd recommend for people to go deep into the software architecture?
I don't know if it's one of the best, but I really enjoyed "Design It!" from pragprog. I liked that it's focused on pratices that can be applied to my job while giving plenty of pointers to theoretical topics to explore more in depth. I guess it's a very beginner book though.
I’ve enjoyed the depth of thought found in—and triggered by—John Ousterhout’s A Philosophy of Software Design. It packs a lot into an easy-to-read, directly to-the-point format.
There is no royal road to [architecture], software or bricks. It is a serious field of creative and intellectual inquiry that requires exploration, experimentation, and verification.
That doesn't look very thorough to me... It's just a few examples, and mostly big images. :/
It's 43 pages where the architecture discussion starts at page 25.
Looks like some kind of a joke to me.
It is a pity that so much effort has been put on writing/designing this booklet. Software Architecture is very hard to 'compress' into a booklet this size. And the concepts explained seem all mixed up. Also, I never understood the difference between Software Architect and Solution Architect, I think they are just marketing tags to specify a bit more what you can do as an architect (install/customize a turn-key solution, networking architecture, software development guidance from scratch, etc).
There is so much noise in the space of Software Architecture. And I think is something natural: building software is not architecture, nor engineering, nor mathematics... still it is all that at the same time. It also has strong social, linguistic and design components. Maybe it is just too new a discipline to define it clearly.
Personally I find these resources more convincing than the booklet or the references mentioned inside it:
For the technical/organizational (Dev teams) part
Architecture without Architects: https://www.youtube.com/watch?v=qVyt3qQ_7TA
Clean Architecture: https://www.youtube.com/watch?v=Nsjsiz2A9mg
https://www.amazon.com/Things-Architect-Knows-About-Transfor...
https://www.enterpriseintegrationpatterns.com
For the Enterprise Architect part:
https://www.amazon.com/Organizational-Culture-Leadership-Edg...
https://www.amazon.com/Chess-Enterprise-Architecture-Gerben-...
https://www.youtube.com/watch?v=ScHG63YmJ2k
There is so much noise in the space of Software Architecture. And I think is something natural: building software is not architecture, nor engineering, nor mathematics... still it is all that at the same time. It also has strong social, linguistic and design components. Maybe it is just too new a discipline to define it clearly.
Personally I find these resources more convincing than the booklet or the references mentioned inside it:
For the technical/organizational (Dev teams) part
Architecture without Architects: https://www.youtube.com/watch?v=qVyt3qQ_7TA
Clean Architecture: https://www.youtube.com/watch?v=Nsjsiz2A9mg
https://www.amazon.com/Things-Architect-Knows-About-Transfor...
https://www.enterpriseintegrationpatterns.com
For the Enterprise Architect part:
https://www.amazon.com/Organizational-Culture-Leadership-Edg...
https://www.amazon.com/Chess-Enterprise-Architecture-Gerben-...
https://www.youtube.com/watch?v=ScHG63YmJ2k
Solution architecture may incorporate non-software related concepts and processes, thus defining the role of solution architect broader than role of software architect and requiring bigger set of skills (e.g. when some process should be implemented without software via manual labor, you‘ll need certain understanding of human psychology to evaluate its efficiency). As a solution architect you solve a business problem, using software as necessary. As software architect you focus only on those business problems, which require software. That’s the difference, as it should be (but quite often it’s just one or another marketing tag, as you correctly suggest).
[deleted]
To OP. I would republish this book with better font faces. They really dont make this information very easy to comprehend.
Queues werent in there. Who needs queues tho! /s
Simplicity, especially, code splitting at build time and run time is THE software architecture you're looking for.