Unhandled Exception

Travel Insurance, Real Options, Cloud and VFM from IT

2010-05-27T11:25:00.006+01:00

With the recent focus on cutting IT waste in government - a thought experiment. Before going on vacation you purchase a one week travel insurance policy for £15. You go for a weekend in Paris and return without incident. Was the money spent on the policy value for money at the point of purchase ? Would your answer be different looking back if you had a wallet picked on the Paris metro and ended up claiming £50 ? Or if you were hospitalised with some exotic virus, also caught on the metro, and had your medical expenses covered ? Did you get Value for money ? Would an annual multi-trip policy that cost £100 provide more value for money if you normally make 10 trips abroad ? Would your answer be different if you ended up making just 4 last year ? When you go up to buy the policy how do you assess if you're getting a 'good deal' ? Is it the cheapest policy on the market for the same features ? Is it a better deal not to buy insurance at all ?

Bizarre as it may sound, almost all large capital expenditure decisions exhibit similar characteristics and a similar difficulty in getting non IT related decision makers to understand the real value from significant IT investments. This non-obvious value derives from the risk reduction and future flexibility that an organisation gets when they put in significant investment into IT capabilities.

Almost every IT investment proposition of reasonable size gets put through a "Value for Money" ( VFM) assessment. This is due to the combination of the increasingly large proportion of IT capital expenditure in a typical organisational budget and a recent legacy of IT silver bullets whose effects were closer to those of the projectile than the precious metal.

One major danger in making these assessments though is the over-simplification of the measures employed in objective assessment. For example, how do you choose the best option when confronted with multiple options of varying degrees of complexity and benefits. The traditional and the most common way of doing this is to evaluate IT capital expenditure as a upfront investment that will give a stream of of quantifiable benefits in the

future. This is very much an NPV/IRR approach and by far the most common in industry. The basic method involves estimating future benefit streams and adjusting them by a risk factor to take into account the uncertainty associated with the benefits as well as the time value, earlier benefits being weighted higher.

IT investment, however, is not so easily categorised in this simple model because it has value in two crucial areas that these dimensions do not measure :

- Risk Reduction.

- Flexibility in dealing with future circumstances

In both these cases, the value of the investment largely derives from investing now for either avoiding situations that MAY arise in the future or reacting to such situations. The situations themselves, of course, may not materialise at all. This however does not mean that the investment does not have any value.

I started encountering this issue about 5 years where a significant number of enterprises where considering, or at least were being seduced by SOA based investment opportunities. A typical SOA initiative proposed by an IT department involved a signficant investment in platform infrastructure in Enterprise Service Bus software, Canonical Data model and schema development, the modelling of Business Process orchestrations etc. This was expensive and proved hard to defend on anything other than a "visionary" basis since VFM assessments forced people down the hard quantifiable benefits road. The value of the investment that derives from the SOA investment making the organisation more flexible was typically not assessed

since the flexibility is only measurable in relation to a range of future possibilities that may or may not arise. For this reason, a number of Enterprises opted for small SOA-lite initiatives, nto because the lack of "vision" but mainly because they lacked the tools to assess the longer

term value of flexibility. I see similar issues these days in clients dealing in particular with investment with "Green" themes or significant investment in creating private-cloud models of infrastructure provision where a one off upfront investment buys future flexibility which is hard to value with existing tools.

How can a decision maker take this into account whilst evaluating competing proposals ? Tools such as Real-Options analysis are out there but get into advanced mathematics too quickly and lose their intuitive appeal and get too hard for the average organisation to use effectively. The other technique I've seen organisations use is to make the risk reduction and flexibility features a standard part of the requirement against which they get competiting compliant proposals and then choose the cheapest. The results, though leave no mechanism for value-add to be accurately assessed.

What else are people using to assess value from IT ?

Data Centre in a box

2006-10-18T10:30:00.000+01:00

The New York Times has this story about Sun's new offering - a datacentre in a box. Google has been doing this internally for a while anyway and it seems like a reasonable idea to try out.

The key proposition is of course how to scale quickly and I guess the appeal is obvious for large companies experiencing rapid growth. Are there enough of these to justify this as a product line ? Time will tell.

What has surprised me is the lack of emergence of the remotely hosted, massively distributed, cheap hardware based infrastructure at a large enough scale that Enterprises can simply provision capacity at will. My view is that something will emerge in this space in the next 5 years - essentially the google infrastructure for Enterprises. I am convinced there is value in it.

The problem is no one apart from Google has been able to master this at the moment and their business model does not evaluate offering their low cost/large scale computing power to Enterprises ....yet. They are moving in this direction with consumers already and it shouldn't be long before they or their competitors realise that the storage and information processing needs for most enterprises are an extension of end user needs that they currently deal with.

