Boiling SOA to 3 Simple Patterns

I love SOA. There I said it! It's done more than pay my bills, it's helped me strategize robust solutions to help businesses succeed. I can't see how any organizaiton can survive without a SOA an strategy! Ok, enough with the SOA love fest. Recently, I have been discussing and debating with some of my colleagues my thought process that Services should be the foundation for anything integration. Even when Ms. Maine proclaimed “SOA is Dead”, she followed up with “long live Services”. Let me explain my rationale. I see services as used and re-used in 3 simple, high-level integration patterns and this is how services can be the foundation for anything integration:

(1) System-to-System integration. Everyone should be very familiar with this pattern. This is 90% of all integration issues. Information Sharing. Data Exchanging. Synchronizing. Hetergenous systems, businesses, applications. Getting data from point A to point B in the right format, at the right time, and with the uptmost quality. This can be real-time or batch. It can be atomic transactions or bulk data loads. All of this should be used through services! Does this mean webServices? Not necessarily, as we know for example that ETL can’t afford the overhead of HTTP and XML. Not to beat a dead horse for the SOA experts, but I think many out there still don't understand that a service isn’t necessarily a webService. What is more important than webServices is the notion of architecting and exposing Business Services that can be consumed and re-used across enterprise. Not rocket science, and most SOA-educated get this!

(2) Business Process Management. A business process should ultimately simply be the orchestration of services across an end-to-end business process during runtime execution of the process. A BPM/BPEL should map business services to each Level 1 activity in a multi-level process flow or process map. Pretty simple: each activity is a business service at Level 1. This approach enables your business process, at runtime, to reuse the same services used in system-to-system integration from Pattern #1 and be easily managed and monitored. Ultimately, you can see where I am going-- our goal is to create a single version of the truth that can be used across all 3 patterns.

(3) Composite Applications: I recommend to clients to re-think their approach to building applications and that not everything requires development or integration to the back-end or legacy systems. Instead, they can focus on developing the business rules and the front-end functionality of these user-enabled applications. No longer do they require using "legacy" techniques that create complexity and more architecture hairballs; rather, they can leverage services to simplify all the plumbing required in a typical application development lifecycle. Why build 1-off websites, dashboards, reports, or mobile applications and re-invent the wheel with all the hard work required for interfacing, security, transformation, translation without re-using services that could already exist? Your creating a bigger architecture hairball! Instead, use a “mashup approach”, and re-use the same services from pattern #1 and #2 and make your life simpler! Re-usability! Hide the complexity and consume what has been exposed! See, my approach with SOA is to untangle the hairball that exists in organizations and not create more lines of code, more interfaces, more maintenance. If we are building another interface another integration to maintain for web or portal development, we are making the hairball worse. Instead, we should be using services to mask the complexity of integrating user-facing applications to legacy systems. This will allow us to reduce and wither away the hairball.