A book on which knowledge and advice from software architects around the world were compiled "97 things that software architect should know" is available on the web for free

ByTec_estromberg

Within software development projects, both software and software architects are required to have knowledge of both business and programming, and they need to steer the project to success and at the same time to meet the needs of stakeholders. A book that summarizes what software architects should know about "97 Things Software Architects Should KnowAt the same time, knowledge gained by software architects from around the world and advice sent to peers are summarized, but this is also available on the web for free.

97 Things Software Architects Should Know
http://ソフトウェアアーキテクトが知るべき97のこと.com/


There are 108 essays posted in total, of which there are 97 "Things to Know" by overseas software architects and eleven items by Japanese architects among them.

97 Things to Know About Foreign Architects

1:Do not give priority to resume's appearance over system requirements / Nitin · Bowankan
2:Essential complexity is simple, eliminate incidental complexity / Neil Ford
3:The biggest problem is probably not technological / Mark Lamb
Four:First, communication, clarity and leadership for that, Mark Richards
Five:Deciding performance is architecture / Randy Stafford
6:Explore the true meaning of the required specification / Ainer Randall
7:Get up! / Woody Durhan
8:All things always get an error / Michael Niggard
9:Noticing that it is a negotiation / Michael Niggard
Ten:Seek quantification / Keith Bray West
11:One line of code from the specification line of 500 lines / Allison Randall
12:Do not ask for a free size solution / Randy Stafford
13:It is never too early to consider performance / Rebecca Parsons
14:Balancing with the architecture / Randy Stafford
15:To prevent criminal commit end runs / Niclas Nilsson
16:A practical way to not narrow down the choices to one / Keith Bray West
17:Give the initiative to the business side / Dave Muirhead
18:More general than simplicity, first thing to use than reuse / Kevin Henney
19:Architect must defile hands / John Davies
20:Continue to perform integration / David Bartlett
twenty one:To avoid failure due to schedule / Norman · carnoard
twenty two:Tradeoff is inevitable in architecture / Mark · Richards
twenty three:Database as a fortress / Dan Chuck
twenty four:Hone the feeling that uncertainty will hide / Kevin Henney
twenty five:The problem on the mirror is larger than it seems / Dave · Quick
26:Recycling is not only about architecture but people's and education problems / Jeremy Meyer
27:No architecture I (ego) / Dave Quick
28:Eye from the ground 300 m / Erik Donnenberg
29:Try before you choose / Eric Dornenburg
30:Understand the business domain / Mark · Richards
31:Programming is not a manufacture but a design / Ainer Randall
32:Give self-discretion to developers / Philippe Nelson
33:Time changes everything / Philippe Nelson
34:A in "Software Architect" is lowercase only. Please be satisfied. / Barry Hawkins
35:Large scope enemies / Dave · Quick
36:Be a butler instead of an actor / Barry Hawkins
37:Consider that software architecture has a logical meaning / Michael Niggard
38:The skyscraper is not scalable / Michael Niggard
39:The future is with heterogeneous / Edward Gerson
40:Performance is important first / Craig Russell
41:Please note the blank space in the diagram / Michael Niggard
42:Familiarize yourself with design patterns / Mark · Richards
43:The situation is more important than anything / Edward Gerson
44:Four people of Dwarf, Elf, Wizard, King, Evan Kovsky
45:Let's learn from the building architect (architect) / Keith Bray West
46:Fight repeatedly / Niklaas Nilsson
47:Welcome to the real world / Gregor Hope
48:Do not rule, observe / Gregor Hope
49:Architect has two faces / David Bartlett
50:Architect focused on boundaries and interfaces / Ainer Rundle
51:Power to developers / Timothy · Hi
52:Write down the reason / Timothy · Hi
53:Implicit assumptions, especially suspicious oneself / Timothy High
54:Let's share your knowledge and experience / Paul · W · Homer
55:Pattern pathology / Chad · La Vigne
56:Notice the excessive use of parables / David Ing
57:Focus on maintaining applications / Musadisi Casuar
58:Decide your mind to choose only three to two / Bill Deola
59:According to principle principle, not hobby or personal opinion / Michael Harmer
60:Let's start with moving skeleton / Clint Shank
61:All the data / Paul · W · Homer
62:Simple things simply / / Chad Lavigne
63:Architect is the developer first and foremost / Mike Brown
64:Be aware of ROI variables / George Malamidis
65:Design on the assumption that there is a legacy system in front of you / Dave Anderson
66:If there is only one solution, seek for a second opinion / Timothy High
67:Understand the impact of change / Doug Crawford
68:Hardware understanding also required / Camel · Wick Ramanakake
69:The shortcut for now, big loss later / Scott McPhee
70:"Perfection" is a "sufficiently good" enemy / Greg Nyberg
71:Avoid 'good ideas' / Greg Nyberg
72:Excellent content makes excellent system / Zubin · Wadia
73:Do not confront business as angry architect / Chad La Vigne
74:Try durability of key indicators and see where they will break / Stephan Jones
75:If you design you need to be able to code / Mike · Brown
76:If you call a rose with another name, it will only be cabbage / Sam Gardiner
77:A solid problem is given a high quality solution / Sam Gardiner
78:Diligence is necessary / Brian Heart
79:Responsibilities for my own judgment / Lee Joo Woo
80:Become clever / Eben Hewitt
81:Choose weapons carefully, do not let go of it / Chad La Vigne
82:A real customer is not a customer in front of us / Eben Hewitt
83:It is not as designed as / Peter Girardmos
84:Choose a framework for compatibility / Eric Hawthorne
85:Make a powerful business case / Lee Joo Woo
86:Control data as well as code / Chad Lavigne
87:Repay your technical debts / Birkhart / Hafunegel
88:Do not try to solve the problem / Eben Hewitt
89:Make the system tool-friendly / Keith Bray West
90:Look for developers who are passionate about problem solving Do not let go / Chad La Vigne
91:Software actually does not exist / Chad La Vigne
92:Learn a new language / Birkhart / Hafnagel
93:There is no safe solution for the future / Richard Monson Höfel
94:User's denial feeling problem / Norman · Kannober
95:Importance of Consommé / Eben Hewitt
96:From the viewpoint of the end user interface is the system / vinayak · hedge
97:Excellent software is not built, but grows / Bill de Ola

