Orange say that the iPhone 4 has been recalled

Okay so I've just got off the phone from Orange on the non-delivery of my iPhone and here are the litany of excuses

1) They ran out of stock

So I pointed out that they'd accepted the order from me, given me a fixed delivery date (the order went in at 2am on the Thursday and was confirmed at 9:05am). This seemed rather bizarre that they'd run out of stock that quickly

That is when it got a lot more interesting.

Then I was told that

2) "The phones have all been recalled as they've got an antenna problem and they keep crashing"

I pushed on this just to check and it was confirmed that the reason that Orange don't have any stock is because their has been a recall due to the antenna issue. The call centre drone said that the iPhone antenna issue was one thing and also that the phones kept on crashing.

I asked why, if it was a result of a recall why they hadn't emailed me about it, the reason was that

3) Their system was so overloaded that it couldn't handle the volumes.

I pointed out that they regularly seem to spam in pretty large volumes but apparently the iPhone is much higher in volume.

There was no hint of an apology and the stock line was "7-10 days or a full refund".

So either its straight Orange incompetence with a rubbish excuse or there are some major league iPhone 4 issues.

Location Centric packages - don't buy a 1990s package

One of the big problems with package solutions is that they are very database centric. Changing the data model is basically suicide for a programme. Adding a few new tables is dodgy but sometimes required and adding columns is reasonably okay but modifying the core data model is always going to get you in hot water.

One area that I've seen consistently as a problem over the years though is down to how the package vendors have thought about physical and electronic addresses. When the packages were created there were really only one set of important addresses, physical addresses. Phone numbers were pretty much fixed to those premises and email was a million miles away from the mind. This means that the data models tend to look at electronic addresses as very much second class citizens, normally as some form of child table rather than as a core entity.

The trouble is that as packages are being updated I'm seeing this same mistake being made again with some of the new technology models being used by vendors (AIA from Oracle appears to make the mistake). The reality is that the model is pretty simple

That really is it. There are two key points here

1. Treat all actors as a single root type (Party) then hang other types off that one
2. Do the same for Locations

The reason for doing this is pretty obvious. These days mobile phone numbers and email addresses are much better communication tools than physical addresses. As you want to send e-statements, e-invoices, and other elements to customers like SMS delivery notices, then you want to be able to channel shift customers much more simply. If a customer switches their delivery address for a book to an email then that is fine as long as you can ship them an e-book.

Now I know that anyone from an OO background is going to go "well duh!" but it does amaze me how in package land the database centric mindset still dominates and people just don't seem to want to revisit the assumptions they made in the 1990s when their hacks to put in electronic addresses seemed like a safe bet, after all email and the internet weren't considered as future strategies.

Its now well into the 21st century and I'd really advise people buying packages to look long and hard at the data model and ask yourself "is this a 1990s view of business or a 21st Century view" if its the former then be aware that you will have pain.

Technorati Tags: SOA, Service Architecture

Tin-huggers the big problem for cloud adoption

Going through yet another one of those "holy crap that infrastructure is expensive" occasions recently I did a quick calculation and found that we could get all of our capacity at an absolute fraction of the internal price. Think less than 1/10th of the quoted price when installation was factored in.

What stopped us shifting? Well a little bit of compliance, which we might have overcome, but the big stopper were the tin-huggers.

Tin-huggers are people who live by the old adage "I don't understand the software, I don't understand the hardware but I can see the flashing lights" which I've commented on before.

Tin-huggers love their tin, they love the network switches, they love the CPU counts and worrying about "shared", "dedicated", "virtualised" and all of those things. They love having to manually upgrade memory and having to select storage months or years in advance. Above all of these things they love the idea that there is a corner of some data centre that they could take their tin-hugging mates into and point and say "that is my stuff".

Tin-huggers hate clouds because they don't know where the data centre is and their tin-hugger mates would laugh at them and say "HA! Google/Amazon/Microsoft/etc own that tin, you've just got some software". This makes the tin-hugger sad and so the tin-hugger will do anything they can to avoid the cloud. This means they'll play the FUDmeister card to the max and in this they have a real card to play...

Tin-huggers are the only ones who work in hardware infrastructure design, software people couldn't give a stuff.

This means its all tin-huggers making the infrastructure decisions, so guess what? Cloud is out.

