By Balasubramanian Somasundram, Honeywell Technology Solutions Ltd.
Well, contrary to this blog post title, I am not going to talk about the finer details of preparing a business case for an Enterprise Architecture initiative. Rather, I am going to talk about ‘What makes the client to ask for a business case?”
Here is a little background…
Statistics assert that only 5% of companies practice Enterprise Architecture. And most of them are successful leaders in their businesses, not just IT.
When I attended Zachman’s conference last year, I was surprised to see Zachman being cynical about the realization of EA in the industry. He, in fact, went on to add that it may take 10-20 years to see EA truly alive in companies.
I am also closely watching some of the Enterprise Architects’ blogs. I don’t see convictions by looking at their blog posts titled – ‘Enterprise is a Joke’. ‘Enterprise Architects do only powerpoint presentations’. ‘There are not enough skilled architects’, etc.
In the recent past, when I was evangelizing EA among the top IT leadership, I often got questions on ‘short-term quick hits that can be achieved by EA’. That’s a tough one to answer!
Now the question is – ‘Why there is lack of faith in IT?’
And many of us know the answer – Because the teams often fail to deliver, despite spending lot of cash, effort and energy. The harsh reality is that IT does not believe in itself that it can deliver something significant, valuable and comprehensive.
If IT doesn’t believe in itself, how can we expect business to believe in us, to treat us like partners and not as order takers?
Now, getting to metrics… I happened to read this revealing Datamonitor whitepaper on the EDS site. Though the intent of the paper is to analyze the maintenance issues Vs adopting new innovations in existing applications, I found something very relevant and interesting to our topic of discussion here.
Some of the observations are:
- IT departments that are overwhelmed by application maintenance do not see the benefit of planning
- Datamonitor believes that skepticism of these overwhelmed decision makers can be largely attributed to a sense of ‘hopelessness’ or ‘burn out’ over formalized IT strategies.
- Such decision makers are operating in a state of survival rather than one of enthusiastic optimism
- IT departments see the value of planning primarily in the ‘build’ phase and not in the ‘run’ phase. They don’t really care too much about the ‘lifecycle’ of those application in the ‘planning’ phase.
- And now, this compounds the maintenance complexity and inhibits the company from embarking into new initiatives – creating a vicious cycle.
What a resounding observation!
As someone said, adopting EA is like a lifestyle change – like following a fitness regimen. And that cannot be realized without discipline and commitment to change! The problem is not with EA but the way we look at it!
Balasubramanian Somasundaram is an Enterprise Architect with Honeywell Technology Solutions Ltd, Bangalore, a division of Honeywell Inc, USA. Bala has been with Honeywell Technology Solutions for the past five years and contributed in several technology roles. His current responsibilities include Architecture/Technology Planning and Governance, Solution Architecture Definition for business-critical programs, and Technical oversight/Review for programs delivered from Honeywell IT India center. With more than 12 years of experience in the IT services industry, Bala has worked with variety of technologies with a focus on IT architecture practice. His current interests include Enterprise Architecture, Cloud Computing and Mobile Applications. He periodically writes about emerging technology trends that impact the Enterprise IT space on his blog. Bala holds a Master of Science in Computer Science from MKU University, India.
“it may take 10-20 years to see EA truly alive in companies”
I don’t think that will be the case. At that time we have new generations (Y and Z) at work and new types of command and control like self-synchronization and self-organization. Enterprise Architecture is central planning and that will be considered legacy at that time.
(not just my crystal ball but the foundation for a whole transition program at DoD)
Yes and No Peter! 🙂
When Social Networking concepts take roots in Enterprises, new management models may evolve and it may obviate the need for centralized functions. We’ll have to wait and watch!.
But, Remember, we still work in management models that were invented in industrial era. No radical workplace transformation Generation X has made in the last couple of decades.
I think more than EA, the individual functions within EA may get practiced under various names in future.
Most guides to developing a business case I have seen include a section that requests a description of the problem being solved.
My questions are:
1) What business problem does Enterprise Architecture solve?
2) What business problems do Enterprise Architecture projects solve?
Enterprise Architecture is a solution. The value of a solution exists in the problem it solves.
Unless you can demonstrate that EA is solving a problem and get the business to agree on the value of solving that problem, the business will ignore EA.
So what business problems does EA solve?
Great Question Bernard!.
In addition to the question that you have asked – What problems does EA solve?. I would another question – How is EA uniquely positioned to solve those problems?. Why not other management methods/frameworks to solve those problems?
This is exactly our topic of our discussion in the upcoming Open Group Conference in India (Chennai location). Pls check the abstract here:
http://www.opengroup.org/india2011/bala-mohan.htm
My intent of this post is to highlight the fact that, the need for business case is ofen insisted upon, not because of the ambiguity in perceived value of EA, but because some of the organizations are overwhelmed in operations that they see no value in planning.
To try to make a business case using costs and revenue (which is what 99.9% of what business cases are) is a mistake when justifying EA.
One of the problems that PEAF addresses (no other framework does) is that usually an organisations business case template is fundamentally flawed. And that is one (of various) reasons why trying to business case justify doing EA is fundamentally flawed.
The business case for EA (and for anything else for that matter) should include other measures/criteria in addition to money. i.e. the goals of EA (as defined by PEAF) Effectiveness, Efficiency, Agility, Durability, and the Strategies for achieving those goals (as defined by PEAF) Manage Cost, Manage Risk, Manage Quality, Manage Flexibility.
If business cases were rated using all eight of these criteria (instead of only one of them – Cost) then organisations would be making much more well informed decisions and any implications would be exposed and accepted when the decision is made and not stumbled over at some indeterminate point in the future with often massive implications.
In addition the business case justification for utilising EA products and processes using this format would be a brainer.
Agreed Kevin!. The business case doesn’t necessarily orient towards cost aspect alone.
The business case should ideally be developed in the currency of the respective company. The currency is typically cost, security/risk reduction or agility/revenue or customer services. It should be understood by the enterprise architect and the business case should be communicated in the same currency appropriately.
@Kevin,
Re : the goals of EA (as defined by PEAF) “Effectiveness, Efficiency, Agility, Durability”
This may or may not be true – however a particular enterprise might not value some or all of these – after all they come at a cost. The only way (IMHO) to identify if they are of value to an enterprise is to relate them to one or more business problems. In that way the business can work out what value these “goals” are to them.
As I asked before – what business problems does EA solve? If that question cannot be answered – to the business, then it’s all academic.
Bernard,
IMHO, Enterprise Architecture doesn’t directly solve a business problem. It helps/enables to solve a business problem.
In fact, EA does solve only a management problem. It helps to reduce the management complexity of the enterprise and enables achieving the business goals in a systematic approach.
@Bernhard: “This may or may not be true – however a particular enterprise might not value some or all of these – after all they come at a cost. The only way (IMHO) to identify if they are of value to an enterprise is to relate them to one or more business problems. In that way the business can work out what value these “goals” are to them.”
It’s not a case of maybe its true. It is true.
Can you tell me any organisation that does not want to be effective? or does not want to be efficient? or does not want to be agile? or does not want to be durable?
These are the fundamentals that EA helps with. You do not need to relate them to specific business problems to accept that they are goals of the enterprise. You do however need to relate any change resulting from solving business problems back to them to make sure those changes do not have a detrimental impact on them, or if they do then that impact is know, understood and accepted.
Yes, some decisions may take a hit on one goal to better achieve another (e.g. a particular decision about a change in the organisation may sacrifice a little agility to obtain more effectiveness, or may sacrifice some efficiency to obtain more agility) But they should still be part of the list of strategic goals of the enterprise.
Of course if the board decides that Durability (for example) is not an important strategic goal for that organisation then they are perfectly within their rights to remove it. However, it is part of the EA’s role to explain to the board the impact and implications of removing Durability (or Agility or Effectiveness or Efficiency) as a corporate strategic goal. And not least, how to explain that to the shareholders.
@Bala: “IMHO, Enterprise Architecture doesn’t directly solve a business problem. It helps/enables to solve a business problem.”
100% agree. This is the crux. EA does not produce business benefit. It allows others things to produce (more) business benefit. EA is an enabler. This is why trying to cost justify a business case for doing EA is fundamentally flawed. EA is not a project, it is a continuous process. Yes there will be a project to implement the changes required to operate EA but that project has not immediate payback. That project plants the seeds. The payback comes from the crops that grow from those seeds. If you want to reap today you must have sowed yesterday. In order to achieve the organisations goals that EA is linked to (i.e. Effectiveness, Efficiency, Agility and Durability) at some point in time, you need to have done the work to achieve them in the past.
This is the catch 22 of EA – you are trying to “sell” something today (EA) that will not reap benefits “today” but will reap them in the future and since 99.999999% of people in an organisation don’t really care about the future (it’s all about quick wins, saving costs today, increasing revenue today, fixing todays problems) that is an almost impossible task and that’s one of the reasons its difficult to “sell” EA especially in a business case.
“Selling” EA (like EA itself) is cultural – and that’s all about communication – and that’s all about talking to people.
“Selling” EA is a conversation not a business
“Selling” EA is a conversation not a business case.
Kevin,
In these days of post-recession and cost control, every single dollar is accounted for. Though EA is an enabler, I believe, We should be able to put together a business case in dollar terms, as it’s very similar to any other enablers – like SEI CMM Level 4 for Software Engineering, COBIT roll-out for your IT organization, ITIL roll-out for operations – all these frameworks one way or ther other contribute to efficiency and effectiveness. And EA is meant for similar outcomes. It should be possible to put together a case.
So far everyone has covered trying to justify the strategic side of EA. However, justifying the tactical side is often enough of a driver for the acceptance of an EA function. A large percentage of EA time is spent on tactical solutions to immediate business problems. If that makes 99.999999% of the people happy then an EA function should be an easy sell. The strategic side will come. Often an EA function has to be opportunistic and implement a strategy through leveraging tactical projects. The key is getting EA involvement so each project is a step in the right direction. By fixing the immediate problems, that involvement will come.
@Ian: “A large percentage of EA time is spent on tactical solutions to immediate business problems”
Not it isn’t. That is absolutely not the purpose or the driver for EA. And anyone working on “tactical solutions to immediate business problems” is about as far away from EA as it is possible to get without writing code.
99.9999999% of the organisation is already concentrating on “tactical solutions to immediate business problems” THAT IS THE PROBLEM.
They do that because they do not utilise EA practices and products to do a modicum of strategic planning which would prevent things becoming problems for which they then have to concentrate on “tactical solutions to immediate business problems”.
This does not mean of course that that immediate business problems may get tackled – but that is only as a side effect of doing EA.
@Ian: “The key is getting EA involvement so each project is a step in the right direction.”
Agreed – by defining some strategic principles that cause bad behavisours to be exposed as Enterprise Debt when project execute, so that business decisions can be taken whether to accept the debt incurred or to take steps to avoid the debt being incurred.
@Ian: “By fixing the immediate problems, that involvement will come.”
No it will not.
Trying to fix immediate problems is one of the surest ways to fail at EA.
@Kevin “[Tactical Work] is absolutely not the purpose or the driver for EA”.
I tend to agree, but you have to be a realist not a pureist to succeed. It may not be our purpose but it demonstrates immediate value.
@Kevin “Trying to fix immediate problems is one of the surest ways to fail at EA.”
I disagree. It’s the foot in the door. If you don’t show value immediately, you will fail in most organizations – especially in todays economic climate. It’s an opportunistic approach to strategy implementation. Define the long term, implement the short-term steps to get there. A lot of EA teams do not have budget and have to rely on client funding. Unfortunately this is the world we live in.
@Ian:”@Kevin “[Tactical Work] is absolutely not the purpose or the driver for EA”.
I tend to agree, but you have to be a realist not a pureist to succeed. It may not be our purpose but it demonstrates immediate value.”
I am not being a purist. I am being pragmatic. The “you are being a purist” line is a common joker in the pack that is brought into service usually along with the “Buit this is the real world” and other comments that are banded about as sticks which which to win any point.
The point is, fixing tactical issues is not doing EA. It might be useful. But its not EA.
I have copied below an excerpt/quotation that I have in the PEAF training slidesets….
(It’s on slide 26 in the Culture slideset at http://www.pragmaticea.com/peaf-products2-culture.htm)
It says… (MVP=Most Valued Person)
“In many organizations, despite any rhetoric to the contrary, people are rewarded for dealing with crises and problems. The MVP is the one who came in at 3 a.m. to fix a problem, or who reacts instantly to the customer’s complaint. Such an organization overlooks the fact that these MVP’s are putting out fires that either they set themselves and/or they failed to do anything to prevent.
Then when we promote the MVP, we wonder why nobody follows any processes and everyone is always too overloaded to get anything right the first time. Why? Because that is the behaviour that is rewarded.”
– Douglas Brown
Chief PMO – US Department of Defense
If you start by tactical problem solving, you are part of the problem, not the solution. The solution that is EA.
@Ian: “@Kevin “Trying to fix immediate problems is one of the surest ways to fail at EA.”
I disagree. It’s the foot in the door.”
It is the deadbolt on the door.
@Ian:”If you don’t show value immediately, you will fail in most organizations – especially in todays economic climate.”
If you show value immediately you are not doing EA. So if you show value immediately you are failing at doing EA.
I think exactly the opposite is true…
– If you show value immediately, you will fail [at doing EA] in most organizations [because by definition you will not be doing EA]
You may be sort of correct in what you say but if the organisation thinks EA is about solving tactical problems, then they do not understand EA and since there is already too much misunderstanding about EA, the worst possible thing you can do is to solve short term tactical problems and call it EA.
EA is about sowing seeds, not harvesting the corn. If you try to do/sell/explain EA by showing that you can harvest the corn more efficiently you are totally missing the point and so will the people you work for.
@Ian: “A lot of EA teams do not have budget”
Then its not an EA team. EA sits outside and above projects. EA is an infrastructural capability like datacentres. You can’t fund a datacentre from a project.
I think we agree on what EA is, where it should be positioned in the organization and what we SHOULD be working on. I also like your analogy with data centers as a funding model. Where we differ is on establishing the team or, where this thread started, the business case to support it.
It seems my experience isn’t unique. The Enterprise Architecture Executive Council did a study into the formation of EA groups (https://www.eaec.executiveboard.com/Members/Topics/Abstract.aspx?cid=100248445). Here’s snippet:
“Three common failure paths repeatedly trip up new EA groups:
1. EA as “ivory tower”. New EA groups focus on long-term strategies and target architectures, in the process detaching themselves from on-the-ground realities in their organizations.”
2. EA as “police”. New EA groups put too much on emphasis on governance activities, creating the perception of EA as a bottleneck rather than an enabler of solutions delivery.
3. EA as “naval gazer”. New EA groups become consumed with documenting the architecture, adopting an EA framework, and mastering complex EA tools, losing sight of IT and business priorities.”
… and the key line
“Successful new EA groups strike a balance between short-term value demonstration and the pursuit of long-term vision.”
Hi Kevin,
Agree with you on the fact that EA shouldn’t be positioned against solving tactical problems. Then, the purpose itself is lost!.
As you had mentioned, yes, investing in EA is like data centers. Its a common expense. You can’t charge it a specific project. However, pls note the difference – data centers are utilities and you can utilize in a project and charge back the consumers. In EA case, it is definitely not a utility. If its treated like a utility, then it would lose its strategic value. It would only sustain if its treated as a strategic function and the initiative demonstrates a value that can be articulated in a business case.
@Bala: “As you had mentioned, yes, investing in EA is like data centers. Its a common expense. You can’t charge it a specific project. However, pls note the difference – data centers are utilities and you can utilize in a project and charge back the consumers. In EA case, it is definitely not a utility. If its treated like a utility, then it would lose its strategic value.”
It is a utility and will be charged to projects in the same way that other strategic assets for change are. It is precisely because it should be treated like a utility that gives it the strategic value.
EA sits above all change projects and above strategic planning and provides services to both sides to glue strategy to execution.
@Bala: “It would only sustain if its treated as a strategic function and the initiative demonstrates a value that can be articulated in a business case. ”
Agreed EA will only be sustained if it is treated as a strategic function but EA cannot be articulated in a business case. EA provides no value in itself. EA only exists to allow other things to provide better value. EA doesn’t do strategic planning, it supports it. EA does not make strategic vs tactical decisions on project as they execute, it supports it.
In this way, EA is a little like any tool, like a drill or a hammer. They have no inherent value or business case in themselves. The value or business case comes when you choose to utilise them to do something. You do not see the benefit of using the hammer until you use the hammer. So if you try to create a business case for a hammer on its own without any context or application you can’t.
And the problem with EA is worse because of the time element, you need to have sown the seeds before you can reap the benefits and there is a time lag between sowing and reaping.
Here the hammer analogy breaks down because there is no time lag between identifying that a hammer may help and obtaining the hammer. The hammer can be “bought” when it is needed. EA needs to be “bought”/invested in before you need to/want to use it.
And this time lag is the cause of many organisations non investment in EA….”You want me to spend money now so I can (perhaps, because you can’t prove it to me) save more money in the future????? Are you crazy, we don’t have enough time and money to fix all the tactical problems of today let alone worry about some airy fairy future…….we don’t live in a perfect world… blah, blah, blah, blah, blah, blah”
They do not see that they are the architects of their own demise.
@Ian: “Three common failure paths repeatedly trip up new EA groups: ”
There are many more than 3 risks/misconception that repeatedly trip up new EA groups.
They are documented in the Risks document in the Foundation Section of PEAF at http://www.pragmaticea.com/peaf-products1-foundation.htm
And the common mitigating action mostly comes down to communication, which is one reason why I say that communication and culture is the backbone of EA.