How much would you pay for a process?

I've been looking at some SaaS solutions recently some have been niche vertical elements, others have been more "traditional" ERP type solutions that are delivered over the web, like Salesforce.com and Oracle OnDemand and it got me to thinking on some conversations I had with a chap called Paul Luckett. Namely if you have an infrastructure that can execute processes and you have some form of semantic mapping of your data to the format that the process requires then why would you not just by processes rather than applications?

The next logical step is then to not have the infrastructure but to "rent" processes based on how much you actually use them. Now for certain areas the argument can be made that there is too much competitive advantage for SaaS to really take off, but for lots of current ERP areas, such as Finance and HR, is there really so much value in customising things like employee onboarding, training approval, invoice creation or accounting? The answer is pretty much always "no" when it comes to putting in an ERP so why, if you have a middleware with the characteristics above wouldn't you just "buy" the process from someone who has formalised and optimised it already.

If however it is one of these commodity things that really don't add value would you really want to pay money to operate it yourself? Wouldn't you prefer to consider it as a utility in the same way as people have outsourced payrolls and telephones? I'd argue for a strong "yes" on that, and I'd even go a stage further. If you have an extremely common process, say creating an invoice, why wouldn't you actually just 100% standardise that via something like OASIS (like an ebXML that is light enough to work) and then have companies compete to be the most reliable hosting for that process.

I'm talking here about the back-end processes where ERPs currently dominate the market. But with the rise of SaaS, Semantic Web and process standards is their really a future for building your own HR, CRM or Finance solution? Isn't Oracle's OnDemand exactly the way the world needs to go?

So what is an invoice worth? 1 cent a time? 2 cents? its not going to be much. The commoditisation will rise up another level and more processes will be put into packages, but I think its reasonable to expect that in 5 years time you'll see the majority of new back-end processes being either downloaded and run or just rented. This gives whole new challenges around data security and retention to be solved but it does sort of argue that the vertical solution direction that SAP and Oracle are taking is the right one and that the new "cheap" ERPs on the block might be arriving after the bus has left.

Technorati Tags: SOA, ERP,SaaS

Google, Sky+ and targetted adverts

N.B I have no inside information it just makes sense
Note for non-brits: Sky+ is a Personal Video Recorder linked to the main satellite TV supplier in the UK, Sky which is owned in part by News International... who own Fox and the Sun

Thanks to the Mrs we've now got Sky+ and a wonderful thing it is as well. What is odd about it though is that there is 80Gb taken up by Sky for whatever they want, leaving me with 80Gb left to record programmes. Given we haven't actually recorded a TV programme in about 3 years this isn't a big issue, although we have recorded 8 in the first week of Sky+, but it got me thinking about what Sky could do with that space.

Then I saw the Google tie up and I suddenly though. What would I do if I had over 40 hours of available space on a hard-drive? Sure I'd use some of it to start pumping Video on Demand at people but I'd also be looking at ways to increase the effectiveness of advertising spend.

What I'd look to do would be pay a premium to advertisers to have their adverts pre-loaded onto the boxes, these adverts would then be played at targeted users based on both their current viewing and what Sky/Google knows about them. So you watch football, golf and Oz Clarke, you get the adverts for a Spanish Wine/Football/Golf holiday. You are watching Big Brother and Sky know you already have a mobile, well today's programme isn't sponsored by Carphone Warehouse, its sponsored by Direct Line insurance because your car policy is up for renewal. Watching lots of ITV? Then here comes the debt consolidation advert just for you.

One of the big challenges of TV advertising is this problem of advertisements being broadcast like a sawn off shotgun at long range at viewers with a hope that someone will get hit. Having even 5 hours of 30 second adverts (600 adverts) would be a very powerful proposition for companies because unlike the broadcast adverts they could apply on every channel so when you skip channels you would still see the same adverts because after all its the box that controls what you watch. Sky have a big advantage here over someone like TiVo in that everyone knows that Sky is the company that makes the box and Sky is the company that controls the box and that you pay all the money to Sky to watch the TV. This gives them a high degree of control that isn't quite so available right now in the US market.

