Architecture in software development tends to be one of those ambiguous terms that means many things to many people, and rarely the same thing to anyone. There are some things that are clearly architecture, some that are clearly not, and many that live in a grey world of ambiguity. In this respect it's much like service, the clear current leader for most ambiguous prevalent term in computing.

Modern enterprises need architecture at the enterprise level in order to build IT systems that are effective and coherent across the entire scope of their business. This is high level architecture where you are concerned with concepts such as governance and the interaction and responsibilities of different business units. The design units at this level tend to be applications and services, the implementation details of which are generally only cursorily considered.

Architecture at the enterprise level does not replace architecture at the application level, although it will define constraints upon applications that determine how an application operates in the larger enterprise context. Application level architecture is still critical in determining the maintainability, reliability, robustness, flexibility and performance of applications and therefore their utility and value to an organisation.

In this series of posts I plan to address architecture at the application level. I'll focus primarily on topics related to the architecture of line-of-business applications used in enterprises to support their business. Where relevant I may also discuss implementation related topics that exist in the grey area surrounding the core application architecture topics.