Practical Principles of IT Architecture

Maxims from my experience.

Free image from

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

It is an attempt to express how architects might be living, breathing and feeling 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 stakeholders. It is to make conscious what I have learnt gradually and subliminally over 20 years. Those who have worked for long in this field may intuitively get it. For others it could seem obviously simplistic or like gibberish. If it is found useful by others it would be satisfying evidence of its validity. It is shared with humility, more with a hope of learning from the discussion than to teach.

It is in the form of brief, haiku or koan-like phrases, left unelaborated to better stick in the mind.

Here goes.

There is no sequence.There are no categories.There are overlaps.There are contradictions.It’s a mixed bag.It will grow and change.

  1. Draw it, always
  2. In the end it should have an elegance and simplicity to it. It should look ‘right’.
  3. Try to minimize the cost, it will lead to better architecture
  4. Become the customer as you think
  5. Know that 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 those of cohesion and loose coupling
  10. Think in terms of 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 are wrong, think again. You are still wrong, think again. Now you may be getting somewhere.
  18. Non-architectural constraints should be applied only at the very end
  19. Allow inelegant failure of mostly successful non-critical transactions
  20. Pre-validate for critical transactions to handle failures elegantly
  21. Think in symmetries
  22. Take yourself less seriously
  23. Document it
  24. Explain like the other person does not know all that you know about it
  25. Explain like the other person is intelligent
  26. Improve your vocabulary
  27. Improve your grammar
  28. Be excellent in the language you use
  29. Improve your language every day
  30. Discuss ideas and concepts with your peers
  31. Listen. Really.
  32. Prepare your reply only after you have listened, else you are not listening
  33. Make the solution as independent of the technology as possible
  34. Know your drawing can be clearer. Every drawing. Every iteration.
  35. Follow conventions for drawing
  36. Follow conventions for writing
  37. Follow conventions for speaking
  38. Be meticulous
  39. Be complete
  40. Be consistent
  41. Stick to your role
  42. Apply an objective method to decide if the data should be remote or local
  43. Apply objective criteria to decide between integrating components directly or via Enterprise Application Integration
  44. Give credit
  45. Learn from others
  46. It always pays to identify and begin with the options
  47. Rationally explain your decision
  48. Decide from wisdom
  49. Listen to your gut
  50. If it is right, do the difficult thing
  51. Stick with it
  52. Spend 80% of your work time performing your core role
  53. Spend 10% of your work time on self-development
  54. Spend 10% of your work time performing non-core roles
  55. Work no more than 9 hours a day
  56. Keep your evenings and weekends for yourself and your family
  57. Be physically fit
  58. Do high quality work and be proud of it
  59. Think about operations
  60. Think about maintenance
  61. Know well and articulate the technical terminology of your profession
  62. Know what architecture is
  63. Understand the various disciplines of your profession
  64. Always have an end state vision
  65. Be ready to achieve the end state via intermediate steps
  66. Start with the actors. IT is for people.
  67. For everything think levels, hierarchies and sets
  68. Do not mix types at any level in thought, pictorial models and text
  69. Encourage quality in your colleagues
  70. Be nice
  71. Respect the work, not the title
  72. Deliver your artifacts
  73. E-mails, phone calls and meetings are seldom real work
  74. Do more, manage less
  75. PPTs and e-mails are not real artifacts
  76. There has to be an underlying business case
  77. Given enough money and time, almost anything is possible
  78. Always think top-down
  79. Get certified. It teaches you the language and thinking of your guild.
  80. Explain to non-architects without jargon
  81. You are not an architect if you can’t draw…..adequately, competently, excellently
  82. A drawing speaks, to an audience and with a subject. It must speak cleanly and clearly using layout, boxes, sizes, lines, text, colours and legends.
  83. Abandon the software tool if using it is taking more time than the architectural thinking itself
  84. Remember that great architecture has often been produced without great technology

That’s it, for now.

Connect with me:

Leave a Reply!

Scroll to Top
%d bloggers like this: