Executive Advisory Program

It's the "B"

Posted by: Michael Disabato

Some of you may be wondering what I'm doing over in this blog, since I'm Service Director for Network and Telecom Strategies at Burton Group. In addition to being a wireless geek, I survived the ITIL adoption at McDonald's Corporation a few years back. I've been writing about ITIL for a while, and the thought was, since our clients seem to like that, I'd do more of it. So here I am.

Now, about that "B"....

We use Yammer internally (think: Twitter in a secure sandbox), and there was a discussion about information technology that started with a discussion of information (data) management. Things went back and forth between Lyn Robison and Jack Santos sort of like this:

Lyn: In enterprise IT, "T" people might tend to go to work for cloud vendors. It will be interesting to see if enterprises will employ "I" people to a greater or lesser degree.

Jack: At this point, most "T" people should be thinking about that as a career move.

And I popped up with: Forget the "I", forget the "T", it's all about the "B".

Yes folks, it's all about the business. I told Dave Passmore (Research Director for NTS) once that "technology is irrelevant." That started a discussion that consumed most of a 90-minute staff meeting. In the final analysis, though, the technology you employ is irrelevant if it fails to meet or support the company's business needs. It's like the iPhone: everyone wants one, but it's taking time to convert this shiny toy into a full-fledged business tool with enterprise-class features that can support business operations and meet regulatory requirements.

That's the point behind ITIL. It focuses on how to manage the "T" and provide value to the "B".

Stay tuned for more on this and drop your comments here if you want to speak up about it.

Michael

Questions

posted by: Jack Santos

Homan Farahmand, in our consulting service, shared this with us. 

We have our annual Catalyst conference coming up; at the core of the discussion at Catalyst are exactly these questions – and answers/strategies for businesses to prepare for the trends.

Awesome video. Enjoy!

IT Value - We Reap What We Sow

Posted by Mike Rollings

How does your organization define the value of IT? Many IT organizations have defined their value based on the ability to deal with complexity.  Many times we pride ourselves on how much complexity we deal with.  We may even say "you don't need to know, it is way too complex for you to understand."  Instead of complexity, the value of IT comes from being transparent about your business contribution. It does not come from being able to deal with complexity.

Today I read "Salesforce unfazed by Oracle competition in cloud computing" by Rob Barry.  In the article Cheryl O'Connor, the worldwide CRM strategy manager at signal processing company Analog Devices Inc., said she deployed Salesforce.com on her project's budget without involving IT in the mix. Still, she concedes that as time goes on and Analog Devices' use of Salesforce grows increasingly complex, IT has become more involved.

The great part of this quote is that Salesforce.com gave her the ability to do more herself without engaging technologists.  I don't know if IT at Analog Devices was involved in the initial choice of Salesforce or other steps along the way. But the sad part is the impression that IT did not have involvement with the business until the business was forced too because complexity reared its ugly head. 

As we race toward cloud computing our ability to broker solutions with respect to a business outcome becomes a primary value contribution. Much of the complexity that we pride ourselves on will be someone elses problem. Internal IT will be competing with new environments that appear much simpler. If your organization defines value based on dealing with complexity, the business will perceive that it does not need IT in this much simpler world. 

It won't matter that the post-modern IT world is much more complex than the old.  What will matter is that it is perceived simpler. And if your value comes solely from dealing with complex things, then the business will not perceive the need for IT. 

There are many other valueable reasons to engage IT.  Make your value contribution to business outcomes known!

For more information about value management and how to use metrics to demonstrate the value of IT, register for our July Catalyst Conference and attend the metrics track.  I will be deliverying the keynote - "The Essentials of IT Value Management." 

Real Legacy Issues

Posted by Chris Howard

My apologies. It has been a long time since I posted. Jack has been valiantly holding down the blogging fort while I've been on the road. Mike Rollings was off the grid for a full two weeks, resting his brain, seeing his kids through graduations, and tending his new scruffy beard. Well, I'm not so sure about the last part...but beards are back in style (i.e., Joaquin Phoenix, Mike Weir, Chris Howard).The last three weeks, I have seen nine countries and as many cities, ranging from Basel to Phoenix.This is my first week in my own office chair since the end of May. And my brain has settled enough to write a post.

