A Google PC would not add shareholder value

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

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 ?

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

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)

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 ?

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

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.