Cuil it

That's really it in a nutshell. Cuil will never work because when you say Google it, you know exactly what the person means. When you say Cuil it, do you mean cool it or do you mean go find something. I say cool it to my 9 year old all the time, I also say Google it a lot as well. Especially during homework time. Cuil it will just cause way to much confusion. I'm already confused enough most of the time, I don't need this.

Pretty pictures though......

Service Based Spaghetti (SBS)

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.

SOA Governance from MuleSource

Joe McKendrick reported this from MuleSource. I think this is good news and worth a look at some point. Tools in this space tend to be pricey. It is nice to see something clearly aimed at a different customer segment. Lots of potential here I think. If I get a chance to take a closer look I'll post back the results of that at some point.

SOA Pitfalls

Here is some actual useful information on SOA Pitfalls posted by the folks over at Xebia. This article is more for the actual designer and implementer of services. It has some very practical advice on service granularity as well as issues you run into when using a CIM. With all the high level stuff/fluff on SOA still leading the way, it's nice to see some practical information based upon actual experience implementing this stuff. This is very good and useful reading. If you are actually involved in implementing services then the issues and solutions in this series of articles should ring home.

Business Activity Monitoring

One project I'm working on at the moment is using webMethod's Optimize for Process. It does BAM for processes. One feature of this product suite that I don't think webMethods does enough advertising on is it's ability to monitor external processes. This means you can send activity data to the BAM platform without using webMethods process engine runtime to manage your process. Basically any system or service that can invoke a web service can send data.

The really cool aspect of this is that you are able to map out your process using webMethods Designer and but then having it orchestrated or implemented by a completely different system(s). From the webMethods monitoring platform it still appears as a webMethods implemented process. If you are a webMethods customer, you should check out the functionality of the web service data collector that is part of the Optimize engine. It is extremely easy to use and features are very robust.