While in Rome during my hiatus, I was faced with an onslaught of history and metaphors. After a few days there, one gets desensitized to the oldness of the place: "Oh yeah, there's another ancient Roman monument." You eat pizza in front of the Pantheon nonchalantly. You rub your tired calves on ancient paving stones. You smile brazenly for pics in front of the gaping guts of the Colosseum. History is a fact of life in a city like Rome. You take it for granted.

Until you have to build a new subway line.

There is a project in Rome to construct Metro Line C. The line cuts across the city along the line of popular tourist locations. As you walk the narrow streets and alleys of the Ghetto and Campo di Fiori, there are signs of work below proudly advertised with official Metro signage. And more often than not, signs indicating archeological work.

Rome has rebuilt itself by building on top of itself. Layers of civilization are everywhere, most of it unexcavated. In the centro storico, dark stain lines high on the walls indicate where street level was before excavation began. As a result, if you dig a hole, you need to be prepared to work closely with archeologists charged with preserving Rome's legacy. If you are tunneling under the city to create a new subway line, the legacy problem is orders of magnitude greater. Project plans are being adjusted as we speak to extend the "completion date". In fact, one sign I saw gave the project timing as "Spring 2007 until Completion." How's that for non-committal? As one Metro official said, "We expect construction of Line C to take between five and seven years. It is impossible to make a more precise estimate because so much will depend upon the archaeological finds." That was 8 years ago. Completion is now targeted for 2015.

So, techno-geek that I am, I immediately draw a comparison between this scenario and the challenge of legacy IT infrastructure and applications. When I explained this to my 18-year old son who was along for the trip, he didn't find it very exciting. His response was "why do you think about this stuff?" But I digress.

The comparisons that strike me:

1. Some of the historic substructure is mapped and known. Much of it, however, is not. You don't find it until you start to dig.

2. Once you hit something in the legacy infrastructure, it's unclear how deep it goes, how far it reaches, and what dependencies it contains.

3. It is probably unacceptable to just dig out and remove legacy stuff. Worst case, it is supporting something else that comes crashing down as a result. More often, it has tremendous meaning/value to someone who therefore blocks its destruction.

4. The best intentions of providing something new and highly efficient are subject to delay as legacy issues are resolved.

