We started off with Distributed Spaghetti(DS). It was pretty bad. We had 100's of applications talking to each other using multiple protocols and no standard exchange format. Worse yet we really didn't know which apps were talking with which apps. It made maintenance and enhancements a lot of fun. Kind of like which brick do I pull out of this wall to make the whole thing collapse.
Then we moved on to Centralized Spaghetti (CS). The vendors came in with great new wares that promised to straighten out your noodles (don't even go there). Only problem was that there were some secrets on how to straighten your noodles and not everybody bothered to find them out. So we ended up with CS and then blamed the product and vendor.
But the best spaghetti was yet to come. The cool thing is nobody even knows it's spaghetti. Here the apps don't know their apps, they're called services. They still have to talk to each other but now they have a very special language. Turns out this special language is pretty complex. And you guessed it, not everyone bothers to learn it completely. Now we have promised our patrons a very elaborate 7 course meal that they can change to their whims right while it's being cooked. But as it turns out you still need cooks who know how to cook otherwise your back to the old standby, spaghetti. That's right, just about everyone knows how to make spaghetti. Raghu anyone?
So what's my point? Well it is a blog do I really have to have one? Okay here it is. Decent software design really hasn't changed that much in the past few years. Yes the technology is changing but the same old good software design principals have not. Encapsulation, abstraction, reuse blah blah blah have been around for a while now(granularity is a bit different). Please don't say SOA is different because it's about the business. If you have been producing software and architecture with total disregard for the business then you are probably seeking employment. If you were successful with OOP and EAI styles then SOA is not going to be a stretch. If you didn't do so well with those or didn't even attempt them then enjoy your Raghu, SBS style.
2 comments:
That is a fun metaphor...
We often call for the "Federated" approach to solving service management here at iTKO, which means the customer takes a more federal vs. states means of organizing the service implementations. (understand we are a SOA testing/virtualization vendor but we do make recommendations when we see them working...)
To do that you need to keep the rules for compliance very broad and simple at the central governing authority, and leave lots of room for interpretation and variance where the services themselves are managed.
Not ironically, we are seeing the US Federal government is getting pretty good about this approach - they know that there is a ton of variance in the actual implementations, so they only centralize the "promotion" of services for reuse, based on functional quality & performance. There are some standards, but that is not the crux of certification.
Of course you may have a UDDI Reg/Rep for the governance, but mostly we are talking about how to get the People on teams to think federated, not some out of the box solution or promise from a platform vendor.
Jason,
Thanks for the comment. I think being federated means you like distributed spaghetti. :)
On a serious note I keyed in to this part of you comment "To do that you need to keep the rules for compliance very broad and simple at the central governing authority". I think that approach makes a ton of sense. Over engineering the governance can have just as bad of results as over engineering the architecture.
This approach seems much more real world to me as opposed to the iron hand of the EA trying to control all.
Post a Comment