What Web 2.0 means for Enterprise Architecture in the next 3-5 years

2006-09-20T12:08:00.000+01:00

Since Web 2.0 has sneakily crept up on us all and replaced SOA as the instant ticket to techie street-cred, there has been a reasonable amount of thrashing around in the industry trying to come to grips with the concept. Inevitably, like most buzz words marching firmly towards term-du-jour status, there is a bit of substance and an enormous amounts of hype associated with this. The germ of substance, however, is what interests me at the moment and I will try to lay out the key implications for Enterprise Architecture in particular, of the developments in the Web 2.0 area. I'll save the highly cynical post about what exactly it is for some other time:)

I see the following Web 2.0 related opportunities that large organisations and Enterprises can take at the moment :

1. The browser as the only UI Channel.
Most large companies can drive substantial cost out of the desktop environment by adopting rich, browser based Ajax solutions. Productivity gains should be the icing on the cake.
Based on some work with some clients and a general sense of the environment, I firmly believe a large part of the cost of constructing, deploying and maintaining hundreds of desktop applications across a typical lage Enterprise can be eliminated over 3-5 years by creating an Ajax/Rich browser based user interface platform. Compared to the UI richness demanded by sites like Myspace and Google spreadsheets, the needs of most business applications are rather simpler and most Enterprises have a large amount of cost and complexity locked up in deploying and maintaining these applications. The coming desktop refresh cycle from Microsoft is likely to further exacerbate dependency hell on the user desktop and an investment in a UI platform delivering a location independent rich interface channel is likely to be far more sensible than investing in mass OS updates. Needless to say, I am pessimistic about whether vista can survive as a pure desktop environment in the 5-10 year time frame because of the emergence of Ajax type technologies.

2.Mashups as a composition mechanism for UI oriented services.
Last year, I heard Jaron Lanier speak at JAOO Aarhus. During his talk he brought out the concept of UI based integration that resonated with me at the time but I couldn't visualise it as working in real life. One year later, it is arguably already becoming a widely practised paradigm ( urgh) for application construction.
Using mashups is likely to take application integration and the concept of services much closer to the UI channel. Traditional portals were just a start but a a large number of business processes can effectively be seen in terms of simple mashup applications that exist to bring together not just services but living , breathing and changing applications ( which may also have a UI element). Cool stuff like this has endless possibilities in the Enterprise and belongs in the mainstream of application construction patterns , not just on the nerdy fringes. The next generation of CIO dashboard applications belong here.

3.Services acquire a Face ( from our augury section)

Our current concept of services essentially as self contained programs that exchange ( frequntly) message based input and output data is likely to change. In my view the next generation of services will have a default user interface and aggregation and composition of services is likely to occur on a UI channel in addition to a middleware/ESB backbone. Be prepared for U( ser Interface) S (ervice)B(used) type products that bring together mashups of applications and not just services.

To be continued....

More Black Swans..

2006-08-23T07:22:00.000+01:00

Strangely, the day after I wrote this post about black swan events and mentioned the current terrorist threat in it, Daniel Finkelstein has this opinion piece in The Times today making some interesting points - again motivated by Taleb's quirky book. He points out the difference between probability and expectation and that our brains don't comprehend the difference very well. I have some issues with the argument.

The argument Taleb makes goes something like this. A low probability event may be disproportionately high impact so we should treat it differently. It may be entirely rational to short the market even if you expect it to go up because you think that if it goes down, it will go down a lot.
Taleb's investment philosophy is based on that. The problem with this is that it is overly simplistic. Most people have a specific time frame for realising their investment returns. Whilst in theory it may make sense to wait for a crash to make money, our patterns of expeditures are steady over time and therefore a steady stream of moderate returns has more appeal than Taleb ( and Finkelstein ) expect. Ultimately, the crash may not happen during an investment lifetime and by creating a strategy that is exclusively focussed on low probability events, we run the risk of running out of money and ending up significantly worse if the event does not occur.

Basically I think the argument needs to consider finite time and funds before creating a strategy linked to the mispricing around black swan events.

In any case, an article quoting a similar point ( from the same book) to one made on an obscure blog appearing on the front page of The Times one day after it was posted is probably a significant Black Swan event in its own right !

5 Things that could be evil about Google

2006-08-22T10:56:00.000+01:00

Richard Brandt wonders if he is too soft on Google and unable to see a darker side to the story. As a Google admirer and investor on the one hand and a general sceptic on the other, I decide to list the 5 issues that about Google that would worry me. Note that these are not necessarily things that make it fundamentally evil - they are just issues that might in the long run take some gloss off the current poster child for uber-successful tech companies.

