Wednesday, August 27, 2008

Top 5 Uses for Google Earth

I was so inspired by this post on a great use of Google Earth I decided to come up with some other great uses of this technology. I know most of you have been struggling with how to leverage cloud computing and/or services hosted by external vendors. I'm here for you. Here's my top 5 uses.

5. Finding SOA. After all figuring out the oriented part is half the battle. Now you can know which way your SOA is oriented using hi-tech satellites. I believe the research will prove out that it's east/west instead of service. That would explain why so many here in the US are struggling with it. So that would be EOA and WOA(Don't confuse West Oriented Architecture with Web Oriented Architecture, this has nothing to do with spiders).

4. Finding the shortest lines at Disney World. I just got back and it would have been very helpful.

3. Finding Disney Land France. Apparently the British have no idea this exist and is just a train ride under the sea away.

2. Enforcing SOA Governance Policies. Yes by linking in the Google Earth satellite photos to our space based defense system you should now be able to fire a highly concentrated laser beam at wrongly oriented SOA implementations.

1. Cow Tipping of course. Now that you know where they are and which way they are facing it should be much easier.

Feel free to chime in with your own amazing uses of Google Earth. Please stay away from the mundane stuff like finding energy, fighting crime etc..

Tuesday, August 19, 2008

Extending Services

Here is a good example of taking an existing service and adding functionality to it without breaking the existing interface. Enjoy.

Friday, August 15, 2008

SOA in the wild

Is that a SOA in the freezer? Just substitute the acronym SOA everywhere you see Bigfoot in the article. The similarities are uncanny.

Thursday, August 14, 2008

Runtime Discovery and Composition

Brenda Michelson put up this post from Melvin Greer about SOA and the "Hard Problems". It's good stuff especially this part from Melvin:

Within the engineering category, Mel spoke of altering existing development processes and methodologies for SOA, designing for context awareness, and designing for runtime discovery and composition. In respect to runtime discovery and composition, Lockheed Martin is trying to determine the best way for a running to composition to become aware of newly delivered capability. As an example, Mel called out how the Mars Land Rover continues to receive new capability without returning to earth

I must admit I have always been skeptical about runtime discovery and composition. I just haven't found a lot use cases that ever made sense. I just don't see this been very practical in the wild of the typical business. Now before you jump in, the programming of the Mars Rover is not normal business activity although way cool job.

Understanding the context of possible uses for services in different compositions seems amazingly challenging to me. Just getting services to be agile and reusable within known business context is very challenging. I certainly would like to hear more from folks who are exploring this space or have implemented solutions that would fit into this categorization. I thinking more along the lines of business type services not generic utility type services which can apply to any context. Anybody out there doing this?

Saturday, August 09, 2008

Agility versus Reuse

Joe McKendrick wrote a post about CIO's and SOA. In the post he touch on a subject that is near and dear to me. Is the value proposition with SOA more slanted towards the agility it brings to the business or in reuse?

Architecting and coding for agility is nothing new. The principals behind it abstraction, loose coupling have been around for a while. Folks who have been in the OOP world or the EAI world know all about hiding the guts of the underlying implementation from the consumer. The better job you do at that the more agile your service, interface, object, message or whatever you want to call it, is. That's the technical side of agility, the other side is governance. Keeping the interfaces agile requires governance. That can get pretty difficult. The very benefit that the business tends to like about agile IT stuff can also make it very difficult to sustain.

The constant change associated with most businesses and the demand that places on the IT staff can make maintaining the agile infrastructure challenging to say the least. Without strong governance the agile interfaces quickly become very brittle. It is harder to design and code agile interfaces which means shortcuts tend to creep in as the business demands more change.

Reuse complicates the matter even more. Reuse requires picking the right level of granularity for the interfaces as well anticipating some degree of polymorphism across different domains of business. This generally requires a lot more effort during design time especially when moving from IT type services to more business oriented services. I have personally found this to be a significant challenge. It is challenging on two different levels, technical and business oriented.

The technical challenge lies in the both picking the right level of granularity for the services and developing reusable data structures to support this. I have generally found that the lower the granularity level is then more potential for reuse exist and the easier the design. You can always combine lower level services to move up the stack.

The business challenge is far more difficult in my opinion. Reuse especially across business domains requires a very good understanding of the business as well as a solid partnership with the business. This understanding and partnership is not at a high level but rather at a very detailed level for reuse design. Given the pace at which the business moves this can be very difficult to achieve.

I think keeping the interfaces agile and picking small battles for reuse makes some sense from a realism perspective. I have never been convinced completely that SOA would actually save money because of reuse. I do believe in the power of agile interfaces. No doubt that some folks will be successful with large scale reuse in the SOA space. I think for the masses however, achieving an agile infrastructure is a significant accomplishment that will pay dividends with some hard work of course.