Interesting ideas from the fortune teller
Last friday, on TechEd's final day, I decided to visit some alternative sessions during the afternoon. One of them was a session called The Nerd, The Suit and The Fortune Teller by, respectively Clemens Vasters, Rafal Lukawiecki and Pat Helland. The format was basically one big discussion between a software developer, his manager and an oracle, or let's say an expensive consultant. The point of the session was clearly to get across the concepts behind the Service Oriented Architecture (I can't believe that they've now gotten me to the point that I'm writing about SOA on my weblog!) The manager was complaining about wasting lots of money on information technology without ever getting a proper return on investment while the developer was frustrated by the manager's inability to understand the underlying complexity of what he's asking from his developers by constantly changing requirements. The fortune teller attempted to get them to accept a new look at the way they use and develop information systems to make both their lives easier.
This session was good because it touched upon all the typical frustrations that both managers and developers have with eachother. Furthermore it gave me a good idea of how Microsoft sees the Service Oriented Architecture. The point appears to be that instead of trying to define fairly abstract requirements based on all processes, communication and datamodels inside an organisation and then turning this into one huge system, instead you first define all the different processes, or departments if you will, and then create a relatively smaller system for every one of them independently. Then you let them communicate across a service boundary (i.e. they send XML messages to eachother, although the implementation of that is ofcourse arbitrary). An important aspect of doing it this way is to ensure that you seperate all the information and responsibilities appropriately, otherwise you'll end up with similar problems as in the original approach. The advantage would be that this hard seperation and forced communication through messages makes it easier to modify these seperate systems.
During the session I definately liked this concept and even though I still do that, I'm not sure whether I truly buy into it as a solution to most of the traditional problems. In the traditional approach, you're supposed to do so-called subsystem decomposition which seperates the different responsibilities of the components making up your system. Also, after getting all the information that's floating around in your organization together, you normalize the datamodel so that all pieces of information that are supposed to depend on eachother do so in the most efficient and correct way.
All in all what it comes down to for me is that SOA makes sense if your developers are unable to properly create a system that accurately reflects your organisation's subsystems and datamodel. Still, if in practice people have a hard time to properly do this because it's simply too easy to make mistakes, then ofcourse it's a worthwhile approach to make it easier to do the right thing. I just wonder if people won't end up with services that are so focussed on the communication with the other services they were developed with, that adding a service will end up being just as complex as it used to be.