Having experienced the phenomenon for quite some time, today I've christened it: "Archiconjecture".

This is the endless contemplation, discussion, postulation, and high-level design that goes on between architects designing systems out of context of the real world.  It is a situation that arises when there is an imbalance in the relationship between the technology and the business it "serves".  The choice of the word "serves" is specific - if a partnership exists between the two sides of the company, then this imbalance is far less likely.  However, when the business feels that technology investment is a tax to be paid if necessary and avoided where possible, as is often the case in this post .COM IT-sceptic marketplace, the ability to introduce technology change is restricted.

Whilst it is easy to blame the business for a rigid stance, the blame really lies with the lack of a common understanding and focus of effort.  The business is concerned with only one thing - maximising profit at minimum risk.  This is where their effort is expended.  Some "architects" expend their effort designing the most complete, technically immaculate systems they can.  This is where the disparity occurs.  Whilst the design of a system may be immaculate - presenting no risks in terms of implementation costs, running costs, or security flaws, this somewhat misses the point - the risk may well be in whether the cost of implementation is outweighed in the value it will add once completed.

To avoid endless archiconjecture, there are are two things to understand:

• The business must understand that an architecture needs maintenance to remain agile - it can't be left to stagnate or the cost of projects in the long term will rise.
• The architects must understand that technology is only used in companies as a means to an end, and that any cost systems incur is taken directly off the company's bottom line.  The "best technology" and the "best technology for the business" are different things

And there are two tasks to undertake:

• The business must define precisely what value any given system will provide, and consider the value of any system to the company as a whole, not just their specific project.
• The architects must design a solution that costs less than this value, with any technically unnecessary but desirable architectural change defined in terms of cost and value.

The day that you spot archiconjecture in a company is a good day to organise a meeting between architects and the Business, where they can discuss change in terms of risk, value, and agility.