1.Weird management structure - How long Google can keep the triumverate as a structure that is able to lead a high growth company and industry is debatable. So far Google has had an easy run in that there really hasn't had a challenger and an inward focussed form of leadership primarily driven by engineering excellence has worked. How long two strong willed engineers working with a veteran CEO can keep a decent working relationship is a huge unknown and because of Google's weird shareholding structure, can easily scupper the company's fortunes.

2.Lack of clear non-search strategy - From all I can perceive about google, If you take core search out of the equation, it seems to be a place full of clever whizz kids who are trying to out-do each other by coming up with 'cool-stuff' and hope that a percentage of all ideas generated in this fashion stick. If there is any major strategic thinking going on it is simply not visible. Now, arguably it is better to bet on a collection of clever folk and their ability to cope with any changes and opportunities in industry and a lot of investors in google have done exactly that. However, it is just as easy to fail and get egg on the face. If search were to see a Black Swan scenario ( which I have written about in a previous post), Google could implode dramatically.

3.An inward looking corporate culture - This is a real danger where Google employees and management get carried away by their own myth and start believing they are infallible because they have never tasted failure. Microsoft is a great blueprint for this. A symptom of this affliction is the creation of products aimed primarily at demonstrating engineering coolness and nerdery rather than clear user value. I can see signs of this already happening within Google and this could be the one issue that takes it off track - the loss of focus on the user and creating products primarily to please itself. Arguably, this is how most tech companies start ( and the succesful ones manage to link it to a user proposition as google did) but somewhere along the line they need to reconcile their need to be a business with being a playshop for clever kids.

4. Secrecy - Richard Brandt has already alluded to this but I want to extend his point by including investors. At this point, due to the lack of guidance provided by google, investors are pretty much invited to buy shares not because they have visbility of clear strategy but because they are asked to trust the management team and products . So far, this has been a good decision but will this be true going forward ? Google gives very little indication of what it is thinking and working on strategically and the lack of external inputs on strategy could well lead to an inward looking 'We are always right' mentality.

5. Inability to change - Google is about search and sees this as very much its territory. Will it have the ability to quickly go beyond its original principles if broadband connectivity and richness of the online experience improve ? By this I am alluding to their original themes of no pop-up ads and simple text based pages. How willing will Google be to ditch these principles if and when the time comes to update them to take into account beter connectivity and broadband availability ? Will it be inflexible and remain wedded to a late 90s set of principles in 2009 thus allowing an incumbent to carve out a niche in richer media ( like youtube has done ) or will it remain flexible and aggressive enough to change rapidly ?

All in all, this reads more like a list of risks than anything tangible. If I were to list a potential source of evil long term, I would probably choose the dangers from an elitist corporate culture that believes its own legend. Humility and being able to contemplate failure is a vital part of the corporate DNA for long term success in my opinion and keeps companies honest.

Black swan stops play and Gambler's Ruin

2006-08-22T07:34:00.000+01:00

On Sunday I saw my first real black swan - and it wasn't a Cygnus atratus on a Sunday excursion. What I did see first hand was "a large-impact hard-to-predict rare event beyond the realm of normal expectations". Obviously I am referring to the 4th day of the England v Pakistan incident-fest which I happened to be at the Oval to see. I have also been recently reading Nassim Taleb's book on randomness and unpredictable events and this Sunday brought the message home fairly spectacularly.

Black Swan was a term originally used by the economist David Hume in a slightly different context. Hume pointed out that a conclusion that all swans are white cannot be logically drawn from any number of observations of white swans. However, just one observation of a black swan is enough to prove the converse - all swans are not white. The point here being to indicate the asymmetrical nature of rational deductions and how easy it can be to fall into logical traps. Taleb uses a slightly broader suggestion to use the term to refer to rare, high-impact events in general. September 11 was a classic black swan event - random, high impact and one most people are totally ill-equipped to comprehend.

The basic idea that Taleb puts forward is that human brains are not wired and calibrated to deal with such random and high impact events which occur more frequently than we think. For this reason, there may be opportunities to profit from the mispricing that occurs around these areas. Arguably, an Enron was a classic black swan opportunity. There was a time when Enron was a wall street darling and featured in Fortune as America's most innovative company 6 years in succession - and then it suddenly and spectacularly imploded. A speculator shorting Enron through the late 90s would have made an absolute killing.

Similarly, yesterday before Mr. Hair decided he could use a little attention, England were 250-1 to win the test match and within 30 minutes, they had been declared winners through a bizarre combination of events that has never happened before in the history of test cricket. Again a massive speculation opportunity for anyone who had taken a punt.

