In thinking about the management challenges of utility computing (how do you manage 10,000 virtual machines anyway?) it was obvious that the right high level abstraction for management is the composite application. A composite application represents the collection of services (ala SOA) that are being brought together to perform some action. This then got me thinking about SOA in general and has led to a new project I'm working on in parallel to the utility computing work called SOA Lifecycle (SOAL). But, as with my utility computing priorities article, I like to know what my priorities are before I dive into a project. So below I explore what I believe the priorities are for SOA in the enterprise.
My priorities for building software to enable SOA in the Enterprise:
-
Re-Use
-
Manageability
-
Simplicity
(Note: See here for my definition of SOA)
Re-Use: I start off with Re-Use because I believe that this is the fundamental value of SOA. At the risk of radically over simplifying, the single most important factor in the growth of an economy is productivity. Or, to put it more bluntly, the faster productivity goes up the faster we all get rich. I believe that SOA (read: networked code) will, if its potential is realized, provide an enormous productivity boost because of re-use. With SOA if someone, somewhere designs a process that does something well it suddenly becomes possible for everyone, everywhere (in theory anyway) to go re-use it. Furthermore this re-use can occur as easily within a company as across companies (again, in theory). Yes, I know, this is all kind of obvious. But in picking from the pot of obvious ideas about SOA I think this one is the most important. The more things we do to enable re-use the richer we will all be.
Manageability: SOA in the enterprise is, I believe, fundamentally about making it possible for machines to talk to other machines (as opposed to most Software as a Service use cases which typically involve machines talking to humans). The result being that the machines handle the day to day drudgery of running a business leaving the people to deal with more interesting issues. But the downside of a machine to machine environment is that machines are unspeakably stupid. If an interface changes in even the most trivial way it's quite likely that all of the other services that try to consume that interface will fail. Yes, I know, loose coupling (a.k.a. versioning) will solve all of our problems. But as I have discussed previously, nirvana isn't here quite yet. So in the meantime what we will have to have is management. Management tools will be crucial in order to enable administrators to monitor the services they depend on and to manage changes when they are required.
Simplicity: The Rube Goldbergesque fiasco that is WSDL, XML Schema and WS-* should, I hope, act as a useful reminder of a very old lesson – complexity is the enemy of reliability. Building a huge stack of specs and products and then saying to Enterprise developers "Go build on this peak" has been and will continue to be a recipe for failure. We must radically simplify the SOA infrastructure or it will never properly work. This means, for example, largely ignoring WSDL and eschewing XML Schema. This means pretty much automatically staying away from any spec that has a "WS" in front of it. Following these rules one would look at a nightmare like WSDM and run in the opposite direction. In any case the point is to start with the simplest infrastructure possible (XML+HTTP) and only add new infrastructure features when absolutely necessary.
You sure you work at BEA? 8-)
Nicely said wrt complexity. Totally agreed.
Ahh, today we get to agree. But when I start talking about Relax NG, choreography and reliable messaging I bet you’ll think I work for BEA again. :)
For me the goal however is to prove beyond a reasonable doubt that these complications are really necessary. I think for most “software as a service”/”web 2.0″/”insert trendy identifier here” use cases choreography/reliable messaging/etc. aren’t necessary.
But I’m specifically focusing on Enterprise SOA and as I hope to demonstrate I do believe these technologies are necessary in that arena. I’ll be interested in hearing your feedback when I publish articles with my justifications.
Ah, there’s the BEA-ness. 8-) Looking forward to your next posts…
FWIW, as an architect, I know that there’s a possibility of there being cases where trading off simplicity, perhaps in a big way, will be the right choice. But I doubt *very* much that such a complex solution is anywhere near general enough to be interesting or high value enough to reify in tools. But if you can show me evidence to the contrary, I’ll eat my words.
One of my SOA prios is Flexibility fur Business Alignment. Current monolithic IT Systems fail to support a changing business, and complicated customizing requires IT people to understand business ppl (and that constantly fails).
So SOA is about providing an Infrastructure for the Business – for BPM.
And BTW I think it would be nice if reuse is a possitive outcome of SO Architectures, however if we look at traditional inhouse coding reuse is seldom and when it happens it complicates things, so I am not sure if reuse will happen at a large scale.
I predict it only works for pre-packaged services and processes – which will somehow have the same problem as current inflexible packages.
Greetings
Bernd
I would have prioritized (1) re-use and (2) simplicity as the core requirements. Improved manageability – like improved adaptability or improved development – would flow from these.
I think we need to understand why re-use has typically failed. I think the main reason is that it cost more than it was worth.
We already knew back in the COM days that the only components that got serious re-use (and keep in mind, the numbers I saw even in those days said the re-usable COM component market was worth more than $1 billion dollars/year) were big chunky ones that did really complex things nobody wanted to re-invent.
I think the same logic will apply here. I don’t imagine that someone is going to invent a ‘time stamp’ service and suddenly everyone will use it. But if one division manages to get a working tax compliance calculator for the EU you can bet that every other group will be looking to re-use it IF the costs aren’t too high.
Also keep in mind that for me “re-use” doesn’t mean “just start calling the other service”. I always expect there to be work to get two non-trivial services working together. But if the work to get two services working together is substantially less than re-writing the whole thing from scratch then the motivation will be there.
That’s why I see it as our job to do our best to make sure re-use is as easy as it should be.
What drove me to put manageability as #2 is that SOA tends to result in big complex distributed spaghetti style messes. Systems like that don’t stay running on their own. They require a lot of care and feeding.
Yes, making re-use easier and making the system simpler will make management much easier. But at this point I’m reaching the conclusion that if we don’t explicitly think about how we will deal with 90% of a product’s life cycle (e.g. development usually only accounts for 10%) up-front then we are likely to miss really important things.
Management has been an after thought for too long and we are all paying the price. Especially BEA, dollars that could go to buying licenses from us are instead going into paying hordes of people to care and feed for existing, unmanageable, messes.
Jaron, I fully agree, distributed systems can only succeed if they are manageable, i.e. system supports RAS aspects. Otherwise it is too costly.
(However modularity and components dont necesaryly mean you have networked components, you can deploy them in a single app server just fine).
Bernd