2009: The Year of Services
By David Dorf-Oracle on Jan 09, 2009
Anne Thomas Manes' comment SOA is Dead; Long Live Services is spot on if taken in context. Taken out of context, it can be quite shocking. But here's the important part of her blog posting:
Although the word “SOA” is dead, the requirement for service-oriented architecture is stronger than ever. But perhaps that’s the challenge: The acronym got in the way. People forgot what SOA stands for. They were too wrapped up in silly technology debates (e.g., “what’s the best ESB?” or “WS-* vs. REST”), and they missed the important stuff: architecture and services.
Maybe I should make a new year's resolution not to use the term "SOA" anymore. I do believe in the SOA tenets (oops, that resolution didn't last long), but by itself SOA is not a solution. Oracle Retail is taking a different approach. We're defining the business processes first, down to the BPEL detail level. Then we are able to more accurately define the data objects and services that are required to support the processes in a flexible and reusable manner. All of this is independent of technology and is driven by the needs of retailers, not their IT departments.
Services are what connect planning to execution, and for retail that's one of the golden rings. The retail version of Deming's Cycle is something like analyze-plan-execute-monitor, and services are what make the connections in an agile manner. Retailers know that consumer tastes change, and they need to roll with the punches -- that translates to agility.
Services are especially valuable when considering multi-channel, since much of the common functionality (e.g. price, tax, tender) can be encapsulated and reused. Why have separate tax engines for different channels? I've been there, and its mess on the back-end. It's so much easier to have a single tax service that handles tax calculations for all channels. In this case, consistency is a good thing.
Don't get me wrong -- services are not THE solution. There's still a prominent place for traditional applications and integration patterns. At least in retail, if you create too many services you run the risk of impacting scalability and performance. ETL still the best way to move large amounts of data, and MDM is a great way to keep data consistent. You have to apply the right tools to the right situations.
So I for one will try to tone down the use of "SOA" and all its baggage and instead put more focus on services.