There is no doubt that black swan events do tend to lead to irrational and emotive thinking. An example is the current security checking regime at UK airports. If you step back and think, there has never been an actual case of someone smuggling liquid explosives on to an aircraft at a UK airport - the alleged conspiracy was just that and may or may not have worked. However, there HAS been an actual incident where people have successfully walked on to a tube train and blown it apart so there is clear evidence that can be done. However, no one seems to be rooting for increased security on the tube even when it has been shown with 100% certainty that it can easily be breached. At the same time, there is all manner of 'stringent' additional security checking when there is no actual evidence that the previous security regime wouldn't have worked anyway ! Another example is that when most people are offered insurance policies protecting them against either terrorist strikes or general loss, most people in a climate of fear choose the former even though it is covered by the latter. Basically our mental processes break down when confronted by randomness.

In this New Yorker article, Malcolm Gladwell refers to an investment strategy that Taleb follows to exploit mispricing in black swans. Very simply, his method seems to be to bet on low probability, high impact events and be willing to lose money on most trades in the belief that a large win on a black swan would more than compensate. The theory is seductive in its contrarianism and simplicity but has the obvious problems of limited funds. It isn't totally clear how Taleb would avoid Gambler's ruin. I guess one way is to keep attracting fresh funds at a rate higher than his general burn rate. In any case, there isn't a convincing argument that you can do very well exploiting real black swans by keeping on betting on improbable events in the hope that one spectacular payday will make up for all the bleeding. So while Taleb is right when it comes to the concept, it is hard to see that as a basis for an investment philosophy.

State in services architecture

2006-08-14T16:05:00.000+01:00

I recently came across a post from Harry Pierson from Microsoft questioning the received wisdom that Services should be stateless. Harry makes a valid point that any meaningful business process has state and goes on to deduce that this implies that services should have state too.

I think Harry is missing the crucial point here by implicitly conflating business process and service state. In a good SOA ( and by good I mean one which delivers on the key promise of loose coupling), business processes indeed have state - they will be meaningless otherwise. However, there is a difference between process and service state.

In my view process state should not creep into services as this makes it difficult to replace service implementations over time and can lead to tight coupling in architectures. Ideally process state should be held in an intermediate metadata layer that forms part of the SOA infrastructure ( insert your favourite 3 letter flavour-of-the-month acronym in this sentence at this point - ESB being a prime candidate).

Service state is a different issue though. I think good SOA architectures should ensure that service state is kept inside the boundary and only exposed through contracts. This way, the service can truly deliver on the promise of being an independent blob of functionality that is independent of the context in which it is used. If this isn't the case in a specific instance, I would question the value in creating an SOA architecture.

To illustrate the point imagine a service that manages customers in any organisation. A CustomerManagement service in what I would see as good design would support an operation to return the status of a customer and would allow non specific states of the entity it manages to be tracked. For example, it may provide methods to change the state of a customer entity from enabled to disabled and have methods to return the current status. Note that such interactions cause the underlying entity to change state across all the processes that may be using the service. However, this still leads to loosely coupled architectures as the complete maintenance of this state lies inside the service so any change to state is only available to other servces through defined contracts.

