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." 

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.

Research and value

posted by: Jack Santos

I’ll take a different tack on this post, and be a little more introspective about this role I am in.  It’s been about 18 months since I took on this position at Burton Group...and it’s been a tremendous amount of fun and hard work…

A couple of recent meetings with CIO friends, and a few discussions with clients and prospects, prompted me to think about what I am doing. 

I am actually a very lucky guy. In a wonderful marriage with an exciting woman, 5 great kids, and a job that I look forward to waking up to every day – in fact, often get up early just to start it, and find myself still at it 9 PM at night. 

Unlike being on the front lines (which I have been over 30 years), I made a conscious decision when I joined Burton Group to pick a role that was in many ways less stressful (in other ways more), that had no one to delegate to, or performance reviews to do, less real management responsibility, a bit more travel, constant exposure to new faces and networking, less corporate responsibility, but more informal responsibility for the advice  I give to many – which I take very seriously.  After spending the first 30 years of my career doing, I can give back and spend the next 30 advising.

Unexpectedly, my role as CIO Executive Strategist has become a nice blend of experience, geek interests, and my wife’s vocation: psychotherapy.  More on that in another blog entry.

What has been fascinating to me are people’s perspectives on the role of an industry analyst, or the value of an analyst firm.  I certainly had a viewpoint before joining Burton Group, which alternated from viewing analysts firms (like many vendors) as a mix of anything from shysters, to business enablers, to real partners.  But the conversations I have often times start with a real challenge – or what the prospects perceives as a challenge – as to why Burton Group is necessary or provides value; or (more personally) why they should listen to me.  Here are some of the more frequent objections, and my observations/responses.

1) We can use Google– why do I need you? I can find it myself.

This presumes that everything on the Internet is accurate, easily discernible, and clearly in agreement.  What I find key to what I do now is experience, judgment, strong critical thinking skills, and detachment from the customers problem – all of which are important in coming up with insight and advice.

2) You guys are just ambulance chasers; I get the same content from <pick your industry trade journal>, the Wall Street Journal, the New York Times, or any variety of publications.

Unfortunately, modern media (Internet included) is very susceptible to the amplifier effect.  One source says it, and the same single story gets repeated, sliced, diced, and presented as fact in a million ways.  Sometimes even fundamentally changed. It’s easy to fall victim to it, and become part of this massive ponzi scheme-like effect that has only gotten worse with the advent of the Internet, and real-time Google-accessible content.  Someone, with in depth technology experience and healthy skepticism, has to sort through the media – and not be afraid to call out the emperor on his lack of clothes.  Unfortunately, the amplifier effect does cause an ambulance chasing type of culture – not just in IT (note the current swine flu coverage).  I also am a firm believer you get out what you put in (capitalist karma); or, as the cliché says: You get what you pay for – often true for both Google searches, and media freebies.

3)  I have a real network – SIM, CIO Leadership forum, CIO Executive Summit, CHIME, my local group that meets for lunch. Peer relationships are important. I just want to hear what my peers are up to. I don’t need analysts.

My personal network is critical, and it should be for every executive.  It’s an opportunity to vet what I hear, get new ideas, and, when I need to, stay with the herd.  I don’t stay with the herd all the time, and even when I do, I may make changes, and vary from the herd for the details.  That needs advice from people that are herd-flirters; they flirt from herd to herd, sometimes within industry, sometimes across industries. Innovation and creativity often times doesn’t come out of thin air, but from the application of different ways of doing things from different industries. 

4) We are a multimillion/billion/trillion dollar company. I have as much, if not more, access to our suppliers/vendors/industry shakers.  A corollary: I rely on my suppliers/vendors to provide advice and analysis of key issues and trends.

In my career, I have sat across the table (or been sitting in the next office) from many major IT industry thought leaders (Microsoft’s Gates & Ballmer, Apple’s Jobs & Allen Kaye, IBM’s Palmisano and Gertner, Sun’s Schwartz and McNealy, Google’s Schmidt).  The companies I have worked for had access, because of the enormous sums of cash we spent with a vendor. There are two rules that I’ve learned: thought leaders put their pants on one leg at a time, just like the rest of us (pants suits for the ladies ), and vendor opinions requires the most skepticism – it’s not like they don't have a conflict of interest.  With millions of dollars at stake, I always felt the extra dollars for someone’s opinion that doesn’t have a dog in the fight is worth every penny.

5)  You don’t know my business as well as I do. How can you advise me?

Fortunately, a company like Burton Group does have a fairly broad pedigree of analysts that may know your business as well as you do – and because of exposure can even apply lessons learned from other industries.  Almost every conversation I’ve had, though, doesn’t require detailed in-house vertical business expertise, especially at the executive level; it requires detachment, common sense, critical thinking, and experience.

6) I pay my team to be as good as you; I expect from them the same knowledge and analysis that you provide, and they should do it without help.

I usually hear this as a last resort.  It’s an attractive cop-out, because it displays confidence in your staff, your ability to pick people, and the amount of emphasis your organization puts on solid, well thought out, decision-making.

But the fact is your staff is there to focus on your internal clients, and lead your organization.  That takes a lot of time and effort.  They are there to not only provide you with insight and expertise, but your business users and your IT department as well.  There is no way that they can put the time into that AND into understanding industry trends, and detailed technology strategies (independent of what your company is doing)—I know because I do that full time, for multiple companies.

If you feel that you should pay top dollar and insource that – god bless and good luck; some Fortune 100s think they can, but find out that sourcing that from the outside is not only more cost effective, it’s also more idea effective. It’s a matter of putting the right people in the role that they have the most opportunity for success, and the most impact.  Your folks should be focusing on YOUR business.  People like me help them do that by focusing on everyone else's business.

Having been on both sides of this equation now, that’s how I see it.  How do you see it?

Comments welcome.

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?

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.

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.

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.