Conversive Services Part 2

In my last post I talked about the concept of dynamic services holding a conversation to achieve a goal rather than just the usual request and response service calls that many of us are familiar with.

Why bother to hold a conversation between services?

Well, when two people meet for the first time it is good to get to know one another. What interests both parties have in common or an exchange of ideas and opinions. In system terms it is good to get to know the service consumer so that you understand them better and can put their requests into context.

In the previous post I discussed the example of a currency service not being able to convert two currencies. In this example the service can identify the context, monetry conversion for going on holiday, and make a decision on how to handle the request. If the request, as in this case, is obviously for tourism, then the service may behave in one of several ways.

1. It may decide that it should not process obvious tourism related requests (based on context) and redirect the consumer elsewhere.
2. It may gracefully redirect the consumer to an affiliate service that can process the request once it discovers that it cannot convert the currencies.
3. It may log the context, the type of exception and then reply gracefully that it does not understand the consumers request.

This requires two things.

1. Intelligent services that can be configured to understand not only the request but the context of that request so that it can decide if it is the best agent to carry out the task.
2. Intelligent consumers that can communicate with and manage connections with intelligent services.

The next part of this blog will cover how services and consumers can find one another.

Stay tuned.

I am coining a new phrase…

Flying like a one bladed helicopter.

This phrase describes the point where a software project (the helicopter) believes it is going really well, when in reality it is slowly spiralling to its rather deadly rendezvous with the hard ground below.

If you are really lucky then the helicopter may stay airborne, but only because it is so damned ugly that the Earth just repels it.

Having worked on numerous helicopter projects, I can safely say that the first warning sign is when the system designer categorically states that they understands the customers needs when they cannot even name the customer.

Be warned! Stay vigilant.

Conversive Services

Recently there has been some dicussion about the merits of SOA as an approach for building a new lagacy of systems (and I do mean legacy unfortunately).

Am I a big fan of SOA as it stands at present? Not really, but this does not mean that it cannot be a great asset in the future. The basic set of principles seem reasonably sound, but I do not yet believe that there is a level of maturity in either the current technology or in the understanding of those who preach it.

Why am I not convinced?

For me, the whole concept of a service is that it should be kept loose. By binding a service to a contract, we can choose the service that we want to use, if and only if, it supports a predetermined contract. This sounds rather tight to me. Okay, so I have choice over which service I use that supports a given interface, but if it later changes its contract then I am in deep trouble!

Now lets try to think differently. Imagine I want to convert Dollars to Euros.

1. I search for services that convert currencies.
2. I pass the values that I expect to be converted to a selected service.
3. I receive back an exchange rate.

Simple.

Now lets view this task as a conversation.

1. (Me) Do you convert currencies?
2. (Service) Yes I do. Why do you need the conversion?
3. (Me) I am going on my holidays.
4. (Service) What curencies would you like to convert?
5. (Me) Dollars to Euros.
6. (Service) How many Dollars need converting?
7. (Me) 200 Dollars.
8. (Service) 200 Dollars is worth 100 Euros.
9. (Me) Thank you.

Ah, what is going on? How have we managed to make such a long winded process out of what should be a very simple procedure? Well what happens if the service I am talking to can convert currencies, but not the ones that I want it to convert? The contract would be sound but I would still generate an exception in real terms. Conversive services aim to address this and many other issues associated with the contract based approach to services.

Over the next few posts I will explain why I think that this level of communication between services is necessary and hopefully get some bench time to code some examples.

Get into shape this recession

Okay, so the economy has come off the rails which everyone will agree is a bad thing.

Apart from me.

The downtime for me can be viewed as a positive thing when discussing software development. One of the biggest problems facing the development is the resistance to change. During this lull period, companies can, and should, take advantage of the current climate to make sure that their internal development processes are efficient and working in the customers best interests. The good old days of “just carrying on doing the same old thing everyday and not needing to change because nothing appears broken”, are gone. Customers have less money to spend so software development needs to do two things;

1. Reduce waste, and with it, costs.
2. Create flexibility.

The customer will have far higher levels of expectation when money is tight and they will be more diligent before they buy goods and services.Teams that can reduce their costs and increase their ability to adapt to difficult markets and quickly exploit niches will do very well for themselves. Those teams that don’t believe that they need to change should just carry on doing what they do everyday, until the P45 turns up in the post.

wii fit for all

I have recently experienced first hand, and achy legged, the marvel that is wii fit.

But why is it so good, and what can we learn from it?