Now consider an AddCustomer business process. In an organisation this may require a 3 day process that uses 3 manual steps including calls to the CustomerManagement Service above. Obviously keeping the state of this process inside a service makes it difficult to modify the process in the future - that is why the whole suite of BPM type tools ( including Microsoft's own Biztalk) exists. Typically one would model this process not in a service but as as some sort of orchestration using multiple services. The SOA infrastructure would manage the state of the process while the servces themselves would manage business state of the associated entities as indicated above.

This has gone on a bit but I think it is a crucial point which I summarise here in the form of some architecture principles :

- Services should only have state that is exposed through well defined contracts and makes sense in an Enterprise wide, cross-process sense ( like customer status).
- Service state should never creep outside the service boundary.
- Process state should ideally be maintained in infrastructure software - indeed it may form the justification for the purchase of such SOA infrastructure in an enterprise.
- Keeping process state in infrastructure and service state inside the boundary is key to creating loosely coupled, flexible architectures whilst supporting dynamic business processes.

Further on the SML debate

2006-08-07T14:36:00.000+01:00

Harry Pierson and Pratul Dublish from Microsoft have written about my earlier post about SML. Before I respond I should clarify one thing. My message was not intended as an attack on SML. I am sure is a solid piece of work. I just asked - why should we care ?

The summary of their message for me is that the specification solves real deployment related issues today and is something that Microsoft will likely use to build some tools for its technology stack and roll into future products. I did mention that I can see this being useful for some tool vendors so I won't contest that. What I don't see the value of is how this is of use as a wider industry-wide specification. Do I think it is a good idea for Microsoft to invest in developments that ease some of the deployment pain a large part of which is due to the overly complex nature of its underlying platform ? Absolutely. Do I think this is the start of an industry drive towards "Service Modeling Languages" ? Absolutely not. Does this language have a future ( or past) outside Microsoft ? I don't think so. The main reason for my scepticism is that in deployment related problems need to be tackled by platform simplification rather than by inventing tools to manage dependencies. Developments in virtualisation tools already give us enough tools to run 'what-if' deployment scenarios to a far greater degree of richness and control so the problem has other solutions as well.

On a related theme, I find is odd that Microsoft has chosen to invest in 'modeling tools and specification languages' as a means of tackling the fundamental issue of deployment complexity largely due to the difficulty in dependency management. I suspect their investment is better directed towards removing the underlying fragmentation and complexity from their OS products - this is what causes dependency hell in the first place. Modeling can help people get to grips with managing the complexity, which is laudable. But it does nothing to remove the underlying problem - Microsoft's infrastructure software ( OS, databases, code frameworks (.NET) ) should probably have a simpler way of dealing with deployment related dependencies.

I do care that Microsoft is creating tooling to help in an area that causes a lot of pain on its platform. At the same time ,I have to confess to not caring very much about the specification itself and I just don't see the drivers for industry wide adoption - and by industry wide I mean solutions built on non Microsoft stacks.

In my view this drive to create industry-standards has a tendency to get out of hand very rapidly. Just witness the utter carnage the WS-* specifications have wrought on simplicity and common sense. The combined WS-* specification suite has just exploded by people adding richness to a basic framework without actual needs for it bubbling up from the wider user community ( thus causing a reaction with a rediscovery of REST). These cycles are not uncommon in software, simple frameworks start small and then as soon as they start being associated with the dreaded phrase 'industry standard' , they rapidly proceed up their own collective posteriors and get bloated and unusable - causing a simpler, stripped down version to emerge. The cycle then repeats.

Arguably a similar thing happened on the java stack with EJBs and Spring and hibernate.

What's the summary ? I'm sure SML is an intellectually robust specification that will really help Microsoft tools behave consistently and offer some value in addressing migration and deployment related concerns on the MS platform. At this point, I just don't see this getting widespread adoption outside Microsoft.

Efficient markets, data dredging and the wisdom of crowds

2006-08-02T16:52:00.000+01:00

I've been commenting on some blogs on topics touching tangentially on the psychology of investing, data-dredging and the Efficient Market Theory.

First the oft repeated argument that long term market outperformance by an investor somehow violates the Efficient Markets hypothesis. I have seen this repeated often and have never quite understood the underlying logic. This came up again recently in the light of Anthony Bolton's retirement from the Fidelity Special Situations fund. Does his long term outperformance contradict the EMT ?

If you take an arbitrarily long time period and measure average market performance over it, clearly some investors' records would be superior to that average as they can't all be the same. Looking back it is easy to identify many such patterns and instances and the fact that it happens has nothing to do with the EMT. This will happen simply due to the nature of averages and the fact that the sum total of all investors is the market.

This outperformance could well be explained simply by chance rather than any particular skill.
The more relevant question is whether you can predict outperformance in advance rather than by creative mining of past data. Could Anthony Bolton or Buffett's performance have been predicted when he started out ? Even here it gets tricky as the number of holdings is also significant. Investors taking increased risk and holding a smaller number of stocks have a greater probability of long term outperformance ( effectively a reward for the increased risk) without contradicting the EMT. People like Buffett, Munger etc. fit into this bracket.

So I believe that long term outperformance is totally consistent with the EMT. That doesn't mean that I am convinced about the EMT though.

Which brings us to the issue of data dredging, something that even pollutes a large amount of scientific research but is especially noticeable in economics. A great ( if not entirely serious) example is here . In fact Chris seems to be a data dredger extraordinaire, and a lot of his analysis fits the definition of the term to a T. That still makes him one of the most original and intellectually stimulating bloggers out there. The key point he, perhaps deliberately, never mentions is that just because you have uncover correlations and patterns in data from the past does not mean that the relationships weren't just due to chance and have zero predictive value going forward.

Finally, some discussion on cyclical markets and rationality is here . I think people underestimate the effectiveness of decision making by the 'average' person in aggregate , as part of a large, diverse group. Admittedly, my views may have something to do with one of the books I am currently reading.

Modelling Overload

2006-08-02T07:16:00.000+01:00

Another day and another modelling language specification that will unify the world.

We are saved. All software development shops everywhere will use just one way of depicting systems, everyone will know exactly what the complicated constructs mean, this will make systems incredibly easy to develop and maintain and get rid of unnecessary documentation and the prosperity and world peace that will ensue and prevail will constitute a giant step for mankind etc etc.

For a classic example of how the IT industry wastes precious dollars in misguided quasi-unification initiatives ( I hinted on this in a previous post), check out the recent releases of the Service Modeling Language from Messrs. Microsft, BEA, Cisco etc. They were pre-empted by their well intentioned but increasingly irrelevant brethren at OMG who spewed forth SysML about a month ago. What impact these will possibly have on the real world I am not so sure as they do not address a problem anyone is actually trying to solve. There will obviously be enough to keep the tool vendors excited for 6 months or so though.
It's tempting and easy to indulge in nit picking the specifications but that's not my point. Why, when the history of software is littered with unsuccesful attempts to impose monolithic modelling constructs that virtually no one ever ends up adopting, do organisations persist in wasting time and money in dreaming up the next mega-specification ? Arguably the only modeling notation that has gained widespread currency is UML and that too in what Martin Fowler calls the UMLAsSketch mode. The MDA related fairy dust that was sprinkled on UML ( giving us the hallucinogenic UML 2.0) , never really caught on widely and exists these days to provide material for architecture conferences which seem to have a social obligation to schedule a "How MDA is changing the world" talk.

We don't need a meta- modeling specification. The whizziest modelling tools are often used as a substitute for clear thinking and there is no magic tool that can solve that particular problem.

Update - Harry Pierson at Microsoft responds to my post and makes a point about SML being a bottom up approach and therefore standing a better chance of working. The point is a valid one, but as I point out in the comments :
- Solutions increasingly involve technology from many vendors and a bottom-up approach has limitations here.
- Is the solution to a communication problem to have everyone speak the same language ?

A Google PC would not add shareholder value

2006-07-29T09:55:00.000+01:00

Richard Brandt speculates on the possibility of a Google PC. My view is that in the foreseeable future there is little business value in Google venturing down this path - though as Richard points out, Google does have the capabilities to pull off such a product.
Firstly, there is no compelling reason for Google to venture into a lower margin hardware oriented business which is extremely competitive. In my view it would find it much easier to generate customer lock-in by using its capabilities in software solutions. It has already done so and arguably the lock-in exists because Google's services are universally accessible without regard to the hardware or OS they are being accessed from.

Secondly, even if a reason for such a move emerges in the next few years, I would prefer a 'Google Inside' strategy - not dissimilar to the kind of deals Google is doing with Dell. Fact is hardware prices are going to continue falling as competition and range of devices increases ( pocket pcs, mobile phones etc). Given rising incomes across most economies, it is clear that PCs will continue to become more affordable over time. For this reason I question the value in a stripped down mega-cheap Google PC. The other factor at play is that it is extremely unlikely that people are not going to want to use a PC they purchase for non-google tasks. There is a significant amount of software written that users would want to be able to run on any PC they buy, A Google or nothing PC would therefore not be as attractive a proposition even at lower prices.

In my view Google can get much better ROI for its shareholders by focusing on higher margin software oriented solutions that leverage network effects and integrate well with each other. A mega cheap google PC would have to have thin margins, uncertain takeup and be very exposed to falling prices of general purpose PCs and that would make it a questionable business move for Google at this point in time.

That said, I think a lot depends on how Vista plays out. If the user response to the launch is lukewarm ( as I suspect it might be ), Google may sense the possibility of taking on Microsoft on the desktop due to its exposed position and competitive instincts may dictate it going down a conforntational route by trying to offer its own OS or PC. I hope it doesn't though. What Google shareholders would care about is not whether or not Google beats Microsoft in any particular area but whether it is a business that consistently generates high margins and returns on equity. And the hardware business where a resurgent HP and a stumbling but still powerful Dell are likely to be long term leaders, the smart strategy is to keep the focus firmly on software but deliver richer and more integrated services over a non proprietary web based platform.

I like the idea of PCs coming with a "Google Inside" sticker in the future :)

