Reasons For IT-Business Misalignment (Part 3)

July 1, 2008

I my last post I listed 4 causes of the misalignment between business and IT. In this post I continue the list.


Reason 5: Implementers have insufficient domain knowledge.
Obviously IT folk need to understand IT – but that’s the bare minimum required to be effective. It’s important to understand the business and industry that you’re operating in. Without sufficient domain knowledge you can’t communicate effectively with the business and this leads to countless problems (e.g. instead of requirements gathering you ‘take orders’)

Solution: IT folk need to learn the business (and industry) they work in.

Reason 6: IT building itself into solutions.
It’s generally accepted that typical IT Department’s spend roughly 80% of their budget on maintenance and 20% on new initiatives. The are many reasons for this but the main one (I think) is that IT Departments build themselves into solutions. In many cases, IT delivers all the features the business wanted but neglect to factor in all the “behind the scenes” things that are needed to operate the solution (e.g. maintenance screens, report writing tools)

Solution: Build complete, end-to-end solutions that don’t require constant hand-holding from IT.

Reason 7: Line of business instead of enterprise focus.
We know that most IT solutions are developed for a particular business unit. This is largely down to organisational factors (e.g. funding models, governance) and the result is a large number of siloed solutions. And here’s the problem. When a new business initiative starts, every department prepares accordingly (e.g. policies, procedures, staff training etc). Part of the preparation involves burying the IT Department in ‘change requests’. Marketing sends their requests, sales sends their, accounts want changes and so on. And of course IT is notified at the last minute – when everything else has been done. IT can never hope to manage this sudden peak in workload.

Solution: Take an enterprise-wide approach to IT solutions. LOB thinking is not sustainable.

So that’s my 7 reasons why IT cannot keep pace with the changing business needs. It’s not caused by a different pace of change (business changing quicker than IT) – the causes are largely due to timing (business getting a head start) and direction (IT going off on tangents).


Reasons For IT-Business Misalignment (Part 2)

June 30, 2008

I my last post I said that the cause of the misalignment between business and IT is not caused by different pace of change. IT can change as quickly as the business – but it doesn’t. This post lists some of the reasons for this.


Reason 1: Business always gets a head start.
Given its relatively lowly position in most organisations, IT is always the last to know about what is happening – IT isn’t “kept in the loop”. The business can spend months planning something but IT is often contacted at the last minute and is forced to cobble together a solution in impossible timeframes.

Solution: The business must keep IT in the loop. The earlier in the process the better.

Reason 2: Poor solution development methodology.
Many IT Departments are ignoring modern best practice and continue to use outdated waterfall methodologies or work on multi-year projects. It doesn’t work. And history tells us it’s never worked. And I’m not talking software development specifically. The same applies to any IT project (e.g. implementing a new content management system).

Solution: It’s time for IT to get with the times. Develop interactively. Deliver early. Deliver often.

Reason 3: Trying to predict the future.
If you can predict the future I suggest you channel your talents toward pursuits other than trying to predict future business requirements. Most business will prefer to get something functional today than wait for something with bells and whistles. Don’t over-egg the pudding. If you can’t trace the work you’re doing right now to a business requirement then stop doing it.

Solution: Adopt the YAGNI principle. Learn to say “you aint gonna need it”.

Reason 4: Short-sighted views.
Some fall into the exact opposite trap of Reason 3 and build for the ‘here and now’ but don’t even consider what may be needed tomorrow. You need to find a balance. Some changes are easy to predict – factor them into the design.

Solution: Do things today in ways that doesn’t close any doors that may need opening tomorrow. Build extensible and easily maintainable solutions.


The Project Portfolio Approach to SOA ROI

February 18, 2008

Erich Roch proposed an interesting approach to calculating SOA ROI, which he called the ‘portfolio based ROI calculation’. This approach “analyzes a set of candidate projects for ROI project by project and adds up the cumulative value of SOA across these projects.”I think approach is a great idea and I’d be keen to hear from anyone that has used this approach in practice – especially if you can help answer some of the questions below.


I recently read an excellent post by Erich Roch entitled SOA Costs and ROI. He proposed a very interesting method of calculating ROI which he called the “Portfolio Based ROI Calculation”. Actually he proposed a few interesting methods (so please read the whole post) but this one grabbed by attention.In a nutshell this approach:

“analyzes a set of candidate projects for ROI project by project and adds up the cumulative value of SOA across these projects. Part of IT’s strategic plan is often a project portfolio that has cleared corporate ROI hurdles and been approved by the organization. These projects are ideal candidates to analyze SOA ROI potential.”

Intuitively, this seems like a great approach to calculating ROI but I think a few questions need answering.

1.Is this approach still feasible if a portfolio of projects DOES NOT exist?
In my mind, the ideal scenario for employing this approach is when a portfolio of approved projects already exists. This is because:

  • Someone has already done the ‘leg work’ in terms of analysis, planning and costing. All that is left to do is evaluate how the use of SOA will improve the project ROI. This should be relatively easy to do. And quick.
  • You will in effect be proposing to take existing projects which are already attractive to the business (since they were approved) and demonstrate how they can be improved even more. More benefits. Same (or less) cost. Better ROI. This is as close to a ‘free lunch’ as you’re ever likely to get.

However, I think this approach loses its appeal when a portfolio does not exist. Sure we can create one, as Erich suggests, but creating an entire project portfolio just to calculate ROI seems like a lot of unnecessary work. It probably makes more sense to look at the key business drivers and strategic plans and propose ONE project that has an acceptable ROI, and concentrate on planning/costing that one.

2. Is this approach just for the “big boys”?
The vast majority of organisations only have one or two projects in the pipeline – probably not enough to calculate a compelling ROI. Strategic plans or roadmaps will exist but the candidate projects listed in these probably won’t be costed until just prior to them starting. So this approach probably only applies to very large organisations – who probably have a portfolio of fully planned/costed projects large enough to make a meaningful ROI calculation.

3. How are you going to convince project sponsors to alter their already approved plans?
If you want to revisit/alter projects have been approved and have “cleared corporate ROI hurdles” it may be difficult to answer the question foremost on the minds of project sponsors: “what’s in it for me?”. The project funding is available and the sponsor has publicly committed themselves to delivering the specified project outcomes by the completion date. They might be reluctant to tinker with something they have already committed to and the organisation is happy with.

4. How do you reconcile the uneven distribution of costs/benefits of the projects within the portfolio?
By taking a portfolio view you will be faced with an unequal distribution of costs/benefits for each project within the portfolio. For example, one project might benefit greatly from adopting an SOA approach and another one might suffer slightly. The cumulative effect to the organisation will be positive but how do you convince the sponsor of the second project to ‘suffer slightly’?

5. In practice how would you go about plugging the gaps in the portfolio?
Erich says:

“In addition, given key business drivers, there are often gaps in the project portfolio where a business need is not or can not be addressed due to technology barriers. These barriers may be eliminated using SOA. Such new projects that address strategic goals can be calculated for ROI based on corporate metrics and added to the SOA project portfolio for a total ROI calculation.”

So you might have a situation like this:

Project Gap

Depending on how big the gap is, you could have a situation where a project devised solely to fill the gap is not worthwhile. However, there may be a potential project that fills the gap and offers excellent ROI – but it may overlap other projects:

Project Gap Filled


As the diagram shows, the overlap might be minor in one project but significant in another. Either way, you would again have to alter existing/approved projects.


Trying to Sell SOA To The Business? Don’t Bother.

February 15, 2008

There is absolutely no point selling SOA to the business. They just don’t care. But if you think SOA is a good fit for your organisation there is a simple way to bring SOA in: sell a solution to a business problem that happens to use SOA as the solution’s architecture.


I.T. people are not salespeople. They are hopeless at writing persuasive proposals, worse at delivering compelling presentations and most haven’t even heard of the 30 second “elevator pitch”. I.T. people don’t speak the same language that business people speak, be it words or numbers. If you observe the often comical ways in which I.T. people try and sell SOA to the business you’ll see what I mean.There’s only one thing I.T folk need to know about selling SOA to the business:

Don’t bother. They don’t care.

Aside from the fact that I.T. has a credibility problem when it comes to promoting the latest and greatest idea, business people only care about things that are ‘visible’ to them. SOA is an architecture. It’s a mindset. It’s a design principle. It’s a lot of different things to a lot of different people. But it’s also an abstract concept – you can’t see it or touch it and it doesn’t ‘do’ anything. It means nothing to business people. SOA is a lot like Total Quality Management (TQM) and 6 Sigma of yesteryear. You can’t see or touch ‘quality’ – but in time you can see the results of implementing a quality programme.

So, if you think SOA is a good fit and you want to “do SOA”, how can you go about introducing it into your organisation? Here is five tips.

Tip 1: DO NOT sell the hype.
The “everyone is doing it so we should too” argument is absolutely the wrong way to go. Firstly, this statement is blatantly false – everyone is talking about it but very few are actually doing it, and even fewer are doing it in large scale production environments. Secondly, when things go wrong, it won’t be “everyone” that will be asked for a ‘please explain’ – it will be YOU.

By all means share industry success stories – but don’t ever commit to achieving the same results. Remember that for every publicly available success story there will be many privately hidden disaster stories.

Tip 2: DO NOT sell the technology.
You’d think this goes without saying, but my experience tells me otherwise. If your argument is “if you look beyond the hype, SOA technology is actually very cool” then you’re still missing the point. Techies may think its cool. No one in the business will. To business people ‘SOA’ is just another TLA (three letter acronym). Forget the jargon. Forget the technology. It only confuses people.

