In a recession its even more about the services

Anne Thomas Manes has obviously taken a decent course in headline writing with her recent post SOA is dead long live services where she says that SOA has been killed by the economic downturn, but that this is a good thing as it means we can concentrate on the services.

Reading between the lines of what Anne writes I think I'd say that her statement is that vendors are moving away from SOA as they've flogged you enough stuff and now they want to flog you its offspring: mashups, BPM, SaaS, Cloud Computing. Now in another headline writing award winner Andy Mulholland wrote Innovation is Dead, long live cost cutting which acts as a cautionary tale to those who are hearing vendors claiming that BPM/mashups/SaaS/Cloud will magically reduce costs and solve all ills. The reality is that it is in fact the services that matter more at this stage than at any other.

This doesn't mean that SOA is dead, it means that the marketing fury of T-SOA has moved on as their just aren't that many more ESBs and Web Service tools that you can be sold. What remains is in fact what SOA was all along its Services are the starting point for SOA its not those pretty technologies. I've argued before that Web 2.0 requires SOA so building on the Anne and Andy posts I'd say that simply put.

If you adopt the new technologies without having a services mentality then you will create a degree of mess that will make the one that consultants and vendors got fat on with EAI look like a trivial problem. Doing Spaghetti inside your firewall in big applications is one thing, doing it over the internet and with thousands of small ones is a completely different scale of problem.

So in a recession you need to Identify your services, understand the business value that they deliver, understand the cost model to deliver that value and then decide on the right technology approach.

If that isn't SOA then I don't know what is. So in reality its the "other" SOA that is dead, not the SOA of today.

Technorati Tags: SOA, Service Architecture

Clouds and micro-climates

A shout to Tim Kelly who before Christmas came up with the term "Micro-climate" to describe the clouds that companies and industry verticals will build for themselves when using a generic cloud (ala Amazon, Google, Azure) won't do for security, regulatory, money or paranoia reasons.

Cloud computing won't be just about who is the big generic cloud, it will be about how do you create clouds for the pharma, defence, government and other industries. These are the micro-climates.

Technorati Tags: SOA, Service Architecture

SOA resiliance and the power of virtual machines

One of the things that continues to amaze me when I look at companies Disaster Recovery policies is how much they concentrate on the Backup and how little they concentrate on the restore. Chatting to a CIO in the manufacturing industry a while back he gave me a great stat on his business

For every minute that we are down it costs 200k euros a minute, my DR plan takes two days, that is why I have three redundant data centres and a full set of passive backups.

Simply put this chap couldn't let his systems go down so he invested very heavily in making sure that they didn't.

More often however people just tick the "backup" box, send it off to tape and then don't worry about bringing a service backup and what that really takes.

If you've lost a disk then its a physical job followed by a data restore (you did of course test that). If the server is trashed then you have procurement, install and then recovery. If the Data Centre is trashed then you have a much bigger challenge.

This is where companies come in and charge quite a bit of money to have "warm" servers on standby. You pay for them at a certain rate (and more when you actually use them) and then have to do all the rebuild job if disaster strikes.

Now in a networked world such as SOA this is a big issue as the failure of one service can have significant knock-on effects. Now you need to design around this, but there is still the question of the quickest way to get a degraded instance of the service back.

Why degraded? Well lets say its a high demand service, you've gone stateless, you've got 20 Linux boxes running it horizontally when a muppet manages to dig up the network cable into your data centre. Its going to be 3 days to get it fixed to 100% but you need something degraded that works now.

This is where Virtual Machines really kick-in. Along side your normal data backup strategy I'd recommend taking a Virtual Machine backup of the server. Now in future the VM approach will probably be the normal one, but its got a great job right now as part of your DR solution. Take the VM backup at the same time and then if you need to just fire it up on some commodity hardware that you have lying around. Its going to perform badly so think about throttling, or fire up a virtual grid with the hardware in the office. This then gives you the space to do the full recovery and get everything up and performing at 100%. Having the VM backup means putting your patch in place as quickly as possible.

When you do this however I'd also recommend that you run, at least once a month, a full unit/system test on the VM backup to make sure that it does actually work properly.

Disaster Recovery is about planning for the recovery, not planning for backup.

