Enterprise Architecture – the big catch up

Here is the problem with EA – it is never complete at the point instant when a project asks some question of it. I think that is true no matter how many architects you have or how good they are.

This is the third time I’ve been responsible for “Architecture”, and – no disrespect intended to architects, who aren’t the problem – it never seems to be in complete enough a state that it can answer the specific question a project needs answering at a specific time.

In an organisation that respects its architects – and I think that DWP is one – that means the projects ring up the architects to get advice. Which is all very well, of course, but since the architects are spending all their time trying to build their architecture out to the point  where projects need it to be going, they don’t have time to write all their advice down and add it to the architecture.

Of course, you could have an architecture team that builds things at such a high level that you get completeness simply because you’ve abstracted away all the detail altogether.

But I think that kind of defeats the purpose of having decent architects. You’re then into the realms of strategy, and lets face it, architects are supposed to be working out how to get to the endpoint that the strategy defines, not defining the end point itself.

Now I know that this set of statements will be like waving a red flag at a bull for some people. I don’t mean to cause offence, really I don’t.

But I have come to the conclusion that demand for architecture – at whatever level of detail – will always outstrip the supply of architects available. No matter how much money you spend.

Now, this presents a quandary, I think. On the one hand, if projects can’t get what they need from the architecture, I wonder what the point of having an architecture is at all. But on the other hand, the chaos that results from not having one at all seems pretty likely to have awful repercussions. I’m not certain anyone wants to go back to the days where people did exactly what they pleased, and dang the consequences.

Anyway, it would be impossible now that we have to do “service orientation” and “reuse” and “integration”.

But I can’t help but wonder if the real answer is to decentralise architecture in some way  - make it a more collaborative and participatory activity, one in which projects do a degree of self serving. Where, maybe, the architects are curators of the content, rather than the creators themselves.

I’m going to be talking to my teams about an interesting experiment I have in my mind along these lines over the next week or so. If we go ahead and try something new, I’ll write about it here.

In the meantime, does anyone else have experiences that are relevant? How did you get your architecture ahead of project’s demands for it?

Comments

[Peter Evans-Greenwood]

Less is more: spend less time worrying about major IT assets (and all the TOGAF documentation that goes with it) and spend more time focusing on how you will manage business change. Think city planning rather than bridge building[1].

Build frameworks and select tools to help business and technology teams to build shared understanding and work together[2] (facilitated events, like the non-conference you just ran are great for this). Focus on the dynamic nature of the IT estate (how it needs to adapt to business change over time) rather than the static state (and end up spending all your time modelling the cow patch in business processe). Invest in models (BPM, rules) that execute, and avoid models which are purely documentation. Out-source, BPO, BAM and (particularly private) Cloud are your friends. Try not to sweat the little stuff: if the project teams are good then that should be their job.

And remember, EA is a planning function, so you're overhead and add no (direct) value to the business. You're there to make the business, operations and delivery teams look good.

All that said, this can be done. It does require a change in world view though, as you need to focus on planning and managing technology enablement, rather than IT assets[3], and you need to measure yourself and your people that way.

1. The Paris Guide to IT Architecture
http://www.cids.ie/Documents/Globalization_IT%20Architecture.pdf

2. The Value of Enterprise Architecture
http://peter.evans-greenwood.com/2009/05/07/the-value-of-enterprise-architecture/

3. Manage technology, not applications
http://peter.evans-greenwood.com/2008/10/13/managing-technology-not-applications/

[Neil Robinson]

Great post, James and one I can totally relate to. You raise two distinct but truly vital issues.

The first point may be the way your organisation is visualising its architecture. It maybe seen as circular - you're trying to construct a "ring" where you start at one point and bring it round to a completed, closed circle. Ever thought about the tower or dangling threads approach?

OK, that sounds odd. But consider this. Requirements - such as you so successfully gathered in your crowd-sourcing session, are not fixed, they change in reaction to business needs and what simply got left out of the orginal concept. So here's the fundimental disconnect with your circular approach. There is no room to change or improve, the design is set in stone.

Now if you see the design as having a horizontal baseline - the architectural foundation - and build vertical towers of functionality vertically from it, you leave infinate room to grow and expand. Need a totally new function?

Simply begin a new tower. very ethereal, true. But perhaps worth considering?

Now the second point. Can I quote from your post here?