So what would it take to build such a solution? Well firstly you need the content on the disk, this is trivial you just have a trickle feed on the 2nd tuner (Sky+ has two tuners) that builds up the adverts, which are after all pretty smart, and then you need a set of smart user to advert matching technology, step in Google which needs some information about the user, hello Sky.

I'm really struggling to see what would stop Sky rolling this out on all of their own channels (clearly ITV would be upset if they did it across all the channels) and what the major technical challenges would be.

Maybe this is the way that TV adverts survive, they stop being broadcast and start being "served" from the PVR and you watch them because they are something that you want to see. Its a little bit scary but it would seem to make a hell of a lot of financial sense. Hell using a bit of fancy streaming they could really personalise it so the advert would say "Steve, get off your fat arse and get down to Globo Gym today".

Targeted adverts in a real-time or recorded broadcast stream using adverts served from a hard-disk. Bagsy on the patent.

Technorati Tags: Google, Sky, Tivo

Budget to Live v Total Cost of Ownership - BTL v TCO

One of the things that never ceases to amaze me in IT organisations is the way they treat support so differently from projects. Often these two pieces are contained in completely different parts of the organisation with different objectives and measures, unbelievably often the architects and project managers from the "build" side don't have to know anything about the existing systems, or indeed the impact of project issues on that existing IT estate.

It also creates one of the most dangerous things in IT from a cost perspective namely the focus on "Budget to Live"(BTL) rather than Total Cost of Ownership (TCO). What I mean by BTL is that a project has a budget to spend to get the project live and that is what they will spend to go live, thus demonstrating how clever they are and why they should all get paid more money.

And time after time I see the following behaviours

