Executive Advisory Program

In the not-so Clear

Posted by: Jack Santos

Belly up. Closed. Anyone notice?

In my year and a half or so as a Clear member, I think I used it once.  Seemed like a good idea when long lines after 9/11 were still fresh on my mind. 

But even then I was concerned about all the personal info they were collecting – SSN, credit card, height, weight, eye color, hair color, fingerprint, retinal patterns.

Where is that stuff now?

Then TSA improved its process.  Never any lines at the regular queue, resulting in  empty stations at Clear;  it was pretty obvious where this was going.

I found that the Clear play was always a bad bet – basically a bet on the government NEVER getting its act together. A bet on outsourcing.  A bet on private enterprise trumping public initiatives every time.

Wow. Now that’s the definition of zeitgeist.  Those assumptions were all true during the Bush years, but apparently not true anymore.  Big government is “in” big-time, baby.  And for Tarp-funded execs that gave up the private jet,  the last protection from the unruly travel mob is gone. So it goes, off to the expert lane.

I ignored the advice of our Identity and Privacy team, and took the Clear leap.  They have something to say about this too, here.

Hey- what the heck, it was comp’d by Marriott, why not? As Dan Ariely, behavioral economist at Duke, has said: I was seduced by “Free!”   And the government supported it, didn’t they?  With much talk about expedited lines and trusted frequent travelers….

Now, Clear laptops are missing, servers are idle and unprotected, and some hacker somewhere is happy, working on how to take advantage of me.  I hope my homeowners identity theft rider covers this…

Clouds and Systemic Risk

posted by: Jack Santos

The “Cloud” topic is much in vogue these days, and runs the risk of the hype cycle; I feel “clouds” are at a peak hype stage and ready for a big disillusionment phase.   That may be so, and we may be tiring from cloud-this and cloud-that.  But I believe that fundamentally, references to the cloud really occur at two levels, both of them significant.

The first level of cloud (what I would call “True Cloud”) is really virtualization gone wild.   Now that most datacenters have implemented and gotten comfortable with virtualization, many are experimenting with it in such a way to maximize capacity and expedite failover or load management.  Especially for organizations with large (>10,000 sq ft), multiple backup datacenters.  By focusing on virtualization workloads, datacenter operators now have the flexibility to truly separate applications from the physical hardware.  Amazon and Google have become masters at this and have productized their offerings.  Nick Carr (in “The Big Switch”) theorizes that this is the start of the utility computing era, much like Edison power plants sounded the death knell for private company-owned power generation.

The next level of cloud is more intangible.  It’s a notion that anything can be built, run, or used over the internet.   I’ll call this “Cloud Think”.  It may be predicated on the “True Cloud” advances (and it may not), but it certainly is a major advance in business thinking of IT: rent – don’t buy.  And just as the holy grail of home ownership has become a mantra for our American generation (and to some extent the root cause of our current economic morass), for many IT folks, locally produced and operated datacenters have been sacrosanct – until now.  The model is beginning to look more like the Euro view of buy vs. rent.  Yes, some buy, but many rent, and that’s OK.   Technological advances with “True Cloud”, and psychological advances with "Cloud Think”, now makes us realize we have that option, and that it is economically feasible.

But what worries me more is the systemic risk associated with clouds – and whether that is on anyone’s radar – in either the “True Cloud” (for raw R&D) or “Cloud Think” (for decision-making purposes) camps.  Systemic risk is on everyone’s mind, since we just pulled back from the economic abyss – and still not quite sure why or how.  Wikipedia's definition of systemic risk is what I’ll use:

• In finance, systemic risk is the risk of collapse of an entire financial system or entire market, as opposed to risk associated with any one individual entity, group or component of a system.^[1] It can be defined as "financial system instability, potentially catastrophic, caused or exacerbated by idiosyncratic events or conditions in financial intermediaries".^[2] It refers to the risks imposed by interlinkages and interdependencies in a system or market, where the failure of a single entity or cluster of entities can cause a cascading failure, which could potentially bankrupt or bring down the entire system or market.^[3] It is also sometimes erroneously referred to as "systematic risk".

What everyone now knows, when it comes to our complex financial system, is we don’t know what we don’t know.  Those that make a living in economic research (like Nobel Prize winner Paul Krugman) anticipated significant upheaval, but are still as shocked as anyone at the speed and breadth of the recent collapse. Lowell Bryan and Richard Rumelt talk about it with McKinsey, in a recent article.

And we don’t have to go too far back in history to discover the effects of systemic risk on the most over engineered and revered system on earth: our electric power grid. The northeast blackouts of 1965 and 2003 didn’t occur in a backwater country with gum, duct tape, and bailing wire distribution systems.  It did start with seemingly small innocuous events that everyone thought had been designed for, spreading wildly to affect millions for an extended period.