You said " the projects ring up the architects to get advice." There you've identified your second problem. You can't stop your day-to-day tasks every day to host a crowd sourcing event, as good as it obviously was. You need a method to connect your business to the architectural design. I'm talking about a published view of how everything fits from a business persective, each tower overlaid on the techy design. Put it up on the wall of every single department that uses it.

Your staff can simply go to their tower and add a requirement. "I need some way to capture this nformation to enable me to walk round and talk to waiting job seekers, whatever."

The architect can then respond and being able to visualise it, see what is needed to implement it, therefore cost it appropriately and hopefully deliver it in a timely fashion.

In effect its an implementation of a social network. Just as your crowd sourcing was.

But finally, you ask if you really need an architecture at all. the answer is maybe not. But you do need to control access to your intellectual property and that vast silo of personal data. So you may need a framework rather than an architecture. Architecture suggests a way of building. A framework implies the touchpoints only!

And as I asked some time ago, is the craft of enterprise architecture dying. I believe the answer is, yes it is, because the business demands water to work with, not a block of concrete.

[Dave Pomphret]

To get ahead of the game define the headlines and work backwards. There is no need to cut granularity of an EA in the early stages; cut the detail. Then focus the details driven activities in a prioritized fashion that works with the Business to deliver their projects.

Acceptance of knowledge boundaries (the "Here Be Dragons" approach) needs to be seen not as a failure in the EA, but as a necessary caveat to the process.

P.S. To run an experiment in improving EA firstly you'll need people that 'care' about EA... Good luck.

[Duncan Anderson]

Hi James, you are onto the big challenge that faces all organisations thinking about architecture. In my past I've been the Chief Architect for a large organisation and struggled with different models and how to make them work. I am firmly of the view that the delivery organisations (service & application delivery) need to own the designs for the systems they implement. There is an interesting human response to design, which is to reject anything that you didn't design yourself. I can recount numerous battles trying to address this - but I can short circuit this and tell you its not worth the hassle. Delivery teams always need to feel that they own the design they are going to implement - that way they become committed and put everything behind making it work, which at the end of the day is what you need given how hard IT delivery can be.

You also need a central planning function that sets the direction, defines to a meaningful level the milestones, approaches, technology capabilities, etc. That central function might include a 'centre of excellence' to help jump-start capability around some favoured new technology or design approach. However, generally speaking you need your delivery organisations to take ownership of anything that looks like actual 'project designs'.

You also need your central function to work with the delivery organisations and guide their designs and make sure they keep to the overall strategy and allow practical feedback from the delivery organisation to influence and adjust that strategy. So, effectively, I'm talking about a kind of distributed architecture function, some centralised and some buried in the delivery organisations.

I believe you need to put in place a community programme and enablers to join the architects up and help make them feel part of both a delivery organisation and also a wider architect community. That way, you get the best of both worlds - delivery feeling they own their designs, and a wider architect community that networks and work together to influence a wider 'city plan' and make sure that is what gets implemented. I wouldn't underestimate what is involved in doing that communication, networking and joining up - it can be hard and needs focussed effort.

I'm sure others will have different views (one large organisation we both know seems to disagree with me), but I've come to this opinion from being at the sharp end, so have a slightly 'grumpy old man' attitude I'm afraid that this is the only way it can work in my mind!

[Jon Ayre (The Enterprising Architect)]

A common dilemma, and I understand your thoughts relating to decentralisation. I agree that this can accelerate generation of content, but it does create its own problem, in that the more people you have contributing to a common model, the more work is required to rationalise the result and avoid conflicts and contradictions (which in themselves give the appearance of an incomplete architecture and we are back to the original problem).

For me the real answer here is LESS architects, not more, but ensure that they are strong characters with a wide range of experience and the courage and confidence to make the necessary decisions quickly in the absence of hard data. They also need to be brave enough to get it wrong (as a mistake in architecture is visible to all).

These architects need to have a deep understanding of the world of projects and delivery. They need to have experienced it for themselves in order to know what a project wants and what it doesn't want. (A project wants hard answers and ready made solutions, not vague ideas and lengthy documents). Give them 80% of what they need and they will have time to help you fill in the other 20% (and so the architecture becomes more complete). People don't mind the gaps as long as the bits that are there are of true value to them (and most importantly make their jobs easier).

