In the work that we are doing in iECM we keep coming back to a discussion around what the right term is for what we are creating. I’ve gotten a bit distracted for a few hours trying to find a consistent definition of the various “xyz architecture” terms (reference architecture, technical architecture, abstract architecture, etc.). Guess what. All of these terms are a bit overloaded (I know, surprising ;-)).Take just one of these – Reference Architecture – a bit of investigation finds little consistency with how this term is used. First off, there are many different reasons for the creation of a reference architecture including providing a baseline against which developers can build a solution, providing deployment guidelines and even describing very specific solution. What is in them also varies wildly from being extremely high level (providing what my iECM colleague Stuart Williams of HP would call a conceptual model), to very detailed; some assign vendor products or standards, others remain entirely distinct from specific technologies.The conclusion I have come to is that any “xyz architecture” document should first define the term in the manner it is used addressing the purpose of the architecture as well as a characterization of contents or style thereof.For what we are doing in iECM, I particularly like the term “reference model”; what we are proposing is consistent with description given in the OASIS Reference Model for Service Oriented Architectures.

This Reference Model for Service Oriented Architectures is an abstract framework for understanding the significant entities and relationships between them within service oriented systems, and for the development of consistent standards or specifications supporting that environment. It is based on core unifying concepts of SOA and may be used by architects developing specific service oriented architectures or by those needing to explain SOA principles. A reference model is not directly tied to any standards, technologies or other concrete implementation details. It does seek to provide a common semantics that can be used unambiguously across and between different implementations.