As a result of the recent financial collapse (or near collapse) two concepts related to systemic risk have come to the forefront: “too big to fail” , and “too interconnected to fail”.  Both of these concepts are entirely appropriate for what we in IT are defining as the cloud.  Burton Group research is very concerned with this and the topic of risk management.  Bob Blakely often writes about it (Risk Management: Concepts and Frameworks as an example).

Bob Metcalf, the inventor of Ethernet, had to eat crow when he predicted the collapse of the internet due to systemic risk issues. It never happened.  I certainly don’t want to follow in his shoes on that topic, but now that we are building the cloud on top of the internet, the systemic risk only grows greater; he may have been wrong on timing, but right on the danger of collapse.  In  the 20 years since he made that prediction, we have only become more dependent on our computing infrastructure.  Cloud – “true” and “think” – developments promise to make that dependency even stronger, and the risk factor even greater.

If all goes according to the plan of cloud pundits, cloud systemic risk will converge with financial system systemic risk…and the stakes will be as high as ever.

Globalization: Winners and Losers

 Posted by: Jack Santos

From the Globalization desk. 

I was surprised to learn last week which countries are the biggest losers and winners, based on acquisitions.  This was  data on change of ownership control, as measured by a company's purchase price.  Interesting analysis in this month's Harvard Business Review by Ken Smith at Secor Group.  By analyzing the data, he showed the resulting net (gain/loss) to a country for all of the companies based in that country that were sold or bought by companies from other countries.

Interestingly, and not so surprisingly, from 2000-2008, the US/UK/Canada and Netherlands (Yes! Netherlands!) were the biggest net losers: 220/187/158/111 billion dollars, respectively).  Apparently the bulk of the Netherlands loss was due to ABN/Amro's sale; even more surprisingly – doesn't part of that ABN sale go to Bank of Scotland?  Yet, the UK came in second with a net loss.  Had that not happened, would the UK net loss of ownership be staggering?

But even more surprisingly  were the winners.  One would expect, by way of press coverage, that it would be India, China, maybe even Indonesia.  Not even close.  Belgium, Spain, and France, the latter dwarfing everyone with a 234 billion net inflow of ownership value.

The long term implications of globalization to IT are significant – not just from a sourcing perspective, but also from a management viewpoint.

As for the conlusion: Viva la France...

Phantom Posterchild - Time for Transformation

Posted by Mike Rollings

In the article "Sony Pictures CEO hates the Internet" Dave Rosenberg reports that Sony Pictures Entertainment CEO Michael Lynton stated "I'm a guy who doesn't see anything good having come from the Internet."  He concludes that instead of embracing new technologies and delivery methods, Sony chooses to stick to the old, now failing ways, as evidenced by the company's recent $1 billion loss.

As I discuss in the Burton Group Perspective document "Real Transformation: Why IT Change Is Not Enough" this is an example of a phantom in the form of an assumption: “We cannot do that because..." The brain is the master of phantoms. Once you begin looking at the world a certain way, you begin to see everything through that lens.  These are the same mechanisms that allow the brain to manufacture the feelings associated with a phantom arm. Yet the fact that the lens itself exists is never examined.

Phantoms prevent the emergence of new conversations while hindering responsiveness and progress. I wonder how long Mr. Lynton carried this notion around with him?  I wonder how many ideas were dismissed by his automatic filter called "nothing good comes from the Internet"?  What would be the result if his filter was "What can Sony reap by embracing the Internet"?

Exorcise your phantoms!  Assumptions, feelings of futility, and other phantoms reinforce status quo and are roadblocks to transformative discussions.  Stagnation - the lack of innovation and agility - happens when you become married to your phantoms.

Benchmarks and the Road to Mediocrity

Posted by Mike Rollings

As I wrote in the Burton Group Research Perspective "Measuring Enterprise Architecture Success" it is hard to avoid a simple trap -- the use of benchmark results purely to understand your organization’s progress in reference to the progress of others. Using the results in this manner encourages mediocrity.

Whatever you benchmark, it is more important to address the problems your organization is experiencing instead of getting a passing grade. Therefore, the problems must be examined with an internal perspective and not just addressed with a broad brush of a benchmark. Problems with IT delivery, decision-making, the application of standards, and other issues cannot be identified solely by comparing your score to that of others in your industry. By analogy, just because you know where you are, and others are with you, does not mean that you are not lost or that you should follow the same path.

A benchmark may be a useful data point to help an organization identify glaring differences between itself and the competition, but that is only a small part of the picture. The most valued use for a benchmark or maturity assessment is to identify what is working and what is required to improve to better address business outcomes.