I personally feel that wii fit is close to software development perfection, and it is typically Japanese when you look at it closely. The concept of lean development has been adhered to very closely and the software is all the better for it. Rather than creating a behemoth of a software title with a huge range of unused or often intimidating features that pad out the product description on the box, Nintendo have delivered just enough functionality to engage with its intended audience. Why go to the trouble of recreating Olympic sports in all their glory when the average customer wants to use it to lose just a few pounds, going to the extreme would have immediately alienated most of the potential buyers.

You see, the point of software projects that Nintendo has excelled at delivering but remain a mystery to many in the industry, is that to do just enough will deliver value to the end consumer to make them want it at a price they can afford. Too often in IT, we try to deliver too many features in our solutions that offer little value to the customer, but we feel we are providing value because the packaging looks very interesting and bulky. We forget too easily that once the customer has started using the title they will tell us what adds value to them, the packaging, no matter how glossy will never dictate importance to the consumer and should never be used as a benchmark for project success.

In one simple statement;

The value of software does not increase in proportion to the number of features but will decrease in proportion to cost.

We should learn from this software example that consumers will only use the features that they want, and when they are offered in a simple package that does just enough, they can’t buy enough of it. If the title does what they want, for a price they are happy with then the customer will be happy. Introducing too many features makes development times much longer, costlier and the likelihood of bugs going out in the final customer release increases, most likely devaluing the product as anyone that had to install patch after patch on the latest video games will probably agree with.

If only all software projects were as successful as wii fit, maybe then IT would not have such a poor reputation.

Agile basecamp

Today I have been working on Agile basecamp, a new website aimed at getting experienced agile adopting or disliking professionals, to share their views and to help educate those involved in software development that there is an alternative to process heavy development.

If you would like to get involved in helping me develop this site over the coming months then please contact me by email at agilebasecamp@hallamsolutions.com.

OurCommunityProjects Sneek Preview

I have found a little time this week to start work on the OurCommunityProjects.org website and you can see the mockup here http://www.agilebasecamp.com/ocp/

Please bear in mind that the site will be changing frequently, but any feedback you have on the look and feel and functionality would be appreciated.

When the site is ready for launch it will move here http://www.ourcommunityprojects.org which at the moment is just a holding page whilst development is in progress.

Enjoy 😀

OurCommunityProjects.org

Last night I finally got round to starting the development work on the OurCommunityProjects.org website. The OCP site, to give it it’s nickname, is a site dedicated to bringing people together to work on social projects on a local or regional scale.

More news to follow, but until then , check out the link.

www.ourcommunityprojects.org

The start of something wonderful

Today I had to explain the concepts of disposable software to people whos views I respect. Their reactions were somewhat curious, as rather than tell me I had gone mad, they instead asked me to explain further.

The idea of a model for developing disposable software has been in my head for a while and needed to reach the world. Others have talked about disposable software in the terms of what we know as hacking, this is not what I am advocating.

Lets say you build a 2 bedroomed house, its just the right size for you and your partner and all of the rooms are just as you want them. Over time you will want to improve it as you get a little more money from your day job, so you replace the furniture, replace the bathtub with a jacuzzi and landscape the garden, creating your perfect place.  You then have a small child so you redecorate the spare bedroom and fit child safety features all over the place.

So far so good.

Now you hit a snag. Your are expecting a second child and there just isn’t the space to accommodate the needs of two children, so what do you do. You don’t want to move because you have built the perfect home. You can either build an unwanted extension and knock through some walls spoiling the house you love, or move?

What does any of this have to do with disposable software and where is this blog going you may wonder?

Well, imagine that the house is a new system that you have just designed and the children represent unpredicted changes in circumstances. The first set of change was easily accommodated and the system function with little change from its original specification. The second change however was significant enough that it posed a considerable problem, do we make very expensive changes or move on? This problem is faced every day in software development and is a very expensive issue to deal with. Only by removing the emotional barriers in the software process can we make the right decision. Many people prefer a policy of modification over replacement because they don’t like the idea of throwing away all of their hard work.

The big misconception when making a decision on when to replace rather than modify is that replacing a system is more risky than modifying it. This is not always true. Through modification, we are only investing more emotional commitment to the system and we will lose sight of whether it is best serving the needs of the customer. This results in very expensive modification and support costs that will generally eat away at any profitability the changes may have offered.

My case for disposable software is that the removal of the people issues involved when making the difficult and emotional decisions will ultimately lead to the correct decisions being made based on goal and value principles rather than technical and pride related arguments.

So is disposable software just hacking? The answer is definitely NO! All I am advocating is that we need to look at what we can change in the software development arena to produce software that is goal specific, of good enough quality as defined by the customer and not by IT professionals, and will offer true value. The overall aim is to create systems that enable the customer to achieve their aims whilst being of such a low cost that they are expendable, where possible. This does not mean that we ditch the idea of reuse, but only extend the thought processes of reuse to areas that deserve it.