Showing posts with label failure. Show all posts
Showing posts with label failure. Show all posts

Monday, October 05, 2009

American Express - Which number is greater?

Sometimes you just sit there and wonder about how the code managed to get to a certain end point... take my current Amex online bill...

Now it could be the surprise that its the lowest monthly bill I've had since I got the card, but I don't quite think that "surprise" is something that should be built into a financial system. But some how the amount that I have to pay (the last bill) is now less than the minimum payment, which includes stuff for which the bill hasn't been sent yet.

Part of this is because Amex have two billing elements, the first is the date that they want you to pay by, the 2nd is when the next bill comes out. If you pay before the later then everything is fine, but they'd prefer you to do it before the former.

This is clearly a historical thing with Amex and it clearly reflects back into their core operational systems which are almost certainly batch oriented. What this also means is that like many companies out there Amex haven't really adapted their systems or processes for the web they've just lobbed the paper processes on line which delivers oddities such as this which aren't possible in a paper only world.

When people put systems on-line they often seem to forget that the interactional model for on-line working is significantly different to off-line working. If you want customers to engage more in your on-line solution and move away from the more manual and higher cost channels then it really isn't good enough to shift crap processes onto the web, you should be looking at how customers will be interacting with your company in real-time and therefore what new processes and opportunities this can bring.

I did feel like phoning up the call-centre and asking "which minimum payment should I make, the one that says minimum payment or the one with the lowest value" but I decided my life was too short to waste time on that.

Thursday, October 26, 2006

SOA - shoot the technologists

There are lots of statements made about SOA not being something you can buy from a vendor. I'm getting more extreme in my views... I think it isn't even something you can build. Clearly there can be technology delivered that meets an SOA, but can you actually do SOA if you are thinking about it as something that is just built?

People seem to be approaching SOA more and more as something that is resident in IT only, or even worse is where IT "understands" the business and builds things that are more responsive... without actually getting the business to own or define anything.

If SOA is going to actually make a difference to what is a failing industry then it needs to impact the structural problems, rather than just trying to deliver a new set of technology projects. 80%+ of IT spend is on "business as usual" aka "keeping the lights on" the support and bug fixing of current solutions, paying the maintenance licenses, patching things and generally just keeping them on life support. And then with the 70% or so of new projects that actually fail to deliver what was expected this means...

This means that around 6% of IT spend actually delivers new value to the business. This is fundamentally broken. Therefore if SOA is going to succeed it needs to help more projects succeed, and more importantly either reduce the 80% spend or help deliver more value for that 80%. This means that SOA truly has to be about how you govern and deliver IT, including how you continually deliver IT to the business once it has gone live.

This is why I'd argue that SOA isn't even something that gets built, its something that becomes a part of your culture, it changes all aspects of your IT organisation. Otherwise it really just will be yet another techy idea that delivers little or no value down the line.

IT is a broken industry, it takes more than an ESB, some Web Services and changing some design guidelines to fix a problem this large.

Technorati Tags: ,