Any form of open ..as long as it's our form

2006-07-27T06:42:00.000+01:00

Microsoft's Open XML Compatibility specification is now available.

Catch is - it's only available as a Word document inside an Exe file that will run only on Win32 platforms. I'm pretty sure they don't see the irony :)

Does the Lake Wobegon strategy work for EA groups ?

2006-07-26T13:22:00.000+01:00

I recently became aware of the Lake Wobegon strategy for hiring talent. Essentially it stresses hiring above the mean skill levels of existing employees as an alternative to hiring people who are better than at least one existing employee ( hiring above the min) .

My issue with this strategy as explained is the fact that it seems to rely on a single factor model of skill levels. Individuals who do senior roles typically need a set of skills and it isn't easy to assess whether on a cumulative basis they are above the mean or not. The multi-skill issue applies both to broad categories like technical and soft skills but also to subdomains within them. For instance Technical skill itself further breaks down into all sorts of different areas for an architect ( application, data, technology etc) and so do soft skills ( communication ( spoken and written, empathy, persuasiveness etc). A typical person may be above average on some but rarely on all equally and it is hard to tell whether they would raise the overall average. One could obviously model weightages for each of these factors but that just seems to me to be taking judgement out of the equation. On the whole, I just don't see how this would actually in EA ( or anywhere you hire into positions which are relatively senior and require multi-skilled individuals). No one would disagree that hiring above the mean of current capabilities is a great idea - but is it really possible to do this consistently in practice ?
PS - This is the reason for the name. The link is tenuous to say the least.