Technorati Tags: SOA, Service Architecture

What to do when insanity reigns. CYA for a reason

Recently I've had one of those experiences where you just have to stand back and think "Either I'm insane or they are". Reviewing the facts its pretty clear that the insanity is on the other side. Slightly worse than that the decision that is about to be made is actually tacitly admitting that its an insane decision.

This is when you need to implement a real CYA policy. CYA is Cover Your Arse this isn't the bad old EA CYA approach, its not even about clear documentation. This is about making sure when the shit inevitably fan that people don't turn round and say "why didn't you say" but also making sure that they don't say "its your fault because you didn't support it".

So the line here on your programme is simple, you know its going to fail, you have to support it through the failure, but when it goes tits up you need to make sure that your well reasoned arguments into the clinically insane decision are well versed.

Stage 1: Store ALL the documents that went into the decision

Stage 2: Write an email saying that you respect the decision and will of course support the approach, but you feel it doesn't address some of the issues that you previously raised

When this email is ignored that is fine, the people making the decision clearly know its insane but have decided that right now insanity is a valid defense. If they reply with "We think it does address those problems" then again don't reply.

Stage 3: Write down a list of the things that are going to go horribly wrong. Get them flagged in the risk register. You don't have a risk register.... holy crap you need more help than I can ever offer, get one in a hurry

Stage 4: It now becomes the PMs job to track against the risks, if you are the PM then make sure you got Amber early, not Red as you will be "obstructive" but go Amber with your concerns. The worst thing in the world is the project that flicks from Green to Red with you saying "told you so".

Stage 5: Its going down hill, your risk report looks like the dance floor in Saturday Night Fever and people have forgotten what colour green actually is. Now is the time to start pushing "resolutions" you really want to be the person who pulls it from the fire, this will involve however Napalming lots of the people who screwed up, you do not want a problem child responsible for clean up as that just means that it will go more wrong.

Stage 6: You are responsible for clean up. The key phrase here is "Drawing a line under what happened before" this means you are going to ignore any previous decisions and base your judgement on what goes forward is what you want. Its the same line as when a failure is put in charge, the difference here is you will be firing people.

Stage 7: Remember that people screwed up against advice. Those people need to find other place to screw up, unless they are in a desperate career saving type place, then they are your perfect allies. Think of reformed smokers or born again Christians... but with a pay cheque.

Stage 8: Do an Obama. The smartest thing Obama has done so far is declare everything screwed. Don't be nice, be ruthless. If there are six months to go live but it will never happen blame it on the prior administration. Then work out what is achievable.

Stage 9: Plan to an end. Don't get caught in fire-fighting, break the current project and start a new plan for a real end game.

Stage 10: Deliver to live. There is nothing that will help you more than meeting the expectations you set in Stages 8 and 9. This makes you a rock star and this gives you the future right to say "this is wrong".

Insanity and stupidity are horrible things, but don't try and ignore them. The worst things I've ever seen are where bright people have dug stupid people out of holes without making that visible. I've seen some really dumb people in roles they couldn't handle as a result and some smart people burnt out because of it.

The Risk Log is your friend. Do your job, do your best. But this isn't the navy. Over throwing the stupid captain is fine, as long as the number back you up.

Technorati Tags: SOA, Service Architecture

User Adoption matters

One of the most annoying things in the WWW and most especially the Web 2.0 world is the Field of Dreams mentality of "build it and they will come". With package projects and business services this is the resort of two groups of people.

1. People who think the technology is the only thing
2. People who are scared of users

Sometimes people fall into both of these groups but the underlying principle is always the same. The technology is enough, its enough to "let people know" and you will then "build a community" which will make it all successful. The problem is that while there are successful internet businesses that were created in part by this approach they also had a couple of other things

1. Marketing
2. A user population the size of the internet

If you are aiming at the mass consumer market on the web then it might be enough to launch it and do some marketing, if however you are doing this internally to your organisation then quite simply it isn't enough.

So how do you drive user adoption? Well the first thing is to find out why users might not use what ever you are proposing. Be negative, get the worst things out there and then one by one mitigate those risks. To do this you've of course got to identify your users and be realistic about them. If you are doing a bug tracking system or a service for fraud analysis its highly unlikely that everyone in the company is going to use it, so set your objectives realistically and see why your user community might not switch.

