
Software Architecture, all you need to know [pdf] - eko
https://share.composieux.fr/white-book-software-architecture.pdf
======
bl4ckm0r3
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?

~~~
option_greek
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.

~~~
oaiey
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.

~~~
jungturk
Agreed - this results from the Last Responsible Moment principle:
[https://blog.codinghorror.com/the-last-responsible-
moment/](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.

------
remote_phone
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.

~~~
oaiey
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

------
ivan_gammel
„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.

------
foolsgold
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.

------
Simpliplant
What are some of the best books you'd recommend for people to go deep into the
software architecture?

~~~
rhizome31
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.

------
Double_a_92
That doesn't look very thorough to me... It's just a few examples, and mostly
big images. :/

------
skipthemeat
It's 43 pages where the architecture discussion starts at page 25.

------
isharamet
Looks like some kind of a joke to me.

------
fredrklem
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](https://www.youtube.com/watch?v=qVyt3qQ_7TA)

Clean Architecture:
[https://www.youtube.com/watch?v=Nsjsiz2A9mg](https://www.youtube.com/watch?v=Nsjsiz2A9mg)

[https://www.amazon.com/Things-Architect-Knows-About-
Transfor...](https://www.amazon.com/Things-Architect-Knows-About-
Transformation/dp/1537082981/ref=sr_1_1?s=books&ie=UTF8&qid=1545832595&sr=1-1&keywords=37+things+architect+knows)

[https://www.enterpriseintegrationpatterns.com](https://www.enterpriseintegrationpatterns.com)

For the Enterprise Architect part:

[https://www.amazon.com/Organizational-Culture-Leadership-
Edg...](https://www.amazon.com/Organizational-Culture-Leadership-Edgar-Schein-
dp-0470190604/dp/0470190604/ref=mt_paperback?_encoding=UTF8&me=&qid=)

[https://www.amazon.com/Chess-Enterprise-Architecture-
Gerben-...](https://www.amazon.com/Chess-Enterprise-Architecture-Gerben-
Wierda/dp/9081984055/ref=sr_1_1?s=books&ie=UTF8&qid=1545832621&sr=1-1&keywords=chess+architecture)

[https://www.youtube.com/watch?v=ScHG63YmJ2k](https://www.youtube.com/watch?v=ScHG63YmJ2k)

~~~
ivan_gammel
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).

------
jsaundersdev
To OP. I would republish this book with better font faces. They really dont
make this information very easy to comprehend.

------
nickthemagicman
Queues werent in there. Who needs queues tho! /s

------
revskill
Simplicity, especially, code splitting at build time and run time is THE
software architecture you're looking for.

