Practical Principles of IT Architecture

Maxims from my experience

This is not to define architecture. There are many definitions, some more useful than others. This is not to lay down a formal method for practising architecture. There are several.

Instead, it is to express how architects may live, breathe and feel architecture beyond the dry steps of any method or framework. It is about the immersive experience and the sheer pleasure of architectural thinking. If done well, architecture can lead to systems of beauty that delight all its patrons.

It is to bring to consciousness what I've learned gradually and subliminally over 20 years. Those who have worked long in this field may intuitively get it. For others, it may seem simplistic or like gibberish. It will be satisfying evidence of its soundness if you find it helpful. I share it with equal hope of learning and teaching.

The form is brief haiku or koan-like phrases left unelaborated to stick in the mind better. There is no sequence. There are no categories. There are overlaps. There are contradictions. It's a mixed bag. It'll grow and change.

Here goes.

1. Draw it, always.
2. In the end, it should have elegance and simplicity to it. It should look 'right'.
3. Try to minimise the cost, and it will lead to better architecture.
4. Become the customer as you think.
5. Know there is no ideal architecture.
6. Assume that you know very little.
7. Assume that you are never right.
8. Begin with these architectural principles for all problems — cohesion & loose coupling. They solve most problems.
9. Apply the architectural principle of reuse after cohesion and loose coupling.
10. Think for business domains.
11. Look for patterns, both good and bad.
12. Be unselfish.
13. Read a lot.
14. Read every day.
15. Read widely.
16. Observe the language as you read.
17. Think. You're mistaken; think again. You're still mistaken; think again. Now you may be getting somewhere.
18. Apply non-architectural constraints only at the end.
19. Allow inelegant failure of generally successful non-critical transactions.
20. Pre-validate critical transactions to prevent failures elegantly.
21. Manage exceptions, don't let exceptions manage your architecture.
22. Think in symmetries.
23. Take yourself less seriously.
24. Document it.
25. Explain like the other person does not know all you know.
26. Explain like the other person is intelligent.
27. Improve your vocabulary.
28. Improve your grammar.
29. Be excellent in the language you use.
30. Improve your language skills every day.
31. Discuss ideas and concepts with your peers.
32. Listen. Really.
33. Prepare your reply after you have listened, or else you aren't listening.
34. Make the solution as independent of the technology as possible.
35. Know that your drawing can be clearer. Every drawing. Every iteration.
36. Follow conventions for drawing.
37. Follow conventions for writing.
38. Follow conventions for speaking.
39. Be meticulous.
40. Be complete.
41. Be consistent.
42. Stick to your role.
43. Apply an objective method to decide if the data used should be a copy.
44. Apply objective criteria to choose between integrating systems directly or via queues, brokers, and gateways.
45. Middlemen are expensive. Connect directly. Suppliers and consumers can speak one language and take care of themselves.
46. Let systems signal each other for short sequences like a pop band.
47. Use an orchestrator for long, complex sequences like a symphony orchestra.
48. Give credit.
49. Learn from others.
50. It always pays to begin by identifying the options.
51. Rationally explain your decision.
52. Decide from wisdom.
53. Listen to your gut.
54. If it is right, do the difficult thing.
55. Stick with it.
56. Spend 80% of your work time performing your core role.
57. Spend 10% of your work time on self-development.
58. Spend 10% of your work time performing non-core roles.
59. Work no more than 9 hours a day.
60. Keep your evenings and weekends for yourself and your family.
61. Be physically fit.
62. Do high-quality work and be proud of it.
63. Think about operations.
64. Think about maintenance.
65. Know and articulate well the technical terminology of your profession.
66. Know what architecture is.
67. Understand the disciplines of your profession.
68. Always have an end-state vision.
69. Be ready to achieve the end state step-wise.
70. Start with the actors. IT is for someone.
71. For anything, think layers, hierarchies and sets.
72. Do not mix types at any level in thought, pictorial models, and lists.
73. Encourage quality in your colleagues.
74. Be nice.
75. Respect the work, not the title.
76. Deliver artefacts.
77. E-mails, phone calls and meetings are seldom real work.
78. Do more, manage less.
79. PPTs and e-mails are not genuine artefacts.
80. There has to be an underlying business case.
81. Given enough money and time, almost anything is possible.
82. Always think top-down.
83. Get certified. It teaches you the language and thinking of your profession.
84. Explain to non-architects without jargon.
85. You are not an architect if you can't draw — adequately, competently, and excellently.
86. A drawing speaks to an audience with a subject. It must speak cleanly and clearly, using shapes, lines, text, layout, sizes, colours, and legends.
87. Abandon the software tool if it takes more time to use it than the architectural thinking itself.
88. Remember that great architecture has often been produced without advanced technology but with advanced thought.

That's it for now.

Shashi Sastry quality-thinking.com

Please consider Medium membership to clap, comment, highlight, and get full access to my stories and those of other excellent writers. (It's only $5 a month. Give it a go!)

Become a member