Sometimes the excuse is "we need a benchmark because it is the only thing our executives understand."  This cop out is one of the disabling assumption in IT that avoids something that is critically important today -- having fact-based, real discussions.  As I wrote in the Burton Group Research Perspective "Real Transformation - Why IT Change is not Enough", we need to deal with underlying business and IT assumptions before we use the excuse of status quo to our peril.

Two phantom assumptions many IT organizations encounter are the assumptions, “we cannot do that because. . . .” and “the business will never consider. . . .” Phantoms solidify into the assumptions and constraints that perpetuate complexity and duplication while hindering new business and IT conversations and progress.  

Management executives require metrics to monitor improvements and achievement of business outcomes.  If you are avoiding the conversation because you think executives won't understand it, then maybe they don't understand it due to the lack of meaningful metrics.

SLAs and Behaviors

posted by: Jack Santos

One of the trends that we at EAP talk about a lot is the “Externalization of IT”.  This simply speaks to options for IT sourcing – some that have always been there and have been growing, some that are new and interesting.  Outsourcing and off-shoring are in the former category, SaaS and Cloud in the latter.

The fact is that success of IT is only breeding more IT needs; and just like the early Ma Bell phenom where, without electronic switching, the trend was that there would never be enough old-style operators to hire, so it is with IT services --- unless we look at different ways to do the work.  All the externalization options are just ways to do that, and part of the tool kit for any business head or CIO.

Sure, you can get into debates about the cost effectiveness of IT – Like the recent Mckinsey cloud study ( a NY Times summary is here), and counter arguments, like Amazon’s James Hamilton’s comments.  I think the jury is still out on the numbers, but it’s undoubtedly clear that for small/medium companies, cloud computing (in its broadest sense) is an option, and for large companies, it depends.  The fact is, though, that every company is taking advantage of externalization options in one form or another.

But what’s really important, besides why to do it, is how to manage it once you have done it. In a recent conversation with Carl Ascenzo (ex-CIO of Mass Blue Cross, not at Ascention consulting) we talked about that - what happens after you sign the deal?

Carl has a lot of experience with this -- he managed one of the (I dare say) oldest long-term IT outsourcing contracts for a major corporation – Blue Cross’ IT outsourcing to EDS which started in 1995 and continues today.  His secret sauce was “managing behaviors”, not just SLAs.  

Sure, IT folks are usually pretty comfortable with black/white, yes/no, zero/one, on/off. Service agreements and metrics certainly fall in that category.  But, says Ascenzo, focusing on the soft side is equally important.  What behaviors is the vendor bringing to the table?  How did they react? What’s their attitude?

Sometimes focusing on behaviors is hard, more difficult to talk about, and open to debate.  But often it’s the simple questions that make the relationship work;  and in this case it’s “When all is said and done am I, the customer, satisfied?”

Looking at it with both those factors (SLAs and behaviors) makes the business relationship better, for the long haul.

Psychology of Stock Widgets

Posted by Chris Howard

I know I'm breaking all the rules. It's 6 pm on a Friday evening, the worst time to blog based on all the statistics. Most people read blogs on Monday and Tuesday, apparently. But I'm winding down, absorbing the week's work, pregnant Aussie/Collie at my feet. And I had a thought.

A few weeks ago, I downloaded a StockTicker widget for Firefox to track the daily machinations of the market. For the past few weeks, Fridays have been pretty good, relatively speaking. It's amazing how a positive market — in green font — changes my mood. Right now it reads 8017.59 (+39.51 / 0.50%). It is so much better to head into the weekend with that in my status bar. Yeah, it's not 11000, but at least it's not 6500. The best thing is that that number will stay in my browser status bar until 9:30 AM ET Monday morning...then, who knows?

As Pavlov's dogs, we are led by crowd psychology, and that will be a significant part of the economic upturn. Without that psychology, the upturn will struggle to gain momentum.

So, first everyone needs to download a StockWidget. Second, some creative programmer needs to hack that widget so that every Friday the market improves, putting the week into the green.

Wait! We've had enough manipulation of statistics and investment math to last us a few generations, thank you very much. I'll just hope for reality.

Have a nice weekend.

On the Death of SOA: Epilogos

Posted by Chris Howard

A couple months ago, I wrote and published a strange piece entitled "On the Death of SOA", loosely cast in the form of a Greek Dialogue. The response was mixed, as I anticipated, ranging from "That's Classic!" to (I paraphrase...) "Playwrights are dumb, stick to research!" (That last comment really hit Jack, our resident playwright, where it hurts). The message within the piece was not a joke, however, even though the presentation of it was a bit tongue-in-cheek. Hopefully, people that know me and my writing understand where I'm coming from.

Indulgeo mihi, patiens lector. Or should I say, συγχωρώ εμένα , υπομονετικός αναγνώστης.

So, I thought a non-tragic epilogue might be a good idea.