Now - this doesn't mean you don't involve a greater community in the production of the architecture. A good architect will be talking to a wide variety of people both inside and outside your organisation, and will have their fingers in many pies. They will already know much of what is required and will be able to talk directly to the people who will give them the information they need.

Regards
Jon H Ayre
http://theenterprisingarchitect.blogspot.com

[Jon Ayre (The Enterprising Architect)]

A concrete example of community involvement in architecture: The Business Architecture I produced in my current role.

How we did it:
We brought together a variety of people from across the organisation into a hotel for two days with the remit to "Create the Business Architecture" (They of course didn't believe this could be done, but were hoping to plan out how to do it).

I facilitated the two days and on day one put up a straw man domain model for the business based on their core value chain (from their vision/strategy papers) and invited them to tear it down and rebuild it.

Free discussion and copious post-its gave us their version.

In the afternoon we had open discussion (arguments?) in which everyone was invited to add to the model the services they as a business wanted to provide to their customers in the future. We asked them to think to the future (an aspirational date of 2015 was used) and be as unconstrained and inventive as they could be. The big question was "What would you like to do!" not "What do you do today" or "What do you think can be done". The constant reminder was "Don't worry if it can be done or not - let us worry about that later"

We then looked at what we had as a group to remove duplicates, resolve conflicts and reach a consensus.

By the end of the second day we had the big picture.

We had a single sheet of paper on which the entire business could be clearly seen, in language familiar to the business. There were no gaping holes around the edges as we did not get shoehorned into focussing on the core services in detail to the exclusion of everything else, and we had a happy (if very tired) consensus around the table that we had a picture of how we would all like the business to look in the future.

We also had a framework that would allow individuals to work on the detail of each service without having to worry about the whole, and in the full knowledge that their work would fit neatly into the jigsaw.

Most importantly, we had created the belief in all those involved that architecture was something you could do (and benefit from) extremely quickly and that decisions were there to be made then and there, not to be passed to a committee to discuss.

This BA has now received wide acclaim across the organisation and has been used successfully and in anger on more than one occasion.

Are there gaps? Of course there are, but these no longer seem to matter. People are seeing the value, getting excited about it, and seeing the opportunity to help us to fill in the gaps as a positive thing.

Regards
The Enterprising Architect
http://theenterprisingarchitect.blogspot.com

[Martin Pickering]

Having worked as part of both set ups in my time, a strong centralised Enterprise Architecture team and a decentralised architecture community, I think the first model works best. Decentralised teams soon become individual teams, following individual agendas and delivering solution to individual architectures. A strong central team, owning and maintaining the Enterprise Architecture with input form the wider delivery community, ensures buy in and allows the central team to concentrate on understanding the corporate direction and associated challenges without the pressures that being part of a delivery organisation creates. That’s not to say that a little pressure isn’t a good thing, but the wrong sort of pressure (i.e. pressure to deliver project x in timescale y) creates the wrong sort of behaviour in my experience.

[Neil Robinson]

Surely the bottom line here is that business people make businesses work. IT guys "enterprise architects" or whatever title they award themselves are merely facilitators of that goal and actually do little in terms of the bottom line.

What is absolutely meaningless is the idea of a "5 year strategy". What are you planning to do in 2015, James, could you write a plan for it now? Of course not. If you can't, how can you expect a business to?

What we need to work towards is providing users with the equivalent of electronic Lego. Architects should do what's necessary to in effect, give the business a box of the stuff and say. Off you go build what you need.

The business should own their own future, their IT, not some IT police force. Making a business work is really hard, building IT is really easy. Tails shouldn't wag dogs!

[[email protected]]

I don't think that the demand for architecture outstripping the supply is necessarily an issue, after all we don't know what we don't know and the business landscape is forever changing. If there is a demand it does point to the fact that architecture has value and this is my view is a good thing and the hardest to achieve. So the problem arises in what 'content' is enough to satisfy the projects and the only way to know this is a) have proper enterprise planning (not doing architecture for architectures sake) and b) have close relationships with the solution architects i.e. not seen as an ivory tower function.
Firstly enterprise planning, the content detail of the architecture should reflect what is required by delivery at a point in time; so we need to have a robust planning process whereby business strategy at the top level, drives IT strategy which drives what needs to be delivered to achieve this. In this way we know what we need to delivered and what architecture is required to do this. Clearly it’s not going to be perfect but if you can get 80% then this makes everyone’s life easier. This is where my second point comes in, close collaboration with those that need the answers i.e. the solution architects. I think to achieve all the benefits of EA, there needs to two things; a strong (not huge) architecture function with architects that are respected and can mange both of these tasks but also; a strong solution architecture function who work with the projects who can understand the architecture and do not delegate what are actually solution decisions to the EA function.
Regards
Sharon Coop

[Jon Ayre (The Enterprising Architect)]

Neil

The 2015 aspiration was my comment, and it was the Business who set this target (not IT). What is more, the Business were incredibly successful at creating a view of what things might need to look like in 2015 and very clear that this might change (and thus the architecture would need to flex with this). What was important was that there was a clear understanding of where everyone would like to be in the future, and clear direction to make progress on that journey (and adapt to changes in the destination). So - yes it can and has been done. Asking if it can is now a somewhat moot point.

What I do agree with is that the Business should own there own future (as should the Customer), but to assume IT is not part of that business and so a co-owner of the future is IMO obsolete thinking carried over from the '90s and earlier.

Regards
The Enterprising Architect
http://theenterprisingarchitect.blogspot.com

[Stephen]

Many organisations have this challenge and it has been well researched, see ‘Enterprise Architecture as Strategy’ by Ross, Weill & Robinson, and we used some of these ideas very successfully on a recent project.
Note: this is a business book – not a technology one.

The first step was to get everyone to understand what ‘Enterprise Architecture’ is; when I mean everyone, I do mean everyone (including the Executive Board). We sent the book too lots of people and asked them to read it. We built consensus on the need for a ‘foundation for business execution’ using business language in simple terms that people could understand.

We got everyone to understand the ‘gap’ between where we were and where we wanted to be as an organisation e.g. you cannot go from ‘silo’s’ to a ‘modular business’ in one step – everyone ‘got it’.

Once there was a ‘shared vision of the future’ and a shared understanding of the gap and the necessary journey to close it, we started making real progress.

People in the business silos started to understand the behaviours required. The other benefit was that IT was no longer the ‘whipping boy’ as the business started to understand the challenge and their role in helping close the gap.

We moved ‘Enterprise Architecture’ out of IT and put it at the heart of the organisation.

I think our success was ‘getting all the wild horses’ (Business & IT) to start running in the same direction and by doing this we have started to close the gap.

It does require leadership and sponsorship from the very top though and we were lucky enough to get it.

Business people do not seem to like or understand words such as TOGAF, SOA etc; for many it is ‘gobblygook’ and cannot see directly the value of it.

http://www.architectureasstrategy.com/book/eas/

[Marcus Gilbert]

James, this is an excellent post and I'd like to present a view from the dark side, as I'm sure it will be perceived by others on this post. I work in sales for Salesforce.com, some would say it's the leader in the new world of Cloud Computing.
When salespeople (try to) speak with EAs in large organizations, especially Government, we are often treated as 'disruptive' to the steady state of how IT engages with the business. Rather than embrace companies that are thought leaders and innovators into the bosom of EA, we are often treated with suspicion and held at arm length.
It should not be forgotten that companies like sfdc grow by speaking to the business and finding out what they want. There are some incredibly smart people in young, innovative companies - most are recruited from senior roles in public companies. SFDC has 68,000 customers, so that a lot of research into business needs, and technology trends that are required to support them.
As I see it, the problem with Government, specifically, is that it puts all its eggs in one basket by offering large and long-term contracts to established vendors who have a vested interest in supporting long-term, legacy architectures and this will guide their support and advice.
I agree with the posters here who suggest that Architecture should be separate from IT asset management. It needs to be closer to the outside world and the trends that drive business. In the the construction world, an Architect constantly explores new building techniques and applies them to meet the need for design - they do not maintain the building, once it's built. Some Architects I meet see their role as policing the IT Infrastructure.
To understand how your Architecture team will work now and for the future, look at the list of questions that you ask prospective candidates during the recruitment process. I used to work as a recruitment consultant many, many years ago. I've lost count of the amount of times that the interview process sought the 'ideal' candidate, but the true role was not based on that skill-set.

I'm know I'm not so eloquent as the other experienced people on this post, but I thought I'd add my 5p worth.

[Neil Robinson]

Very well put Marcus. I agree with every word. And having just taken an international client with offices in the UK, US and China from a locally maintained SQL Server running all their business processes to SalesForce from signed contract to live in less than 10 days - a feat I thought impossible, I know just what is possible when conventionally supported IT architecture is taken out of the equation!

[James Gardner]

Well that does point to reasonable value, I know. But I'm not so certain about the strong solution architecture function. Why aren't they the same?

[James Gardner]

That's a very good set of points, Marcus. And though I'd hate to say I agree with you about Govt, I agree with you about Govt.

[James Gardner]

Yes, that's right, Jon. Why are IT and the business not equal partners these days?

[Stephen]

There is indeed a problem there.

http://www.computerweekly.com/blogs/tony_collins/2010/01/26bn-of-botched-it-is-good-for.html

Which references the 26bn write-down of IT projects - I am sure we all know of many more that are not included within that figure.

What is the old saying: change or die?

At the same time, I think there are problems on both sides, and we all need to change and shift to a longer term focus.

There needs to be some very frank and open discussions about a new order.

Not a discussion about blame, but how can we do things better?

[Stephen]

Just to add, having worked with most of the vendors on a number of continents, they also have no desire to hang on to legacy systems, especially those that are 20 years old as they are not leverageble.

I think the challenge for these people is reputational risk, some players have taken big risks at the customer behest and they realise the price they may/could pay in the longer term.

So in terms of legacy, we all want to divest it, but, currently there is not enough trust in terms of the approach and potential outcome.

Also, from the vendor perspective, they also need to manage change in a controlled way, e.g. skill-sets, people transformation etc.

So, how do we all move from a ‘Prisoners Dilemma’ e.g. loose/loose to a win/win situation – I think communication,
collaboration and engagement is a good start.

Ultimately, there needs to be something for both parties e.g. win/win

The other challenge for internal staff is (many) sales-people trying to sell stuff directly to the business, as IT may not want to buy it because it does not fit with the strategy. e.g. ferrets down a drain pipe.

There needs to be a genuine way for external suppliers to bring genuine innovation offerings in a controlled way - weather they are a direct partner or not.

What they do need to understand though, is that they need to fully understand the strategy of the organisation they are trying to sell into, and the USP of their product and how it might fit.

[Stephen]

10 days, hm, it would be nice to see the project plan.

[Dave Pomphret]

Alas, getting people to let go, stand back and take in the bigger picture is very difficult. Given our EAs are all IT staff, (MOST not all) have tunnel vision and keep to the 'old' silo structures. :-(

[Neil Robinson]

James, the short answer to your question is no, IT and the business are not equal partners, never were and never will be.

Would you go ask the exec chauffeurs where the next HQ should be when their job is just to provide the transport to get you there?

The evidence is that IT directors are becoming an endangered species in the board room and are slipping down from C-level as the business slowly wakes up to the fact that with software as a service, the Cloud, employee-owned workstations and service based delivery, they can choose what they need for themselves.

I started in system enginering, went through system support, via architecture and onto strategy. A tech career all the way, so it pains me to say that IT people are usually the worst people to talk to about any business, because they talk about systems, shrink-wrap and tinware and usually don't give a damn about what demands the business faces.

I made the jump because I realised its the problems the business faces that we need to fix not the people with ideas that don't fit the current architecture, which is what IT and the security guys are obsessed with!

[Stephen]

Neil, forgive me for responding as your reply was to James (and appologies to James too).

If the driver has a bespoke car with the engine of a 20 year old hilliman imp and he is asked to go on a perilous journey and cross mountains where no roads have been built, and the passenger wants to go to nirvana - this can be a challenge.

So, who plans the route, what is the vehicle given the constraints, and who decides what these things should be?

One thing I do want to say though is that everyone – does their ultimate best so that they can to deliver on outcomes set, given the constraints.

Let’s not blame the little people (the driver) who is only looking for some leadership and direction.

Neil, if you study the business e.g. the benefits system as a business, the inter-linkages and the constraints of some of the technology (e.g. 20 year old non-relational databases), 100,000 users etc; you will start to get an idea of the challenge.

I visited the Inland Revenue Service in the US - 10 years ago, the big plan was to modernise and transform, I visited again 10 years later, their systems were still running on 1960’s Assembler and the challenge is still to get their flat files into a database.

The best metaphor for me is the Thelwall Viaduct on the M6 – and that is a very simple structure in comparison and it was very difficult for the people to fix.

http://en.wikipedia.org/wiki/Thelwall_Viaduct

[James Gardner]

A typically confused argument from you, I think. I wouldn't ask the chauffeur where to put the HQ, but I would ask the best way to get there. I wouldn't ask an IT director to design a new banking product on their own either, but it would be impossible for them not to be at the table during the process.

In your model Neil, IT is an order taker. You wait to be told what to do, and then you do it. It is IT directors who are order takers who are in danger, not the ones who recognise that their functions are no less part of the business than, say, marketing. Could you run any major business today without technology? Of course not.

Consumerisation is all very well, but you ignore the fact that non-consumerised IT is where much of the investment AND the competitive advantage is. The cloud is all infrastructure. Its commodity. So is all the other stuff you mention.

I know you've done a few years in some major businesses, but not for a long time I think. The fact of the matter is there are these radical shifts going on in large organisations, and IT *is* becoming part of the business in a real way.

I know it doesn't seem like that to IT folk who aren't on the inside. As a contractor for the last decade or so, I suppose it is possible you haven't really been part of the maturing of large IT relationships. But trust me, they are maturing very quickly indeed.

[Neil Robinson]

James, one point we'll both agree on, I hope, is that businesses came about through the success of the unique operating model they initially established. Their use of technology (as a tool) merely facilitated that. In other words IT was a component only - a vital one, certainly, but not the driver (no pun) at all.

Now, fast forward to the next operating model change for that business. Instead of the business being able to establish the new model based on requirement, it's often forced to compromise not because the IT can't do it per see, but often because the IT guys simply won't allow it, place so many smoke-and-mirrors obstacles in the way or just make it too expensive and drawn out to be viable.

Not so? - I could refer you back to so many posts where you say that it is so. Oh how I wish I had your chameleon-like ability to change my view based on my paymaster.

I would love you to show us any occasion when the next head office move was run past the chauffeurs to decide, or even to have have an opinion on!

And the Cloud is just like a taxi.

Surely like IT, you don't need to ask the drivers how to get there, their job is to get you there, not tell you how - its their job!

One thing I've learned through my outside position (although over 5 years continuous engagement with one customer, following 10 years supporting the same one through another channel exceeds all of your "permanent positions" by some considerable margin!) is that business models are often difficult to change and when change is inevitable, should be changed with great care. And that business success is fragile.

Technology is the opposite. Inordinately flexible, easy to change, getting cheaper and quicker to implement. Also done right, incredibly resilient. And yes it is becoming a commodity, absolutely.

My point is that given those two factors, surely the IT should accommodate the business, not vice versa?

Do your existing tools dictate how you build your house, or do you budget to update those tools if necessary?

How can you expect us to accept an argument for "maturing large IT relationships" when you have just fired your long-standing IT partner (who hadn't had a pay rise for far too long) to take on another?

Tech will always be the bridesmaid, never the bride. A supporting, never a leading role!

To Stephen, given public sector IT budgets can you really defend failure to keep underlying systems current? Ever considered the per capita allocation of such funds compared to the commercial sector?

An interesting exercise for you.

[Stephen]

Neil, government departments around the world do keep their mainframe legacy environments very current, as do the hardware vendors (mainly from the hardware perspective) as they want the revenue stream.

So even though many of these systems may be 20 years old and encapsulate an outdated software paradigm and/or perhaps an outdated business model, they still run many businesses (successfully) around the world today.

Eventually there becomes a tipping point though, where it becomes just too expensive, too hard or takes too long to change them, or they become obsolete and they need to be replaced.

Often the knowledge of these systems is ‘tacit’ as they encapsulate many years of evolution and the people who developed these types of systems are starting to retire.

There are many different approaches to solving this type of problem, both
bottom-up, inside-out and top-down driven.

The challenge of doing these things is though, is it can be like re-building a 50,000 room hotel whilst people are still sleeping in their beds and it needs to be done incrementally as some systems are just too big or the risks too great.

It is just as much a Business problem as a technology one.

Because we are talking about Business, Technology and People, it is not just a question of money; there are many other critical success factors.

I think culture is a critical success factor. My view is that IT enabled change is likely to be most successful when there is a ‘We’ culture rather than an ‘Us and Them’ culture.

So in response to you, no, I do not see it as a failure, or a lack of investment.