It's raining out, so it's a great time to be inside and hear about the new buzz terms as they hit Smalltalk. Andy Berry is going to cover what SOA (Service Oriented Architecture) is.and what the business benefits and risks are. In particular, he'll cover how it interacts with Smalltalk.

What is "architecture"? Let's pretend that you won the lottery and ask a builder to build you a new house... Heh - Andy has a picture of what you have in mind, and a picture of what the builder actually produced (I lived this one when we had our house built - we didn't get the cathedral ceilings at all where we wanted them...). Like Andy says, the builder always has a rationalization at hand to explain why things went the way they did.

So... consider a city, where you end up with lots of buildings. You want it to all mesh. Now, apply that to IT - you have apps for Sales, Billing, Q/A (etc) - they probably are all silos. They should all tie together (eg - a Sales Enquiry should be able to "turn into" an Invoice w/o any hard work). The bottom line - a suite of applications that work together this way will save money.

An IT architecture must tell us how to link things together. Has to consider both the business itself and the world around it. At this point, imagine a circle ("The World") with boxes for your customers, your suppliers, your company, and your enablers. That's what your architecture has to tie together.

"A Service Oriented Architecture is a way of including everyone - Customers, Suppliers and Enablers - as partners in your IT system" So, an SOA is an architecture designed around services. What's a service? posit a taxi driver, who you call to take you from point A to B - the taxi driver has provided a service. Side note - how the driver gets paid is an interesting point all by itself.

Services:

• Business Oriented - don't tell the taxi driver how to drive
• Asynchronous - I make a request, and it later happens
• Normally, you get what you ask for

Returning to IT - Always ask yourself - can I imagine myself doing this? If so, it could probably be made into a service. A service to submit an invoice is high enough level to call a service. Where does this fit - design/architecture level, or code level? Is SOA:

• The most important development in the last ten years?
• An interesting development that your company should monitor?
• Just a messaging application?

Andy falls into camp two above - start thinking about it, and see how you could/should use it. Consider doing an internal project before trying to go outside the company's walls. So Andy asks us: Can you think of three business oriented services that would allow parts of your company to work more effectively together?

Implementation:

• Do it yourself
• Us a supplier like IBM, Iona (et. al.)
• If you do that, make sure you get monitoring

One option is to use what's called as ESB (Enterprise Service Buss). InfoWorld just did a wrap up on those, iirc - I think I threw rocks at it :) The basic idea is that you wrapper your applications in a messaging layer. What goes on the "bus" - messages - typically, Web Services messages.

At the implementation level, a web service is a service delivered by XML encoded messages. Andy is referring us to "The Semantic Web" by Berners-Lee. This is where you end up intersecting with the "Web 2.0" folks - including the RDF crew.

So what are the benefits? You automate (as much as possible) your communications flow with your suppliers. A simple example of this sort of thing is how we (Cincom Smalltalk) handle "goodie" submissions from authors. They register with us, and then have access to an FTP site. Our normal build process pulls the latest from there - thus eliminating the need for reminder emails. The upshot here is to end up with an architecture rather than a set of isolated silos. You should end up automating out a bunch of things with customers and suppliers.

The risks? At this point, you'll be an early adopter - meaning that you'll inclur extra costs, and be off the wrong way if the buzz ship moves along. How can you mitigate that? Andy's suggestion is that Smalltalk helps here, by dint of its flexibility - and it's supported in Smalltalk (VW and VA, for sure). More:

• Don't bet the business - start small
• Ensure access to mentors that have done this before
• Choose a product before you start implementing.

At the end of this, you want an architecture, not just another "cool" use of buzzword bingo technology. Start small, get buy-in from the right people in your organization, and try to pick an obvious starting point to prototype.

Back to that taxi driver and payment - we just hand him money. Translated to IT, what we really want is "pay as you go" services that are metered. Yes, it sounds utopian - but it's probably a level of outsourcing that will work.