Wednesday, February 22, 2006

From blob to services

Many clients ask us what to do about their legacy applications.
Should they be converted to servicees ?
Where do you draw the boundaries ?
Do we need to rewrite our whole application?

In a nutshell, the boundary of a service lies where external knowledge of the inner workings ceases.
This means that a piece of functionality can become a service if a consumer can just ask it to do something or can simply consume its messages, without having to tell it how.

The best way to transform an application into services is to start teasing sections of it apart. The right boundaries will become apparent as you do this.
Take one section at a time, learn and apply that knowledge to the next section.

In the category " a picture speaks a thousand words"...

Friday, February 10, 2006

The Interplay of Agile and SOA


Here you can see more concretely how Agile and SOA enable one another.

Start with a bit of Agile to get the first services out there.
Your first services will make you more Agile, which will enable you to take services to the next level, et cetera, et cetera.

Thursday, February 09, 2006

Even the Army is getting it

So you thought that the government uniformly was an old ddog that couldn't learn new tricks.

They seem to be getting ready to become more Agile.

Read this :

http://www.defensesystems.com/issues/1_1/beyond_the_dog_tag/25-1.html

The Symbiosis of Agile and SOA



This is the symbiosis of Agile and SOA.

Start small.
Get solid, test-driven functionality out there and prove the skeptics wrong.
This way your will get your first services deployed at very low risk.

It's hard to argue with success.

A spark of Agile can bring an SOA to life

Some parts of Agile practices are needed to get the first bits of an SOA (a service) off the ground. This manifestation will prove to skeptics that deploying a small piece of business functionality that actually delivers business value (Agile) is possible in the most adverse of circumstances. It proves that the oft-heard cop-out “that will never work here” is bunk.

That first service can then motivate others to make their own services. Providing a registry where the uninitiated can find existing services will then spark a trend where people not on the bleeding edge can adopt services. Note that such a registry initialy can be just web pages.

At this time, introducing a little bit of governance, i.e. some approval process as to which services are listed in the registry, will provide some level of standards.

Adding a services monitoring tool to the infrastructure will validate the use of certain services. If these metrics are available in the registry, then prospective users can see whether a service is actually used and is actually performing within desired specs. This will then spur reuse, which will allow for iterative improvements and additions.

SOA and Agile are locked in a virtuous circle that creates a helix of progress. each stage of SOA maturity will allow for a new phase of Agile maturity.