Executive Advisory Program

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.

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!

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.

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.

Comfort Food and Cloud Computing

Posted by Mike Rollings

Isn't it nice to sit down for a helping of comfort food? I grew up with pot roast, pork chops and gravy, fried chicken, mash potatoes and other wonderfully tasty foods.  I don't eat them all the time, but when I make them now I have fond memories of my childhood.  It is... comforting.

Now I reserve comfort food for the occasional meal.  My workout regiment and my eating habits reflect my new lifestyle. My previous eating habits were slowly killing me.

The way IT implements business solutions today is loaded with comfort food. The solution paradigm has incrementally improved from the days of the mainframe.  Sure there have been some major improvements that give the illusion of a transformation, but the dominant paradigm has been to build solutions inside the four walls of an environment protected at the perimeter.  We are comfortable with it!

Like blocking the holes in a sieve, we keep trying to incrementally improve our approach and stuff keeps falling through. Identity, security, services, integration, information management... it is all a mess, and it becomes more of a mess when you try to apply it to a new paradigm like cloud computing.  Complexity is constantly increasing and IT staff just continue to cope with the burden. I think it is a sign that you can become comfortable with anything.  As long as it is incremental, you can put up with a lot of pain.

Two areas where the affect of comfort food is evident are the application portfolio and information quagmires. Many organizations have been ordering high-fat functionality from IT. But IT—not the people and departments ordering this unhealthy fare—has been piling on the pounds. The result is a bloated application portfolio, redundant data, and complex duplicative infrastructures. The business does not see the weight gain.  These are two areas that cannot transform without the business at the helm pushing for a new lifestyle.

Cloud computing requires a new lifestyle.

When the assumptions fundamentally shift, incremental improvement that addresses “change” is the less-able brother of transformation. Incremental change typically occurs by examining what’s not working with the organization and then taking a modest step forward. Like a house inspector looking for cracks in the foundation and other imperfections, a list of problems is assembled. Estimates are then formed for all the repairs, and you may find that you have neither the time nor the resources to fix them all. Therefore, a small number of the achievable modifications are chosen to make the house more livable, slightly more efficient, and less prone to breakdowns. But many assumptions and constraints remain the same.

Transformation is different. Life changes present the opportunity for individuals to transform themselves. Yet many look to incremental change when it is incapable of yielding the transformation they seek. Sometimes we need a new house, yet we falsely believe that incremental improvement will achieve the same thing. The IT castle we have created...

• prone to leaks...
• constantly needs repair...
• only keeps out the casual bad guy...
• costly to maintain...
• difficult to remodel, and
• no matter how much we remodel it...

It still doesn't seem to be what we need. It's time for something really new. 

Cloud computing could provide the vision for a new lifestyle, but my concern is that our ravenous hunger for comfort food will just keep packing on the pounds for IT.  Cloud must support a paradigm where interoperability is a forethought; where security, identity, and entitlements are a fundamental part of a service's invocation; where the compromises we make about data do not expose us more than we are; and where the utility we dream it to be does not fade like Camelot.

Look at IBM's announcement for a private cloud appliance as an example.  Create an appliance that runs a virtual machine, runs Websphere applications, and slap a cloud sticker on it -- PRESTO -- Cloud Computing is Here! NOT!!!  It seems to leave out policy enforcement and operations management aspects of cloud.

Then listen to Larry Ellison.  His sarcasm is evident as he says cloud computing describes everything we've ever done or will do. I agree that if it is not truly different, then we are only having another heaping serving of comfort food.

Mr. Elllison continues on to say, "I don't know what we would do differently in light of cloud computing". It seems to me that many vendors do not and sales of "cloud ready" stickers are set to skyrocket.

If we truly intend cloud to revolutionize IT then it must be revolutionary.  Beware of new stickers that suggest doing the same thing will give you a new result. 

The Negative Effects of IT on Ancient Culture

Posted by Mike Rollings (aka M7580624892)

I could hardly believe the article in the New York Times yesterday "Your Name's Not on Our List? Change It, Beijing Officials Say".  This article is a sad testament to how restrictions imposed by information technology affect the names Chinese citizens can give to their children.

The Chinese government has a new identity card. The character recognition software used can only recognize 32,252 of the roughly 55,000 Chinese characters. As a result, 60 million Chinese citizens cannot get new cards. But the unique combinations of characters that form names makes it even worse. The government list of names will include only 8,000 characters. As a result, people with unique names that do not make the cut are being asked to change their name. "Mike we have determined that our IT systems can only recognize one letter in your name, so we would like you to be named M."