• Testing cut short to "get it out the door"
• Testing only positive scenarios
• Taking coding short-cuts that "are a bit messy but its quicker"
• Allowing "code first" design (and I don't mean TDD)
• Excluding existing systems from question of "how to build this"
• Deliberately hiding problems
• Claiming "live" going to the pub and saying "its a support problem now"
• "It was fine when I left it"

This is often exacerbated by the "architects" within these companies who practically aim to be ignorant of the challenges of actually deploying and managing a solution. Thus the architects are there for the first few months and then leave it to the lowly designers and implementers, and when it goes wrong.... well it isn't their fault the architecture was fine, and of course those massive maintenance issues for this "optimal" architecture are down to the lack of sophistication in support.

All of this means that projects store up a whole load of hidden costs that are only realised after the project goes live. In many organisations there is a "hand-over" between the two groups and no cross fertilisation of resources, so operations doesn't get to be involved in the project to point out the issues they just have to deal with the problems. The problem is that the project will be seen as successful, whereas the support will be seen as expensive. The project will take the plaudits and operations will carry the can, this isn't an effective way of delivering a decent IT organisation.

So what I'd recommend is that architects be made to learn the existing estate and be measured on the total cost of ownership for their area, their bonus should come from them delivering on the promises that they made at the start of the project. A project managers bonus should be split 20% go live and 80% 12 month TCO to make sure they focus on the bigger picture. Most importantly of all however the accountants should recognise where cost should be assigned, namely against the project budget that created the mess. By making these changes an organisation can start to think in terms of TCO not BTL.

If you aren't considering support in the same breath as new spend then the odds are you are doing BTL, and your IT is much more expensive in total than it should be.

Technorati Tags: SOA, Service Architecture

Have Microsoft got serious about Enterprise Software?

Reading over on infoq I came across this interesting article about one of the most senior, if not the most senior, person from IBM Software leaving to join Microsoft. Don Ferguson is pretty central to lots of things that IBM have done and is extremely important in the overall picture at IBM. From his old IBM blog

Don chairs the SWG Architecture Board, which oversees the architecture and integration of WebSphere, DB2, Lotus, Tivoli and Rational products. Don was the original Chief Architect for the WebSphere family of products.

Which sort of scopes out the sort of calibre that Microsoft have got themselves here. I've been concerned in the last few years that Microsoft just don't appear to be focused on the enterprise market. It was clearly going to take a pretty heavy hitter to move them forwards and most importantly give them the clarity they need to build a full enterprise ready stack of products.

With Longhorn Server and the revision of most of the enterprise stack that it requires being scheduled (according to rumour) for next year this gives Don only a short time to implement the complete overhaul of how they work. As a champion of SCA at IBM it will be interesting how ideas like that are either used, or replicated, in side of Microsoft. It will be interesting how much of the current Vista and .NET 3.0 pieces make it into the enterprise stack or whether Don will decide that something better is required.

From the post I referenced above I said that Microsoft need to Buy BEA, or get a vision for SOA that allows the enterprise to evolve at a different pace to the operating system. at least now they've hired someone with a good track record in proper enterprise software. Maybe there might be competition from Redmond after all.

Technorati Tags: SOA, Service Architecture

IT fundamentalism - The Technology Delusion

I've been reading The God Delusion recently with its rather nicely argued points about theism, deism, atheism and the like. Reading it made me think however about how a clearly designed environment, like IT, operates and while reading some of the chapters around monotheism it became clear.

IT loves to proclaim the "one" truth of IT and burn at the stake all those who do not agree. It is a professional of many fundamentalist preachers who preach "the one true way" of IT and proclaim that all others are damned. It is a professional of followers of those preachers who deride others for "not understanding the truth" rather than seeing that maybe there is another side that they don't know about. Now clearly I'm open to this charge around SOA, I pretty much think that viewing businesses as services is the only practical way I've seen so far that works and right now I'm preaching that gospel.

And here comes the other bit, we may proclaim to be fixed to "the one true IT god" but we will switch as easily as pie to the next "god" that comes along. Sometimes this is in the guise of a powerful preachers (e.g. Microsoft) who convince the followers that all that had been said before (e.g. VMs are slow and not the way to go) is true and that all that is said now (e.g. VMs are the way forward and the only way to work) is true and sure enough the gullible followers develop with this religion and rarely look for solutions outside of their creed.

Consistent in all of these beliefs is that all problems are, at their route, an IT problem that needs an IT solution. Thus the battle will rage on WS v REST and Java v .NET, Spring v J2EE, ESB v ESB, BPEL v BPMN, lazy loading v pre-fetching, OO v procedural, Netbeans v Eclipse and for all of these there will be people who take, in effect, religious convictions as to the "right" of their side in being the one true way to solve the problem.

The history of IT fundamentalism has taught us that one answer has pretty much never been the sole right answer that will be true for all ages and that just as the religion of EAI has pretty much died so the religion of ERP is liable to falter in the coming years. The history of IT fundamentalism has also taught of its immense dangers to projects and even businesses, the .com bust is a great example. WS and REST will be looked back on as a footnote in the debate and we will all have moved onto a new religion with new fundamentalist preachers proclaiming its truth.

Maybe however we should look to what has caused these IT debates and what is driving these changes. The answer, in reality, is that the big changes have not been made from the fundamentalist preachers of IT they have been made by people who saw a problem that needed fixing and provided a solution that hadn't existed before this means that they key to IT is not the solution that drives but in fact it is the problem which is important, and each generation has new problems that are now required to be solved.

The Church-Turing Thesis sums up this dilemma that in fact all current problems are reducible to previously solved problems or by definition is unsolvable. This means that the only question is on the efficiency of the latest IT cult rather than on it being genuinely different. This presents the IT preachers and their followers with a problem, how to push their new cult when in reality it is going to be short lived and is in fact just a different view on the same old problems. The answer is of course denial and fixation. We hear, most often from the followers rather than the preachers, that those who do not follow the true path are doomed to failure and (a common refrain) "do not get it". The failure to accept this new religion is placed straight at the doors of the non-converts.

Just like with religion this places the burden of proof in the wrong direction. If you are saying your new "miracle" truly is the Silver Bullet we've all been looking for then it is your responsibility to educate and accept the challenge. It is not enough to claim that "you don't get it" for as Albert Einstein said "If you can't explain it simply, you don't understand it well enough".

The reality of IT however is that these religious fads are, like religions in the real world, just things that give us false comfort about the real underlying problems and challenges that we face. It is better to have a religious rod of conviction that "REST" or "Agile" or "SOA" or "Web Services" or "PHP" or ".NET" etc etc is the best way rather than having to actually sit back and think that maybe it might be better to use something different on this problem because it is different to the previous problem. The current approach of "The answer is X, now what is the problem" and then blaming the problem is just plain madness.

The only rational position in IT is to be a political agnostic, that is you should accept that different IT religions are required in different areas and you should be skeptical about new religions that come along. When you find something that works for a given set of problems you should believe in it, but you should do so in the knowledge that something else might come along. Fundamentalism should have no place in IT, nor should the "believers" seek to condemn the heretics who dare to question their preacher or "bible". The political agnostic is one who chooses to believe for a period of time because right now that belief works for them, you could also refer to them as the slutty polytheist if you are of the fundamentalist monotheist persuasion.

One size doesn't fit all, one solution will not be the answer to all problems and there sure as hell isn't a Silver Bullet. Its fine to have certain beliefs on things that help but these should be backed up by data and should accept that these may not be true in all circumstances. Beneath it all should be the recognition that the true challenge is not what is the "one" IT solution, but what is the current problem you have and what is best suited to solve that problem. The problem is that the preaching of reason never generates the same degree of noise as that generated by the truly fanatical. So the messages that are heard in volume are not those of reason, debate and discussion but rants about technologies and the continual almost maniacal obsession with "the developer".

IT fundamentalism is a reaction to the fact that most IT challenges are created outside of new IT projects whether by customers, business, markets or the existing estate. It is a reaction to those who aren't assured in what they are doing and need some technology deity to cling to., IT fundamentalism dictates a "technology truth" as above everything as it is just too scary to admit that IT not only doesn't have all the answers but...

IT rarely even asks the important questions.

Technorati Tags: IT

Why Sales isn't process driven

One of the statements I've made on a semi-regular basis is that the concept of business process being the most important thing in a business is a myth. The other day this was brought home to me perfectly when I was looking at packaged solutions and particularly pieces around the "sales process".

Now I'm not going to say that there is no such thing within an organisation as a sales process, of course there is, but what I'm saying is that this isn't actually the important factor when looking at the success or failure of a sales organisation. Having a process that says "Stage 3 - Agreed issue with client" and "Stage 9 - Contract Signed" isn't the thing that actually drives successful sales.

No its sales people, sales targets, bonuses and most importantly goal driven behaviour that is the important factor in sales. Understanding what the goals are is much more important that understanding what the process is, different people will have massively different approaches to the selling process and while they will move from one step to another and this will give you the ability to measure and audit their performance it will not give you the ability to help focus or improve it.

Its an old truism that KPIs drive behaviour and its massively the case in sales, it is therefore, when modelling the architecture, more important to consider these KPIs and the underlying business goals than to worry about the audit process that will allow elements to be measured. This is a great example of where the business value and importance is assessed via the KPIs and Goals, but is measured by the implementation of a process.

This is one of the critical things to remember when creating an SOA, understand that the mechanism for the implementation and measurement of a service can be different to the mechanism for defining the external drivers and business critical value of the service. In some cases process might be both of these elements, in some it will be none but do not fall into the trap that because the measurement is by process that this is actually the thing that drives the business behaviour and value.

In fact I'd say that for most Services the concept of "Goals" will be more useful than the concept of "Process".

Technorati Tags: SOA, BPM, Service Architecture