Even if business people did listen and understand the technology aspects of SOA, be aware that one man’s “cool” is another man’s “risky, bleeding edge, here today gone tomorrow fad.” Don’t expect everyone to instantly share your enthusiasm.

Tip 3: DO NOT sell features or benefits.
On the face of it this may sound a bit controversial but let me explain.

Proponents of SOA point out the many benefits that an organisation could gain by implementing SOA. The key word in that sentence is could. SOA allows you to do many things but so what? A salesman might point out all the great features of a new television set – but all those features are irrelevant if I’m looking for something to keep my food cold.

Going to the business and trumpeting all the great things we can achieve with SOA is like saying: “I’ve got this great gadget! It does this, this, this and that. Are any of those things of any use to you?” This is the proverbial solution in search of a problem. We’ve got to do better than that.

The business is not interested in all the great things you can do – they’re only interested in what you can do for them. You need to go beyond providing a checklist of features and benefits – you need to apply them to solving real problems in the business.

Tip 4: DO sell business outcomes.
Don’t expect business people to make the jump from features/benefits to business outcomes. That’s the job of the person writing the proposal. Let me illustrate.

The Solutions Architect in an organisation wants to propose a project for integrating the warehouse management and order processing systems. He’s done a proof of concept and has worked through the major technical issues. He’s ready to take it to the business. In his proposal he explains that he’s done a proof of concept. He explains that the project is relatively low risk and that it can be done relatively quickly and cheaply.

Then he pats himself on the back and waits for the inevitable approval. After all, why would anyone knock back a low risk, cheap and quick project? But the proposal is rejected. Like most I.T. people the Solutions Architect is not a good salesman. He expected the person reading the proposal to understand the implications of integrating the two systems. They didn’t. No matter how low risk, cheap and quick a project is, it will never be approved if the person reading the proposal is scratching their head trying to work out what’s in it for them.

A better proposal might say something like: “integrating the two systems will allow us to have a real-time view of our stock situation, which should prevent stock outs and reduce the number of customer complaints”. You need to stress the business outcomes: less stock outs and reduced complaints.

Tip 5: DO NOT mention SOA or bend over backwards to accommodate it.
When proposing your solution resist the urge to put the ‘SOA’ label on it. The business pays Architects to provide solutions using industry best practice – so do it. Whether the solution is SOA or something else – there’s no value in trying to label it.

It is well known that I.T. people like to tinker with the latest technology. Given the hype surrounding SOA, the business might think (not unreasonably) that you proposed SOA because it’s the “in thing” and you want to be a part of it. It’s that well worn phrase again: the business might think all you have is a hammer and you see all their problems as nails.

Finally, don’t get too carried away – SOA is not the solution to all problems. If you bend and contort your solution to try and make some tenuous link between the problem and SOA – savvy business people will see through you. And if they don’t – sooner or later you will have to explain why you chose to fix a leaking tap by replacing the entire plumbing – instead of spending few cents on a new washer.

So there’s five tips for getting a foot in the SOA door. Of course – the same tips apply irrespective of whether your proposed solution is SOA or something else.


I.T. Has to be About the Bottom Line

February 12, 2008

During my years in the IT industry I have seen very little progress towards the goal of I.T. and business alignment. Despite the fact that both sides accept the ever-increasing need for it, each side continues to accuse the other of not “getting it”.

The I.T. industry as a whole is getting better at doing what it does but still it struggles to improve its reputation in the business community. I started thinking about why that is. The answer turned out to be relatively simple. With a few exceptions, I.T. continually fails to live up to its potential of being a source of competitive advantage and having a positive impact on the bottom line.

As an industry we have positioned ourselves in a no-win situation. We can continue to do things better, cheaper and faster – but it will never be good, cheap or fast enough. We will always be a ‘cost of doing business’. Unless we reposition ourselves.

My premise is simple – true ‘business-I.T. alignment’ will not be possible until I.T. has a positive impact on the bottom line. And I don’t mean a ‘smaller negative impact’. I mean a positive impact.

Nobody ever talks about alignment between sales and marketing for example. Although they are distinct functions they are so closely aligned that people often talk about them as being one and the same. The reason for this close relationship is simple: they depend on each other. They cooperate to each ones mutual benefit. The ultimate benefit being money – profits, pay packets and bonuses.

A similar relationship doesn’t exist between business and I.T. Sure, both sides need each other but the relationship can’t be characterised as symbiotic – as it is in the case of sales and marketing.

The irony is that I.T will only have a positive impact on the bottom line if it aligns itself with the business, but at the same time this alignment won’t happen until I.T. has a positive impact on the bottom line. The classic catch 22. But we have to start somewhere. Small wins and incremental steps will build momentum.

After all, when all is said and done…

I.T. has to be about the bottom line.