This is not just a folly of a government's inability to protect its culture, it is a profound example of IT limitations imposed on a fundamentally human quality - individuality. But, IT limitations do not need to be as profound as human individuality to take note of this problem. We don't need to look far for other examples of where a technical limitation imposes, sometimes hidden, restrictions.

One example is the limitation imposed by the carrying capacity of data formats used inside the IT systems we create. Limitations like field length that exist in many IT transaction systems cause organizations to reduce the meaning of the information the format is meant to convey because it does not fit the carrying capacity of the format.  The impact is compounded as data flows from one system to another, each with their own format and length quirks, adding to the reduction in information fidelity. 

Information fidelity is a problem for almost all organizations, but the business is unaware of just how messy the information environment is. My friends in our Data Management Strategies coverage area have a deep understanding of data quality and data interoperability issues like this.

Back to the Chinese ID card for a moment... Maybe the IT project started with the fact that 100 surnames cover 85 percent fo China's citizens versus 70,000 surnames covering 90 percent of Americans. So what's the big deal? We increased the number of names that people can have - deal with it! The IT assumption being an increase in the number of names recognized is good enough.

I'm sure there was a reason for the limitation, but I think the original assumption needs rethinking. If you assumed citizens could have any name, and you have an ID card with a unique number for every citizen, do you really need to have a registered name that can be recognized as an authorized character combination? Couldn't you just treat it like a string of Chinese characters till the software improves? Perhaps there is another way around this issue.

Maybe the assumptions have been questioned, but it is concerning in a broader respect. Has IT become complacent about these types of limitations to the point where we unconsciously obscure the affect of these limitations and as in this case undermine ancient culture?

CIO Magazine "Do You Need an Enterprise Architect" - Way off base

Posted by Mike Rollings

In the CIO Magazine article "Do You Need an Enterprise Architect?" the Alok Kumar, CIO Reliance Infosolutions, suggests that the ambivalence around whether architects are needed is representative of the role's continuing evolution.

I disagree. I don't believe that this is representative of the role's evolution or that the article accurately portrays an architects role. It reflects a designer's role. Also, I don't see the hiring versus contracting to be the key.  It is the expectation of the role that is the most important and the views expressed in this article are counter productive to success.