Eleven things to know about by Japanese architect

1:Architecture has vertical and horizontal basic structure / Masayoshi Hagiwara
2:Aim for business architect / Junzo Hagimoto
3:Focus on the problem / Akira Sakakibara
Four:Do not be trapped by the problem / Akira Sakakibara
Five:Making cumbersome things non-attributable and enhancing creativity / Masayoshi Hagiwara
6:Mechanical technology and intrinsic technology not obsolete / Naoya Ito
7:Design development style / Kazutoshi Ono
8:Design communication, not system Yusuke Suzuki
9:Capturing casual users / Yuki Makino
Ten:Passive architect and active architect / Kentaro Esjima
11:Fulfill accountability / Junzo Hagimoto

For example, "81: Weapons should be carefully chosen, do not let go of it", architects who remain in software development places for a long time have multiple weapons (knowledge and know-how on specific codes, etc.) Advice is raised that even if a new technology has appeared, there is no need to easily let go of the weapons you already have. Since introducing new technologies first may pull the feet into a negative factor, pay attention to "business" "cost" "future" of technology, paying attention so as not to be late for the trend and introducing new technology It should be decided about.

ByPedro Vezini

In items that seem to be unrelated to software architect "Importance of consommé", it is better to think that consommé, which is perfectly clear and good, is the job of software architect, refine thought until we grab the requirement of each system, filter idea We are preaching the need to do. The architect seems to make it possible to prove the relationship within the architecture to be correct by breaking through the idea such as "What is this? What kind of characteristics is it? What kind of relationship is there?" Many of the bugs and requirements that I forgot to implement are said to be warm, meaning vague words.

Repeating the same thing as customers, developers, analysts and users getting bored and sleepy is the same as repeating the filtration over and over again until the liquid becomes transparent in making a good consommé That is why it will make the architecture more sophisticated.

ByThomas Hawk

In the item "Reimbursement for technical debts", the importance of not deferring system changes such as correction of bugs and addition of new functions in software development projects is discussed. Generally, when developers and testers make system changes, I hope to work on it after securing enough time to correctly design, implement and test the changes. Of course there are trade-offs in judgment, and quick-and-dirty techniques are suitable in some cases, but if you do so in a way that makes it impossible to do so, the project will be called "technical debt" We are forced to respond to them necessarily.

With money borrowing, there is an invisible cost of "interest". To the contrary, the debt of technology is equivalent to "the system becomes unstable" and "extra maintenance cost" for change. Also, with technology debt, you need to repay the principal, that is, change the system itself, just as you do to pay off the debt of money.

If you understand technical debt, you may think that "compensation is so expensive that we can not afford to pay such a cost very much!", But it is better for developers to make changes as quickly as possible and make quick changes . In that case, it is recommended that after the fix is ​​applied to the production, it will return to the state before the change, ask the developer to correct it in the correct direction, and incorporate the modification into the next periodic release. "It is the same as paying interest at the end of the month, even if you buy something with credit card and make debt."

By401 (K) 2012

Although O'Reilly Japan does not publish the "97 things that software architect should know about" on the web, the content itself isCreative Commons 3.0It is freely available as it is.