Tin-huggers are yet another retarding force on IT. Sometimes the software folks can get it out and work with the business but too often the TIn-hugging FUDmeistering is enough to scare the business back into its box.

Its time to build a nice traditional bypass right through the tin and into the cloud and let the tin-huggers protest from their racks as we demolish them from underneath their feet.

Technorati Tags: SOA, Service Architecture

REST has put enterprise IT back five years, Sun has put it back ten

Okay I've watched REST, Clojure and the other shiny new things rise up and for the last 9 months I've been back in the bowels of large, lets just say massive, scale enterprise IT delivery and I've come to a conclusion.

IT is in a worse place now than it was 5 years ago. The "thinkers" in IT are picking up the shiny new tools and shiny new things and yet again continuing to miss the point of what makes enterprise IT better. There are a few key points that need to be remembered.

1. Art v Engineering is still the big problem - 90%+ of people in IT aren't brilliant, a large proportion aren't even good
2. Contracts really matter - without them everything becomes tightly bound no matter what people claim about "dynamism"
3. No technology has ever, or will ever, deliver a magnitude increase in performance
4. The hardest part of IT is integrating systems and service not integrating people. People are good at context shifting and vagueness, good interfaces are fantastic optimisers but even average user interfaces can be worked around by users.

The likes of Clojure and REST haven't improved this situation in the enterprise in any marked way. Its been 5+ years since REST started being hyped and in comparison with the benefits that WS-* delivered to the enterprise in 5 years its been zip, zero, nada. The "dynamic" languages piece that kicked off about the same time has delivered similar benefits to large scale enterprise computing (you know the stuff that keeps most people in IT in a job) over the "old school" Java approach.

A few years ago I said that if you wanted a career then learn Web Services, if you want to be cool learn REST. Since then its become clear that some people have made careers in REST... but you know what?

1. Its as hard to do a large scale programme with a large integration bent as it was 5 years ago.
2. There are less really good enterprise qualified developers as they've got "dynamic" language experience and struggle, or worse bring the dynamic language in and everyone else struggles
3. Vendors have been left to their own devices which has meant less innovation, less challenge and higher costs as the Open Source crowd waste time on pet projects that aren't going to dent enterprise budgets

In 5 years from 1998-2003 Java and Web Services went from near-zero to being everywhere, innovation was being done at the edges and then being applied to the enterprise. It was a melting pot and it improved enterprise IT, thanks in part to the smart people working at the edge and the way this pushed the vendors forwards...

Well now SAP, Oracle and IBM are still heavily backing Web Services but there is a big problem....

No one is holding them to account. With all of the cool, and smart, kids off playing with REST and Clojure and the like we've got an intellectual vacuum in enterprise IT that is being "filled" by the vendors in the only way that vendors know how. Namely by increasing the amount of proprietary extensions and software and pushing their own individual agendas.

So we get the bizarre world in which Siebel's Web Service stack has a pre-OASIS specification of WS-Security, last updated in 2006 by the looks of it. We get a world where IBM is still pushing the old MQSI cart horse as an "Advanced ESB" and generally the innovation in this space has just collapsed in the last few years. Working on a programme doing integration which uses Web Services in 2010 feels pretty much like 2005, sure some specifications have come out and there is some improvement but overall its pretty stagnant.

"Oh do REST then" I hear the snake-oil salesmen cry. Really? If you had to do an integration between 20 different programmes and over 300 systems in a heavily regulated area then you'd use REST? High value assured transactions between different vendors and providers over a "dynamic" interface?

Give me a break.

What works in these areas is what has always worked

1. Define your interfaces, nail them down, get them right
2. Test like a bastard to those interfaces

You can't do complex programmes without having those firm areas, this is why major engineering programmes don't have variable interfaces for screws. Now before someone pipes up with a nice edge case where 200 people did something complex then please do that 20 times in a single organisation and give me a call.

In 2006 I asked why there was no WS-Contract and the real reason was that it wasn't a good vendor specification (WS-TX is that) but its a brilliant enterprise specification. So WS just had Security and Reliability, important things for the enterprise, but didn't make then next step.

And what has REST given us in the last few years? Errr please, folks... Now in my current engagement there was a great area where REST would have been very useful (Reference Data) and some where it would have been quite useful (Federated Data Network Navigation). The problem is two fold