Mr. Kumar states "If, today, large organizations have hundreds of databases and as many silos, he says, 'it's the CIO who created those databases'. There needs to be someone on his team who can fix that."  Then a little later "While the lack of will to hold on to their architect probably had something to do with the nose-diving economy, what's telling is that he was not replaced." (No points for making the CIO the scapegoat, but we'll ignore that right now).

No big surprise here.  First you define the enterprise architect as a master technician, then set an unreasonable expectation that he will fix all the problems, and then define their value add in terms of making a single project's environment agile.  The strategic problems will never be solved by someone you hire as the technical fix it person!  Also, no amount of technical simplification will solve a problem created by a culture that creates silos and duplicative databases.

What is EA?
Burton Group defines Enterprise Architecture (EA) as follows:

Enterprise architecture (EA) is a planning, optimization and design discipline that is fundamentally based on dependency, implication and constraint analysis. It results in a set of artifacts that capture and communicate aspects of design.

The artifacts associated with the EA discipline include:

• The enterprise operating model
• Business strategies
• Dependencies (i.e., process, information, application, and infrastructure)

Every organization practices the design and engineering aspect of architecture. But as I describe in the Burton Group Perspective document “Enterprise Architecture is More than Engineering,” a primary benefit of EA comes from facilitating collaboration. This collaboration results in the ability to develop a shared understanding of a particular undertaking along with its dependencies, implications, and constraints and permits that perspective to be reflected in the discussion of trade-offs and the resulting design. The collaboration informs the decisions to improve the result. To facilitate this collaboration, EA is managed as a process discipline. This attention to the practice of architecture forges consistency and monitors the improvement of results.

Making EA relevant

Making EA relevant in an organization requires more than the application of brute force. It involves relentlessly pursuing business outcomes and applying the combination of influence and integrated governance to improve the IT decisions influenced by architecture. The most successful EA programs influence many types of decisions. In fact, the majority of outcomes influenced by EA will be those over which the EA competency owner does not have any direct control.

Enterprise architecture is an important set of skills and processes that improves IT decision-making and contributes to business value. Many organizations struggle to succeed without a clear definition of EA success and the ability to measure it. Maturity models are helpful, but must be carefully applied to avoid their pitfalls.

To measure EA success, an organization must first develop an understanding of EA’s expected contribution to business outcomes. Then, it can focus on using assessments to improve the EA discipline, improve the integration of EA with other IT processes, and examine the real and perceived contributions made by architecture.

Vitality of the City - No EA equivalent.

Posted by Mike Rollings

Below I captured some of Ada Louise Huxtable's comments from her Charlie Rose interview. She is a renowned impassioned critic of architecture. Her new book will be a must read for me! 

Modernism defined - the rejection of the past and using new materials to solve problems introduced by a need for new building types.

The building at the Guggenheim in Bilboa, Spain an iconic example of Modernism. The AT&T Chippendale Building on Madison Avenue represents an awful period of post-modern architecture where we lost creativity and beauty. Jim Sterling's art museum building in Stuttgart is credited with the beginning of Modernism.

Many architects have lost the art of planning "so much emphasis on the dramatic that many have lost their sense of humanity - architecture is for people." For all its value, Modernism also inspired acrobatic architecture without reason.

Architect Frank Gehry starts with sketches, models in cardboard, studies the relationship to the space, and the relationship to the plan for use. Architecture without the examination of humans interacting with the space is not architecture. Space for technologists needs to be expanded. A building architect examines the entirety of space -- the room, the floor, the building and its relation to the environment around it, and how it is perceived as part of the city. Space is studied from the perspective of the people experiencing the space, not the perspective of the building. You cannot limit your perspective to a single part of space and say it is the same as examining the whole.

She is a believer in the vitality of the city. This concept allows architecture to be expressive while meeting the functional needs of the real estate developer. The developer can do what they need to do with a little bit of planning and design. To be creative in your design does not mean to double your expense.

Applied to information technology, we do not have the equivalent spirit or sense of humanity with which we establish a guidepost for our architectural work. We do not have an equal concept "for the vitality of the city". To slightly twist a concept from Bob Blakley - perhaps from the re-introduction of people into our concept of architecture the definition of "city" will erupt. A new environment that is social, spacial, and fascinating to work within. The modernism of IT is the emergence of digital metaphor in which people conduct their inquiry, transact, and interact with other people, businesses, and other avatars of our physical world.]

Architecture is for people. This is a great reminder for all architects that strive for the technical sophistication. But Architecture without the examination of people's perception of space is not architecture.

We have computer systems architecture, yet it is the study of computer systems and not the human perspective that defines the discipline of architecture. The consistency of space is done one compartment at a time. We do not have a concept of "city" into which we are plugging the building. You might say "sure we do", but that perspective is solely the physical connection into the whole, or if UXP it is the interaction of the human with the single thing you are building. It is like examining how to pier the building, connect it to infrastructure, connect it to the adjacent buildings, but not concern yourself with the human perspective of that space and surroundings.  No equivalent experience exists in computing to that of a city -- the digital metaphor in which the consistency of the whole can be examined from a human perspective.

Perhaps the great advancement of the 21st century will be to incorporate graphic design, behavioral psychology, and social science into the computer solutions of our time. Perhaps we will do architecture.

Is BI Relevant?

posted by Jack Santos

Business Intelligence (BI) is an area that gets sporadic, almost schizophrenic funding in most business organizations.  Some businesses do it well, often led by a visionary business leader that understands the need for insight derived from real, accurate data.  Most businesses define BI departments, which become a focal point for analysis and report tools (like Cognos), or degenerate into a repository for standard reports. Data warehouse bloat is a side effect of the lack of commitment to world class BI.

Sometimes the vision for BI in an organization gets mired in the muck of data.  I have been reviewing our research into data and information management technologies – and there is a lot of good advice there (I’ll be writing about it in an upcoming EAP document).

But for a real eye-opener about data, information, and how to mine and display it (especially with readily available public sector databases) – no video does it better than this one (Thanks to Burton Group CEO Jamie Lewis for bringing it to our attention). 

In the video, Hans Rosling’s insights raises up the quality of discourse about public sector policy; he also shows off what the result of effective BI could look like for most businesses.  The tool/techniques are further explored at Gapminder.org, and really brings longitudinal studies to life.   It’s in Google spreadsheets NOW, and shows that the desktop office software market is undergoing some renewed competition and innovation, due in part to Google Docs.  No doubt the specific tool will be an add-on to Excel next year…

Good stuff.