Wednesday, July 19, 2006

Practical AgileSOA - How to promote and incentivise reuse

Question: why would anyone use other people's products?
Answer: when they are better than they can make themselves.

Traditionally, software development was not considered proper unless an application was built from scratch. Over the years, more and more components have become available and these products have become better. Today many of these products are so good that it doesn't pay to rebuild them. So software development is now done using a multitude of other people's products

So it must be with services.

Services must be so solid and reliable that it doesn't pay for others to re-implement their functionality. But how do you know when a service is solid and reliable enough?
While there is no absolute formula or metric that makes a service pass a standardized quality test, it serves to understand what the critical aspects are of designing and building services that people will want to use.

First and foremost, the service functionality needs to be designed so that it actually does something useful. While that is different from business to business, the concept should be obvious. A service that just serves up database records provides no value. A service that locates the correct database records, processes them and serves them up as a useable bundle provides something useful. A service that simply collects performance data may be a good building block, but it truly comes to life when it starts to interpret that data to provide intelligent monitoring.

Secondly, a service needs to be built using TDD. All functionality needs to be unambiguously testable. These tests need to be run every time a change is made, preferably using continuous integration tools. A service without bugs trumps just about any application. In this case, statistics are your friend.

Thirdly, a service should behave like a good building block. That means that a client has to have just knowledge of how to invoke it or subscribe to it, and what to expect back.
It should not have to be aware of the state of a service, unless that state is what the service provides.

Next post: Getting some governance started


Post a Comment

<< Home