Next up think about how you are going to market it to the users, yes that's right market it. Again its not enough just to lob an article on your intranet, think about how you are going to communicate what is coming before it is there. Create a comms plan and work out what you are going to tell them when. Maybe even create an internal buzz campaign to make people interested.

Next up look at how you transition users to your system gradually (if you can). If it is a green field system then this is easier as you don't have the data migration challenge. The point of a gradual migration is to start building a reputation for success that can then be used to go after the more challenging groups. If you have to go big bang then make sure it works on day 1. If this means delaying the launch a couple of weeks then try and do that because if you bugger up the launch day they'll remember for a long time, no matter how good it is a few weeks later (look at Heathrow T5 for an example of that).

Finally, and most importantly, don't stop on go-live day. Track usage and adoption and look at who is, and isn't, using the service/package/solution/etc go out and find out what has worked and then have a follow up campaign to get people more engaged. Keep doing this as a core part of the run for the system to make sure that the system is successful in 24 months time, not just 24 minutes after being turned on.

Technorati Tags: SOA, Service Architecture

If you get made redundant

As someone who has been made redundant twice (startups that didn't) and fired once (saying that a company would go bust in 12 months if it didn't change its approach, I was wrong.... it took 18 months) and who graduated during the last downturn I thought I'd give some advice to anyone who finds themselves in IT without a job in the next year, and a few things to do while you are in work to make sure you either keep your job or are better prepared for what ever comes next.

First off lets be clear, being made redundant sucks, its a crappy feeling and it will hit your self-esteem, so the first point is

It sucks, it sucks for everyone, its not just you

You are entitled to mope around for a bit, hell the first time I was made redundant was six months into my first job, my uni girlfriend dumped me and Wolves went out the FA Cup with a dreadful performance... trust me it sucked. The key point however is that you need to drag yourself and realise a few key points

1. No-one owes you a job - you have to go and get it
   
2. You will be competing for your next job - its not an end of year promotion round
3. Your skills need to be marketed

The first two are pretty obvious but its the later where I've seen people struggle. Your internal profile at your company that lists out your skills is completely different to the CV that your competitors for the job are putting in. Its not a question of lying its a question of putting it the right perspective for the job you are going for. If you are after a Java developer job then your CV needs to reek of Java, don't lob in the fact that you did VB for six months on a nightmare project as most Java guys will turn their nose up at that. If you are after an architect job and your last project was on time and budget... don't expect people to know that.

Its really worth spending time crafting your CV and making it something that markets yourself. When you review CVs how often do you look at page 2? How often do you look behind the first half of the first page (especially when reviewing electronically)? Well that is how most other people review as well.

The other piece that some people have to face up to as well is that maybe IT isn't he best area for them to be in. Lots of people have fallen into IT because there were lots of jobs and will struggle when it gets more competitive. Sometimes its worth taking advantage of redundancy to recognise that your career lies elsewhere.

Key things to do while you are at work is get your Google score for work up if you can. Nothing says "different" like being able to find relevant stuff to your job on Google and someone thinking "hey, this guy knows his stuff". I've had people say they are "world class" in a given subject but I've given the job to the person who the world actually knew about.

Another key thing to do at work is start profiling your work for your career. This doesn't mean turning down work it means thinking about how it best reflects what you want to do. If you are managing a team of offshore developers, but you want to be an architect, then make sure you are also doing the governance and oversight stuff.

If the worst does happen and you are made redundant make sure you don't dress like it at interviews, a new suit and shiny shoes (like when you went for your first graduate job) are a must at many companies.

Being made redundant can also open up new doors, I was lucky. My first taste of redundancy got me into Air Traffic Control which ended up with me meeting my wife in Paris. My second led to be working in Denmark which led to my third (getting fired) which led to a solution architect role that got me to where I am now. If I'd been in the same job since university then I wouldn't have done half the things I've done to date.

So start planning now because you aren't just planning for redundancy you are planning for your career, and its that focus that will make sure you aren't out of a job for long.

Being made redundant sucks but not having a plan for your career sucks even worse and is especially critical at a time like this.

Technorati Tags: SOA, Service Architecture