Building architectures in IT often refers to the traditional architecture for their concepts, and indeed IT architecture has often the same issues as its sister discipline:
- Some architects have never built or even repaired houses; in IT, you have architects who were never developers on existing projects, just new technology ones or they were never part of any on-call system engineer teams; if they never tried to fix unforeseen problems at night, there are good chances that their proposals will lack good sense. The worse case you can find in your professional environment is people who were so bad at operational tasks that they get promoted to avoid incidents (Dilbert effect);
- Other architects love cocktails but not mud; those corresponding IT architects love paper design and meetings with boards but not with end-users; again using their proposed systems will be a nightmare;
- A couple of those architects sell you buildings without looking at their orientation or the climate they will endure; the corresponding IT architects deliver you solutions from their own shelves without asking you what you need;
- Finally, some architects don’t know how to speak and work with the people from the various professional bodies you need to build a house; in IT, they don’t interact with developers nor with system engineers
Finding one of those traits in the behavior of your IT colleagues should raise a warning about the good health of the project and its ability to fulfill the users’ need.
In the ‘brick and mortar’ architecture there’s a name for it: ivory tower; what’s the name in the IT field? NGINGO (NoGood input, no good output) systems?