I find there are several key considerations beyond my discussions so far to determine the architectural design. One issue is to define a process/methodology for steering key design decision based on, at least, relative scales of measurement. The other relates to the technology per se. I will treat the latter first (I admit to procrastinating from the real hard one. Hey, this is my blog - so here we go). One of the key aspects driving the interest in Services and SOA is the concept of "loose coupling". Admittedly, this is not a new idea at all. With Services/SOA this is a core concept and benefit. There are architectural patterns delivering loosely coupled systems with proper encapsulation and of course approaches that do not. It is one thing to have an architectural design and it is quite another to properly implement the design to realize the goals/attributes. Every part of the technology stack contributes or hinders, for any particular design or sub-design, the achievement of the design and via extension the goals/attributes. Personally, I think this relates to the capabilities inherent the Product Types and then more limitedly to the actual products. There are some Product Types that easily enable loose coupling and other objectives for elements of the overall design and then there are some making it difficult and/or impeding it. So I how do I break this down. I wish I could figure out how to put a graphic on this blog, since I have one. In light of my blogging challengedness I will endeavor to explain it. Hopefully, I will resolve my ignorance and get the graphic posted. Imagine a vertical access indicating "coupledness". Highly or completely loosely coupled at the top of the axis and completely or tightly coupled at the bottom of the axis. Starting from the top and working down (from loosely to tightly coupled) this is the way I categorize the solutions and Product Types. • Enterprise Service - Loosely Coupled with Canonical Definitions (standard defined interfaces used instead of application or transaction specific interfaces). o Service Frameworks - There really isn't a Product Type called Service Frameworks. I'll explain the trick I'm pulling below. o Orchestration/Collaboration Servers - usually integrated with ESB or EAI products. I believe Enterprise Services are best not implemented directly in the EAI/ESB middleware. The Enterprise Service is more appropriately deployed as an end point. This can be accessed either via the middleware or by loopup call (using UDDI etc). Building Enterprise Services in this fashion is dependent on the tooling an Enterprise uses. It turns out to accomplish this in the manner I outlined usually requires custom development. Now there are many kinds of frameworks that can be deployed within the Enterprise Service to deliver the functionality, but the overall Service is likely a custom component deployed in a J2EE or .NET application server independent of the ESB/EAI/ETL products. Orchestration/Collaboration/ESB/EAI products help with many of the infrastructure needs that might be required, such as mapping to a canonical format, data augmentation, etc. • Functional/Legacy Service - Loosely Coupled with no Canonical Definitions (unless a layer is wrapped around the functionality to translate from the Canonical to the legacy interface). o Collaboration Servers - heavy usage of technology specific adapters is common o EAI/ESB products - heavy usage of technology specific adapters is common o Application Servers - not always a good fit depending on issues of protocol mediation, functional needs, and special access tooling Functional/Legacy Services are fairly common. Examples of Legacy Services include exposing CICS transactions, MQ applications, mid-range applications, etc. The goal is to derive continued value out of existing functionality by leveraging a different interface methodology/technology. Many vendors offer complex adapters to enable this process. In other cases the Service is purely functional. For instance, health care claims generally are checked for syntactic structure and specific common semantics (zip code, state identifiers, etc). This kind of function can be exposed as a Service. This is not a classic coarse grained business operation, however, there is benefit to this approach for many reasons. • Interchange Gateway - Moderately Loosely Coupled with no Canonical Definitions This type of solution is primarily used for protocol mediation. With today's tooling this is often an assumed service available with added functionality higher up in the stack. Often the protocol mediation is the adapter for specific mappings/connections, such as to IMS, screen scraping, etc. Protocol mediation as a stand-alone need versus as a function part of a larger process is the question. There is no value to invest more into some kind of transactions, meaning there are efforts it is not worthwhile to add any more sophistication or effort. • ETL - Moderately Tightly to Tightly Coupled. ETL can abstract data sources. In this fashion, ETL exhibits less tight coupling then a pure SQL solution. Under the covers the ETL product is tightly coupled to the data server, schema, etc. In my mind, ETL, straddles between slightly loosely coupled to fairly tightly coupled. ETL products have interfaces today to many protocols, such as JMS, persistent messaging, web services, etc. This makes extending the product easier then in the past, but the strengths are not in protocol mediation, service capability, and/or transactional orchestration/collaboration. • Programmatically - Tightly Coupled And lastly, programmatically. Integration can be accomplished via custom code. Now some might argue, that using some approach/methods this could be a loosely coupled solution (my definition of Enterprise Services above). Keep in mind such functions as ODBC/JDBC, vendor specific APIs for add-on software, etc. It is possible to add some flexibility into the application space so that some changes are based on configuration instead of re-compile. The popular interest in Inversion of Control (IoC) frameworks is an example. Using one of the frameworks, a particular implementation can be changed via configuration. Some flexibility is possible, but in essence the solution is still compiled. There is my take on a key architectural design principle, loose coupling, as it relates to the technology stack. If part of my design is ripe for an Enterprise Service implementation, I will use a Service Framework and possibly an Orchestration/Collaboration Server. I will not use a Gateway product or an ETL tool. I have recently worked on several projects requiring extensive data extraction. For that portion of the work, nothing but ETL, I wouldn't want to do it any other way. Other parts of the project including routing, remote system connection, etc, other capabilities were used. I mentioned previously that I tend to use the right tool for the job. This means that integration of different products is a requirement. This is a one time effort and all other projects can benefit from this. I guess next time, I will talk about the hard part which is deciding if a need is worthy of being an Enterprise Service or something else. I hope this was interesting. I often look at issues/problems in ways that make sense to me, but I am not sure that is true for others. Take care and keep up the good work.