Market beating returns or just coincidence

2006-07-25T17:03:00.000+01:00

Chris Dillow points out that low risk stocks beat market returns over time. I think he is making a mistake by drawing this conclusion based on the performance of a 20 stock portfolio versus the 350 stock FTSE 350 index.
I remember some analysis quoted in Robert Hagstorm's book on Buffett where he found that there is a higher probability of beating the market with a fewer number of stocks - implying that if you randomly put together 20 stock portfolios based on arbitrary criteria, a higher number of them would outperform the market than a similar collection of portfolios based on 100 stocks each for example. Of course the returns would be more volatile but the point is that just because a portofolio of 20 stocks picked according to some criteria outperforms the market doesn't necessarily mean that there is there is any correlation with the criteria. It could simply be increased reward for the higher risk of a smaller number of stocks. It is quite possible that a collection of 25 stocks starting with the letter 'A' also outperforms the market.This may not totally go against what he's suggesting but it seems that you need to show more data to make the argument. I know that 15 stocks diversify away something like 80% of non market risk but that is an average figure. Hagstorm's numbers still show the increased probability of beating the market with fewer stocks in a portfolio.
Update - Chris acknowledges that random portfolios can outperform the market but goes on re-iterate that the defensive anamoly ( as he puts it ) lasts much longer. Fair enough I suppose.

The Power of ONE ( to cloud clear thinking)

2006-07-25T13:56:00.000+01:00

James McGovern goes off on one about his various theories on why IT in Enterprises isn't agile. I think he forgets to mention a key reason for this - and that is self induced by the EA community. Perhaps it is because it answers the following question : Why is Enteprise Architecture not agile ?

EA these days suffers from an overwhelming malaise that has gradually crept up and dominated all the problem solving that is occurring in the area. This is the drive towards centralisation as a solution to every problem that an Enterprise ( and an Enterprise Architect) faces. This is the school of thought that drives initiatives such as the push to have ONE (insert term here) of everything across any domain an architect that conceive of within their organisational boundaries. The term in the blank can be any technology ( database, ESB, development environment etc) or process ( governance, QA, funding etc). It is this process that causes architectural teams in large organisations to occasionally wake up and commission well intentioned unification initiatives. The underlying premise is that simplification and unification is so obviously a good thing that simplifying the mess that is a typical organisation's IT by standardising on ONE framework, database etc etc is a worthy goal. The reason this reasoning is flawed is twofold.

Firstly, every move towards 'simplification' of an IT estate has associated transition costs - both in raw spend as well as the risk introduced in the landscape. Very few people actually calculate the relative cost and benefits of sweating existing assets ( which normally work pretty well but are extremely ugly to look at) as opposed to ripping them out in the interests of an idealised simpler picture. Things are complex for a reason and the biggest reason is that complexity is a function of time. Most IT decisions are made by intelligent people solving problems in optimal ways at points in time. Complexity and 'spaghettiness' is an emergent quality of interacting systems and modules that are subjected to unpredictable 'shocks' ( aka business requirements/cost cuts etc) over time. The fact that this happens in the best of organisations across all industry domains over and over again is proof that this is simply the nature of software evolution. Changing the system without being able to change the environment is not going to change this basic tendency towards entropy in systems.

Secondly, what's the evidence that this adds business value ? Given that having a single product or framework that solves every problem that even the simplest of subdomains that an architect has to deal with is self-evidently impossible, why do people keep assuming that a move towards unification is a good thing ? Why are sources of value in a heterogenous environment overlooked ? Some of these in my view are the ability to have multiple options for solving a problem ( eg. for database storage have the ability to choose from 5 different solutions) which in most other areas leads to better and not worse decision making.

My theory on why this happens is that centralisation is easier to manage. While it doesn't lead to better IT decision making, it empowers IT managers, it appeals to the first order 'simpler is better' though processes that govern IT decision making and is generally unquestioned.
Wouldn't it be better if there was more acceptance of the idea that more energy needs to be spent on improving the manageability of complex heterogenous system sets than the time burnt up in frequent unification initiatives ( which I suspect take up more than 60% of all EA work done in industry) ?

What is Google's sustainable advantage ?

2006-07-24T14:32:00.000+01:00