I have spoken with many clients and members of the media since Anne Thomas Manes' obituary for SOA published in early January. Amid the cheers of support for her message (one senior exec in Germany actually applauded when we talked about it in February), there has been a non-trivial amount of confusion. Many readers were blindsided by the headline, and missed the underlying advice. Some accused Anne of cheap sensationalism.

Let me say outright that Anne is not the sensationalist type. You'll look long and hard to find a more pragmatic, down-to-earth, pull-no-punches analyst. Also, SOA has been Anne's "baby" for a long time, so for her to kill it for sensational purposes would be nothing short of infanticide. From my perspective, Anne did not kill SOA so much as she dropped it from the nest. Anne's — and Burton Group's collective — decision to raise attention to SOA's fatal faults was based on whether we could, in good conscience, continue to lead clients down a path with a low likelihood of short-term success.

If you read Anne's defense of her SOA obituary, you'll find that she strengthens her position on both services and architecture. Her intention is to raise the level of discussion, to change the emphasis from technical details to strategic objectives. The service is a unifying element that facilitates the implementation of a business capability. Architecture is essential to understanding how services fit together, and guides their design. Removing the emphasis on the acrimonious acronym "SOA", stripping away its semantic overhead, seemed to be the correct way to reorient the discussion.

There is a larger issue, however, that is linked with this particular moment in time. The recession is causing ROI windows to narrow. If an initiative cannot prove its ROI within 6-9 months, it is likely not to be approved. Tactical work trumps strategic work, at least for now. Most SOA initiatives take much longer to prove ROI, so they are being pushed out into the fuzzy future. In that future, IT organizations will need to provide stronger metrics and estimates, and avoid "silver bullet" discussions. Tossing acronyms around without significant justification will not work.Successful architects will be able to iterate towards an enterprise service architecture within the restrictions of ROI windows.As proven in the 2008 Application Platform Strategies contextual research project, this type of SOA success is the exception to the rule. Many more initiatives stall out after multiple quarters and substantial funding. This stalling has created a progression from SOA fatigue to SOA disillusionment. If you continue to push on SOA, your executives may take on the "bored senator" stance.

Time to change the conversation. That's the focus of Anne's proclamations.

We will be digging into this topic in depth at Catalyst 09 in San Diego, so come armed with your questions and ideas.

Value is Ambiguous and Vague - Thank You Captain Obvious

Posted by Mike Rollings

In a court challenge  to a Chicago Landmark ordinance preserving architecture, an Illinois appellate court found that terms like “value” and “significant,” are ambiguous and vague. You could say the same thing about the definition of value in information technology (IT) value management or the value of enterprise architecture!

A term has no meaning until we assign meaning to it.  Value is vague when we fail to identify the outcomes that we "value". I like one definition of value, "the usefulness of something considered in respect of a particular purpose". (The New Oxford American Dictionary, Second Edition)

If an organization does not identify a purpose for its IT investments, then the usefulness of each potential project cannot be evaluated. A symptom of this is when IT projects are selected based on politics, bag-o-money syndrome, or other ambiguous approaches. Another symptom is when infrastructure is hard to justify. The easiest way to justify infrastructure is through the identification of dependencies to projects that have a clear purpose - the infrastructure then has purpose too. Yet another is when EA programs struggle to articulate how they add value.

For all these problems related to value, start with defining the purpose or the outcome you desire. If it is cost reduction, then the usefulness of complexity reduction can be examined which brings application redundancy, infrastructure redundancy and other costly affects of complexity into the light. But if you cannot identify the outcome, you are hoping you are doing the right thing instead of acting purposefully. You are also going to struggle to develop criteria to evaluate options and measures of success.

So don't wait for another court to point out how vague "value" is, start defining the meaning of value for your organization.

Post-Modern IT Primer

Posted by Chris Howard

I promise to write more about this in the months to come, and show how it relates to all of Burton Group's coverage, but here's the skinny version.

Post-modern IT assumes that bits of functionality and data are spread all over. Some of it is commodity, some of it is strategic. Some of it is built and/or operated by the enterprise, some of it is consumed by the enterprise from service providers. The tension comes from this: should we attempt to corral these fragments into order, or should we capitalize on their emergent properties? How much does the concept of post-modern IT challenge the command and control structures of most enterprises?

As companies work to re-imagine their business models in response to the recession, costs will be driven down by finding the right balance of fragments to combine from inside and outside. This dynamic is driving the accelerated interest in the cloud, SaaS, and related concepts.

Taking this a step further, the unified field naturally connecting all these fragments disappears (if it ever existed at all). Unification happens in logical overlays that serve specific purposes or points of view, but these overlays do not change the nature of the underlying fragments.

OK. I got that out of my system. Off to Vegas and MIX09, so the opportunity for serious philosophical thought is quickly disappearing.