Tomas Erl have written a very interesting article about the transition to service oriented architecture in an organization. The article gives a set of best practices to assist in this shift.
One of the biggest issues, according to him, is the lack of understanding what SOA really is. That is also my experience. One of the first things to do, when making this shift, is to educate the organization and not only the developers. And do it several times, over and over again. Be very clear with the definitions of layers and such, so that the whole organization speaks the same language. Without this, it will be hard to discuss the implementation of this architecture.
One other thing is to understand that SOA is not only web services. It's so much more. The web service part is mainly only the implementation technology, probably the best one right now.
The last thing that comes to my mind when reading this article is that the organization could require new roles when implementing SOA. The first role that I think of is the xsd or schema librarian. It is a dba for xml. It's a person that is responsible for creating schemas for all information in the company and how they relate to each other.
It’s always interesting to see people act when a new buzz word shows up. The buzz sweeps like a wave from somewhere by someone of some reason. Some people starts working their new agenda based on the first wave, other on the coming waves. It doesn’t matter when you start, you will always fail if don’t know where it is coming from. So where does SOA come from?
Let me guess! I start from the beginning, with money. Money in this industry goes to maintenance of the legacy systems. Software companies wants to be there. They want IT organisations to rip down and replace their legacy systems with a new technology that can run on their own hw/sw. Sun created java as an excuse to buy their hw, but failed when java became a fat teenager.
IBM is responsible for all these maintenance related costs but still tries to exploit their technologies, and they are successfull. They got lobbyists like Grima. "Father, forgive them; for they know not what they do."
Linux supporters want it too, but they can’t make it fly either (yet). No one trust things that are too cheap.
The sun/ms war has left some ugly cadavers on the ground, such as intercepted containers and object oriented programming that we now have to live with. I would say that real legacy systems (main frames) are far from the problems one face from java, oo and container based systems. To step away from all this mess, people started communities to kiss up and be friends. Like the most important one of them all, The XML Protocol Working Group. They created the Ring called SOAP and the tail can be read in the WS-* specifications. If you understand the formula you can join another community, a group that includes all the people who wants the money from the legacy. The formula explains how you can build things like Indigo. If you have other plans like Spring Framework, just drop it. The path is already there and it spells Web Services.
Well, we can’t rip and replace. Rip and replace is history. Could we use Web Services? Yes! Let’s hook up and extend the main frames instead.
Microsoft was banned from this area and was deported to desktop development because of their heritage, until today. With .NET they got one foot inside the door. Now wonderfull things can happen. Cobol is supported as a language for creating managed code. A new strategy is born. Lift and shift from cobol on main frame to cobol in CLR on windows/intel.
First cut of the oxygen to the legacy system, then pull away the carpet underneath it and without anyone noticing we all got Longhorn running all software in the world.
Posted by: Jonas Ekström | 2004-11-24 at 19.32