Curt Monash asks what Google's sustainable advantage is over the long term and why couldn't Microsoft, given sufficient deployment of resources, be able to deliver search just as well as Google can.
First lets establish that in the very long term no advantage is sustainable in any absolute sense. That said, google’s main advantage in the search business is its ability to deploy enormous amount of computing power at low cost ( relative to industry) using its homespun set of technologies. This article describes it well. Being the lowest cost provider of computational infrastructure for mass usage makes it easy for it to maintain leadership in search which demands exactly this. However, in the future, it also enables it to go into any other areas where huge amounts of data storage, processing and analysis are required ( video is an obvious here). Sure, other companies can do this by throwing money at the problem - but can they do it at the low cost that google can ? Till there is some ground breaking technical breakthrough that makes Google’s model of distributed computing at a mass scale deployed on inexpensive hardware obsolete, I think this is as sustainable an advantange as any other.

5 new skills SOA practitioners need

2006-07-03T14:10:00.000+01:00

Part of the ritual of engagement of architects with their peers is a pre-emptive declaration of knowing contempt for the latest buzzword. Service Oriented Architecture /BPM has been a real need-filler in this area. What better way to instantly declare your mastery of all things architecture than to knowingly preface every conversation with a world weary "UML is so-oo overrated" or "Oh not this SOA hype again ". Such sentiments signal a mastery of the subject to those less able and instantly define the guru-acolyte dynamics in an interaction.

Well this has been happening a lot lately so, fed up of the "SOA is just the same old stuff just hyped up" hype, I decided to launch this blog into cyberspace by defining why this SOA thing is not just the same old techniques packaged up in new garb. Here are 5 things that SOA practioners need to master and yes, they have evolved in the last ten years.

1. Process based thinking.
Yes I know processes analysis has been around for ever. However, the use of top down Process based thinking leading to systems design on a widespread scale is a recent development caused by the emergence of tools and the development of industry standards at roughly the same time.
Building an understanding of the nature of process design and re-engineering and assessing where BPM and SOA tools can and cannot help is very much a 21st century skill.

2.Composition based design.
Dashing all hopes that the phrase paradigm shift died of natural causes in the OO era, allow me to resurrect it for a sentence and say that composing efficient processes and systems using independent, autonomous services that have no awareness of each other is a new technique for architects to master. There is a definite skill in being able to combone loosely coupled , always running services to deliver business logic. A new mindset is required to understand issues of state management , process orchestration and business rules in delivering effective solutions using composed designs and creating metadata based business process logic without relying on a shared process space ( as in traditional programming methodologies).

3. Investment justification and value assessment
SOA and BPM initiatives require investment in infrastructure - often significant. Enterprise architects need to be able to make the case for platform investment for these initiatives to lead the business and need new skills in valuing the flexibility. They key benefits SOA and BPM platforms provide is future flexibility and an Enterprise architect needs to be at least conversant with non traditional means of investment valuation like Real Options. Stndard NPV and IRR based techniques that work on the basis of determininstic projections of cost and benefits are inadequate in valuing the flexibility that comes with a platform than can open up opportunities for future initiatives that are difficult to accurately value at this point in time. The inherent value of this option needs to be valued and communicated in business terms and it is a skill EA practitioners increasingly have to come to terms with. Expect this to become increasingly mainstream in the future.

4.Buzzword mastery
The ability to distill out the few nuggets of sense that lie behind the constant buzzword assault on the senses is more important than ever in the SOA/BPM space. Unconvinced ? Allow me to challenge you with a small sample of acronyms you would normally expect to be able to make sense of on a day to say basis ( I'll leave SOA and BPM out)
ESB, BPML,UML, OMG,MDA,REST,SOAP,ATOM,RSS,AOP, SOMM
(That last one I overheard at a particularly "kid-you-not" moment at a conference - stands for Service Oriented maturity Model whatever that means).
Now expected to be confronted constantly with the following questions as an architect by earnest and sincere sounding folk :
What is our (insert acronym from list above) strategy ? and expect to be able to give a diplomatic and equally polite response.
Which leads us nicely to .....

5. Problem definition

A large number of questions Enterprise architects spend time tackling have to do with a particularly bizarre variation on applied Ideonomy , that weird science of taking any bunch of terms and combining them to form a proposition - whether it has meaning or not.
Like this sentence , a lot of the propositions around SOA and BPM are nonsense cloaked in rational sounding structures.
"What is our SOA strategy" is merely one such form of this logical trap ( cunningly implying that there is obviously some value in having an SOA/ESB/BPM strategy). I'll leave finding other such nonsensical statements as an exercise to the discerning reader.
Seeing through this bovine faeces and guiding discussion around to the more sensible "what is the business value of investment in SOA related technologies and do I need to do it " type discussions is also a very 21st century architect skill.