SOA, SOAP, RMI, TLA, FLA and Horses

Picking that horse. I'm not a betting man at all, never been trackside, but some describe technology like betting a horse.
Do your homework and choose, then hope it wins, maybe needing a good relationship with your bookie (I am not sure who the bookie is in this analogy).

My own take is technology far much more than betting, (and the punters would say the same about horses).
But in fairness, some people get burnt, myself included, when then chose the wrong horse.

So taking some pages from anyones book, do your research, and, if your're
at the other end when the horse is scrapped, don't give up and move on.

My point is, a technology, platform can be chosen which ensures you don't have to worry, too much, about what is going to
come up against if you follow a few simple guide lines.

Ramon's Tech Tip #1 - Horses will be scrapped

What do you do when the horse you backed is scrapped ? Same as you do in business, learn from it.
It may have been the best horse when you started, and sure, it got you to now.

Ramon's Tech Tip #2 - Choose the Horse, Jockey, Race History and the Silks

You trusted your instinct and your fellow peers, but something went wrong.

The way I apprach a choice area is to talk to people who would agree with me, easy. I also
get opinions from people who I know won't like it, two outcomes come from that approach, (1) I will learn something, like that
they are definitely wrong and I am right, or that they actually have a valid point. (2) They show I am wrong and in fact they
do like it anyway.

The other approach I do is to research the other technology camps to find out where they are heading. In this I mean .NET, LAMP, Java,
bright people with bright ideas working in another language, what do they see the future in X area to be ?

Silks ? Well, go with what you like, at the end of the day you will have to be the decider.

Ramon's Tech Tip #3 - Think of the future bets

All good and well when you have to decide for a short term item (1 - 2 years), but what about choosing a
direction when you yourself won't even be looking after it.

A well guided decision that will impact others beyond you must be well thought out and planned. Don't rush into
any decision lightly (Sub tip #3a). I have recently been involved in the decision making process that will see a platform
being used well into the next 3 - 4 years. I can be good and say I will be around in that time, most likely I will, but what if I am not?
I need to be considerate of the fact that the choices we make now, take us that far into the future, expecting that things will change.

Ramon's Tech Tip #4 - Follow the Jockey

If you don't get too friendly and passionate about Mega-Deployed Platform AlphaX, you will be happy to change to Simple-Deployed Platform AlphaX
when you need to. My tip here, make the choices such that each component is not interdependent on another, don't couple things so tightly
that it means cutting off when all you wanted to do was change cars

Ramon's Tech Tip #5 - Horses fall over

Expect it to change. In all our dealings with IT, the one thing that is guaranteed is that something will change.
Be it that it will become obsoleted or improved.

I have just been involved in a project where the first cut of our product was available for no more than 9 months
and then we saw a radical change in how it should be offered to clients.
One key component to the easing of this transition is that it was well engineered from the onset to cope with the change.
So the best way to describe this is, write it so it can be changed, but write it to last. Loosely coupled.

in the .NET land I have seen comments that interfaces should be removed, but in the land of dependency injection. Interfaces
are king. Sure interfaces may change and need to be redrawn but so will a tightly coupled system. I can tell you
that IoC Frameworks are becoming King, and, bottom line, they save money. and I don't mean small cost cutting here
and there. I mean in the order of weeks of work for teams of developers. Relating to $1k's to $10k's for large projects.
Prove me in this and I'll be quiet, but they really work and are not just some Astronaut engineering Oxygenless fad.

Ramon's Tech Tip #6 - Don't sweat when you lose

Let's face it, and that's it, you will have to face it one time or another.
Horses collapse, decisions made may die. It may not have been a bad horse, it may not have been a mistake.
It could have been due to external factors such as another horse on the track destroying yours, or a big comet
taking out the whole race.
In any case, accept it and move on. The person that hangs on to the, "oh but it was good" and doesn't learn from it
doesn't learn. Sometimes things were good and there are hard factors that caused them to fail, such as humans.
So .. learn from it, analyse what you did wrong and choose another horse.

Ramon's Tech Tip #7 - You're betting for someone else

I once had a colleague that, when I asked him what he wanted to be doing in 3 - 5 years time, said, "I don't want to be doing the 'next IT project' which just involves another set of requirements and tasks". He wanted to get out.
Now sure, that's valid, and he probably needed to move on. My take on IT and the next project similar to the last
is that I am pleasing a client. The client is always right, and IT forgets that. Sadly there has been this thing that the techy dude,
sys admin, software engineer, whoever, knows better than business person X because they know something. Knowledge is king, sharing it with someone else and letting them make a decision is power to the king.

It's always said, and often in retail. The client is always right. Well that is also so true in IT. IT department, make the client the person that pays your wage. Software guys, the client is the one who is funding the project.

IT from it's onset has always been around to "solve" a problem, make a buck, help someone do task X. The key thread in all these is that there is a client, and there is the problem they want solved.
They are the ones that will dictate what needs to be done, how much to spend and the cut off point at
which foobar-option-ABC is implemented using pure methodology Reverse Vegemite Toast.