1. Most people in IT appear to know bugger all about it. Now I continue to be surprised at how little people who work in IT read about what is going on, but I was really surprised at how little traction REST had.
2. EVERYTHING is manual and there is still no standardised way to communicate on WTF you are doing between teams

Now if you had 2 then you can do 1. I did this with WS back in 2000-1 when most people thought I was just making up this WS stuff I could run between the data centres over port 443, I had interfaces, they had tools, we got it working.

Now before RESTafarians jump up and talk about all of the wonderful WEB things they've been doing. That is great and wonderful, but its not my world, my world is having 300 systems that vary from 20+ years old to just being built and I need to get them all working together. Even when REST was the right "architectural" solution it was the wrong "programme" solution as it would have driven us off a cliff. My world does have stratospherically large budgets however... you know what, if you want to make real cash wouldn't it be a good idea to address the richest part of the IT market?

But my real ire I reserve for a company I used to really respect but which, at the same time as REST began to get a load of buzz, drove a huge amount of enterprise IT off a cliff. When Java SE 6 was released I said it wasn't enterprise grade and indeed very rapidly the stupidity of the decision to push JAX-WS into JavaSE became apparent (yes please note I was massively against WS-* in JavaSE, partly because if someone wants to be a RESTafarian why the hell should they have to have WS-* cruft in their environment?). This was also the release that added in scripting to Java SE.

I'm now seeing 4 years later the impact of this stupidity on the enterprise. Java SE 6 is dribbling in under the application servers but the mentality that it represented, namely that Sun was more interested in "Joe Sixpack" and the cool crowd than the enterprise really helped to ensure that it was left to the vendors to undertake the enterprise side and Java began to stop being the innovative platform or language. The bits that the enterprise wanted, things like profiles and dynamic loading, were deferred into Java SE 7, which is now (by my reckoning) 2 years over due.

Sun championed the new "cool" languages and undermined the whole thing which made Java good for the enterprise, consistency. Having lots of different languages is rubbish in the enterprise, having the same basic platform from 4 different vendors is much much better on every level. So now we have people proposing doing programmes with 4 or 5 different languages and its being seen as "reasonable", we are also seeing some great developers doing some interesting things on platforms that will never bring benefits.... I can't help but wonder whether Spring or Hibernate would ever have delivered any benefit if it wasn't for the fact that they operated on the common platform... oh wait I don't have to wonder, they wouldn't have been anywhere near as successful.

So the last 5 years have been poor ones for enterprise IT. WS-* is the only viable system to system integration mechanism for large scale programmes, but its stagnating. REST has some cool stuff at the front end and for people who can invest in only the very highest calibre individuals but is delivering bugger all for the average enterprise environment.

Why is this a problem?

Well most of the modern world is driven by computers, computers are what makes economies tick and its integration that matters in a networked world. The immature and techno-centric way in which IT approaches enterprise solutions is ensuring that far from being an accelerator that works ahead of business demand it is IT that is all to often the dragging anchor to growth. This obsession with purist solutions that solve problems that don't exist are just exercises in intellectual masturbation which are actively harming developed economies.

Far too much shiny, shiny, far too little getting hands dirty with pragmatic realities.

So maybe I'll come out of this funk and people will point to the wonderful things that are massive improvements over the past 5 years and how some of the biggest enterprise IT challenges in the world are being solved by people in application support thanks to these new developments.....

But I won't hold my breath

Technorati Tags: SOA, Service Architecture

Business SOA and package delivery

I've been rather quiet this year, mainly due to being full out on a rather large programme delivery effort. Package and Data (MDM) rather than my normal SOA work but still very much around the Business SOA approach, and more in future on how to do Business SOA for a package and have a really strong governance approach to ensuring a successful package delivery.

But I thought I'd give a brief over view here.

1. Detail the Business Services - including the "nearby" Business Services that aren't in your scope - this tells people at a high level what you are, and aren't, doing
2. Create a "Business Catalogue" that details the fine detailed capabilities that the programme will be delivering.
3. Map the catalogue to the Out of the Box (OOTB) functionalities in the package
4. Create a strong governance approach around managing changes to the catalogue
5. Document the capabilities using use cases. This gives you the explicit definition of scope that you need the enterprise to accept. These use cases are documented based on the OOTB what the package does, rather than being requirement gathering exercises

That is the high-level view and there will be more to come

Technorati Tags: SOA, Service Architecture