My views with regard to these key questions: A definition of architecture states that it is the structure of a system and the description of its components and interconnections. As a structure, the architecture exists in any system, no matter how convoluted; and it can be described by an architecture diagram. For the target state of a system, a blueprint is drawn to describe the desired logical architecture of the system, that is its components and interconnections. This architecture blueprint enters then a design phase where technologies and products are selected for each component and interconnection. The end result, the Design blueprint consists of detailed drawings of the interconnected applications components. The design is ready now for implementation and as such, at last, the architecture is implemented in a physical system out of interconnected applications.
SOA, a style of architecture, consists of recognisable and reproducible architecture patterns. The style is applied to a target architecture which, after the design phase, is implemented in a system. SOA is at the same time an integration technology for services rather than applications. This is what vendors try to sell you: ESB, registries... based on SOAP/XML, UDDI, WSDL etc. SOA technology integrates and interconnects rather than implements the services of a system. But vendors also offer, in addition, business process (and rules) engines, B2B systems, application servers, service management and other products in their SOA offer. SOA, as a style, can be equally used in a complex application or in the target architecture of an Enterprise. The business component design of SOA is what people say you must do, not buy. You do have to specify your business services first and then interconnect them with a SOA technology. Can you say implement SOA services once you specified then? You probably can. But there is more of that in this book, just published (second edition): "An Enterprise Architecture Development Framework" (subtitle "Business Case, Best Practices and Strategic Planning for the Enterprise"), available from Trafford at www.trafford.com/06-0421 and soon on Amazon. Content of potential interest to you (although the book is not entirely aimed at IT people): an EA architecture framework consisting of the business, technology and people/organization layers, EA frameworks mapping and classification, an EA development exercise to clarify the EA process and deliverables at every step, the Enterprise Value Chain, business model and functional architecture, UML stakeholders' use cases, an EA maturity model, inhibitors and politics, relationship to SOA, BPM, ERP, Enterprise Architect role... Hope it is useful. Adrian
