Pragmatic Dictator

A graphic demonstration of how short-term thinking over strategy can be outright life-threatening:

I was out driving this morning on a dual carriageway, approaching a slip-road in lane two (the outside lane) so as to avoid merging traffic. In front of me is another driver who in their impatience is on the boot-lid of another vehicle, we’re right on top of the merge point for the slip-road now which is a feeder from the M4. At this point, the boot-lid surfer dives into the inside lane clearly intent on an undertake, failing to account for the motor-cycllst merging from the slip road. What follows is best described as a lucky escape with both motor-cyclist and boot-lid surfer taking evasive action.

Many a technical decision is taken without measuring, pausing for strategic thought or evaluating alternatives. What we typically do is jump on whatever is the current hype without bothering to weigh up whether it’s worth it. This is a key contributory factor to the utter absurdity that is the hype curve where we all get far too optimistic about a technology, jump on it and then after a few years realise it is not the holy grail. Techies as a group are supposed to be some of the most rational, analytical of all and yet we make this newbie mistake – who are we kidding?

Short-term thinking can be seen elsewhere too such as in the feature’s versus refactoring/re-structuring discussions that go on in software product (shrink-wrap, web or otherwise) companies across the world. In general it seems that businesses encourage these minimal thought policies. Increase customers now. Increase revenue now. Don’t worry about consequences we’ll deal with those later………maybe!

But wait a minute – if a child wants to stick their fingers in the wall-socket should we just forget the consequences and let them do it? Clearly not – that’s strategic, big picture thinking which saved our child some pain. Why don’t we do similar things and save our businesses, systems and workers pain?

I do wonder if rampant short-termism is somewhat related to our own survival instincts. Perhaps when there’s too much pressure/threat we are more likely to stop thinking about the big picture? Understandable when it’s life or death but surely unnecessary in business, tech or the daily commute?

Technorati Tags: business, strategy, technology

I see many a comment talking about concerns with roundtrips in SOA/distributed architectures. For example in “The Fractal Nature of Web Services” the author starts totalling up additional round trips taken once we disassemble what was a single app into separate remote services. He then goes on to walk down the well worn performance path expressing concern about performance etc.

His concern is certainly valid but it makes a fundamental assumption about how you implement your services:

Each service is represented by some stub that communicates via some protocol to some remote back-end. Clients access the service via the stub and thus incur remote call costs.

Further whether he meant it or not, the author gives the impression that SOA can only be done with Web Services which is absolutely not true. Your choice of method for implementation for SOA is determined by your chosen architectural constraints and can often (and maybe, should always) lead to a hybrid model with “public” interfaces exposed via WS-* or REST and others implemented in Java.

And this is where it gets interesting because with Java we can break the stub/remote back-end constraint. Why? Because we have code-downloading. We can construct a service implementation that offers an interface and is advertised in a service registry as usual but at the point of access, downloads it’s whole self to the client. The service then runs in the client’s address space.

i.e. We have what appears to be a remote service with none of the roundtrip costs because in fact it runs locally.

From a practical perspective that means we can do things like:

1. Create a service that wraps a database and contains all the SQL etc
2. Advertise that service
3. Client downloads service and all it’s dependent code and configuration
4. Client invokes on service
5. SQL connection is made to database
6. Queries are run against database

Now, were the service genuinely remote we would incur two roundtrips:

1. Client to Service
2. Service to Database

But because we can “inject” the service into the client we actually only have the roundtrip to the database. Things to note:

• We keep all the benefits of late binding of services and clients at runtime.
• We taught the client a new protocol on the fly – we downloaded all the client/database communication code at runtime as part of service lookup.

Technorati Tags: distributed systems, Java, soa