5. Access to the new system may end up being convoluted due to complex existing, immobile structures. (In the case of Metro C, this means carefully considered station access points, and there isn't much space to work with.)

6. The resulting solution will not be a straight line. It will bend around legacy structures.

7. Some projects may be abandoned because the risk posed to the superstructure is too great.

So, the moral is that our IT shops are quite Roman. We have extended our IT infrastructures by building on top of older versions. When it comes time to put something new in, we are faced with a fuzzy set of legacy dependencies that increase risk, extend project timelines and complicate design. Maybe we need a better city model. Phoenix? Not so much.

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…

Using TOGAF and Burton Group's Reference Architecture

Posted by Mike Rollings

I returned from vacation today to a client's question about how Burton Group's Reference Architecture applies to The Open Group Architecture Framework (TOGAF) and any other architecture framework.

Simply put, TOGAF provides methodology to discover the inputs to an architecture, and methodology to describe an architecture.  It does not provide proven architectural approaches that are related to a set of typical client requirements.  Client requirements may be localized to a particular technical architecture domain (the classification of technologies imposed by TOGAF methodology) or may cross domains.  TOGAF provides an approach to consider the requirements, but non-Burton Group clients are responsible for having the knowledge to thoroughly conduct the analysis, interpret the analysis, identify the implications upon requirement’s, and determine the appropriate architectural solution.

Since requirements must be identified by the client – the obvious questions become:
• How do you know core requirements are complete?
• What architectural approach will satisfy the requirements?
• How can I accelerate this process?

Burton Group’s Reference Architecture (RA) answers these questions and an architecture methodology like TOGAF does not. 

Burton Group's RA helps technologists examine technical architecture requirements that are imposed by business strategies upon the technology domains. Our Technical Positions identify the set of typical requirements encountered for an architecture (e.g. Network Intrusion Detection and Response), alternatives, future developments, and evaluation criteria.  It then provides decision-making logic used to identify a tuned architectural approach to satisfy the set of requirements. 

Therefore, organizations can accelerate their technical architecture creation by starting with the Burton Group RA based on an understanding of their strategy in a given area, identifying pertinent requirements from our collection, and then using our decision logic to create an architectural recommendation.  This saves time and money!

Twitter remorse

Posted by: Jack Santos

About a year ago I spoke at our annual Catalyst Conference (check out this year’s here), and had a rant on Twitter (as part of an Information Overload talk I gave).

Bottom line, I didn’t understand why anyone would become religious about 140 character real-time updates, and was concerned about the “too much information” trend with email, IM, SMS, facebook, myspace, etc etc etc

Well, there is a use case for Twitter, which makes me eat my words (somewhat).  Revolution, populist uprisings, any mob-based movement.

Like these.

and these.

Is it only a matter of time when the mob turns on something that is only a rumor, not fact based, panics, and has significant economic and societal consequences? Like against a legitimately elected government? I hope not.  In the meantime, check out #IranElection on Twitter to watch history in the making. 

The  revolution will not be televised, it will be tweeted…

We are all SMBs

Posted by: Jack Santos

I hear an awful lot of dismissive talk whenever a new innovation comes along…whether it’s cloud, SaaS, the Apple iPhone, or  some new social networking (web 2.0) tool.  It usually ends with something like “That will work for SMBs, maybe”. 

I think there are two  motivations behind that.  One is the assumption that SMBs (Small/Medium sized Businesses) will take on more risk, can do things quicker and respond to innovations faster, and that they naturally lean toward cheaper (and not necessarily better) solutions.

The second is that as IT professionals we are tired of one-offs and silo solutions, and will naturally gravitate towards a solution that can easily work cross (f500 f100 f50) enterprise, in the hopes of consistency.  I can certainly relate to that, remembering the days of having 30 email systems in one company.

But it also seems to me that most corporations WANT to act like SMBs.  They want to fine tune accountability and P/L to give business unit heads the chance to be successful, and have a sense of ownership.  If everything is dictated in the vein of “standards” or “consistency” then innovation, and profit motive can easily be squelched.  This is particularly true for new, and innovative, solutions – even if there is a potential for overlap with existing (standard) solutions.

So the wisdom in management is to decide when something is a commodity (and force standards) and when it’s not – which may depend on the state of the technology, the state of the company, culture, strategy, risk assessment, etc etc (numerous factors – it isn't black and white).

My thesis is that most (if not all) major companies want to act like SMBs, or risk being marginalized by one (or out of business).  There is a false sense of safety in staying with the status quo but it limits innovation and transformation (read Mike Rollings’ post Release that Kung Fu Grip).

I would also contend that it is appropriate to choose areas of innovation, and a strategy that emphasizes total P/L accountability, while offering (but not requiring) a common solution.

There are other names for this topic, ones we hear a lot about and are on a lot of business leaders minds.  How to make your company innovative. How to drive transformation.

Of course either way (acting like an SMB or acting like a F100 Enterprise) has a lot of baggage.  That’s why management decision-making is not easy.

Maybe we should all act like SMBs.

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.

Bloggers, Beware

 Posted by: Jack Santos

A recent journal article came across my desk on Blogging.   In one of those rare moments where I can get to be Hofstatderian (author of one of my all time favorites ), and be totally self reflexive and in danger of getting caught in a programming loop…

So Bloggers (like yours truly) are less like journalists or individuals with a right to express opinions (even wrong ones), and more like corporations, held accountable (financially and reputation wise) for being wrong, or off the mark.  Wow.  this should be interesting.

It does happen (although not with regular frequency) that my colleagues at Burton Group occasionally get targeted by vendors for blog comments,   Those specific disagreements have been significant, but we have been proven right in our assessments, and vendors have threatened to disengage (to which we have responded, “So? We work for the client and call them like we see them”).

Unlike many other research, and quasi research, firms, we ascribe to a mantra of "vendor independence".  A minor portion of our revenue is vendor subscriptions, and we don't accept payment by vendors for research (that propensity by others for vendor funded research is, in fact, anti-research).

But these rulings may have a chilling effect on the blogsphere…we shall see.  Another aspect of our litigious society, and the gray area between the web and the real world. 

Even more importantly, last year I did some research on executive (CxO)bloggers. Although an excellent communication medium, executive bloggers are still rare...and with trends like these they may be even rarer.