The lack of integration in banking has been caused by a combination of build and buy, the need to address regulatory changes, the launch of new products (yes, I remember the launch of credit cards, never mind ISAs).  But you might assume that, because banks have been around since IT was invented, and have been perpetual early adopters, that it is only old industries that suffer this problem.

It got me thinking about newer industries, take Telecoms and Media for example.  Why didn’t they have the opportunity to greenfield their IT?  My take is that it is the opposite of the banking scenario.  That is, the industry exploded so fast the ability to keep up with the pace of change meant that systems had to be cobbled together on the fly.  To grow a company from almost nothing to £80Bn in a few years must put enormous pressure on the CIO.

So despite the provocative headline of this post, the mess is entirely understandable and it is difficult to envisage any other result than the one we have.  We now must learn how to live with it, both in the short term and the long term using a combination of strategic and tactical initiatives targeted at the nirvana offered to new entrants.  However, if Metro Bank experiences the sudden growth it expects, I wonder how long before it suffers the same integration problems as everyone else?

“By 2012, 20% of businesses will own no IT assets”.  This is a stunner.  On closer inspection Gartner means hardware assets, not software, but even so, can we really believe this?

I will be happy to stand corrected.  I think that, supported by a very compelling business case, most enterprises are likely to head towards delegating responsibility for application development and support, and hardware procurement, configuration and management to external organisations.  But haven’t we seen all this hype before?  Consolidation of end user computing resources within the enterprise never really took off, did it?  Enterprises have so much invested in existing hardware and systems that I can’t see any, large ones at least, making so much headway in such a short space of time.

I expect the vast majority of larger enterprises, even the ones trying to aggressively adopt Cloud et al, to be living with legacy on-premise systems for at least another 10 years.  Am I a Luddite?

Well, Citi have contributed to the debate by offering a sticking plaster solution, both virtually and literally.  A sliver that adheres to the back of your mobile phone and enables contactless payments of up to $50 at Master Card PayPass readers.  This is a proper workaround but hopefully it is proving the need for something more strategic.

Hopefully within my lifetime, we will all have a unique identity held (securely) within our mobile phone.  Every time we buy a new device like a laptop or car, every time we are permitted access to a new office, club or country, every time we want to make a small or large payment, the infrastructure around us will adapt to us.

At the moment the supplier of the service or product grants us a single unique interface (for example a key).  The future will be citizen-centric.

Here is my take.  If IT departments started listening more to what their businesses need to succeed in their own competitive environment, and less to vendor promoted architectural trends, then people would stop talking about whether SOA/Cloud/SaaS/Private Cloud/WTF is successful and move on to the much more important issue of whether businesses thrive irrespective of their choice of architecture.

In truth, most experienced business heads are a bit more pragmatic than that.  They understand the IT side of the argument.  The importance of data integrity and security, system stability, centralised procurement of technology, coherent architectural strategy.

Whilst these are all very plausible and necessary requirements, the fact is that the speed of modern business requires operational responses measured in hours and days, rather than the months and years associated with traditional IT projects.

IT people are not dumb.  They recognised this ages ago.  Initiatives like SOA and BPMS are designed to provide business flexibility, speed of response, agility.  But these are major IT programmes in themselves and in business eyes can take too long to deliver even small benefits.  They can also be disproportionately costly, so the economic case only makes sense for major business requirements.  What about the 750 item (and growing) change list?

The business is coming under ever greater pressure to reduce headcount so the old option of simply recruiting a few more operational staff is no longer available.

The result is that well intentioned business ops people create their own solutions under the guise of “end user computing” but more likely referred to by EAs as ”Rogue IT”.  Spreadsheets, local databases, emulator macros, even amateur VB programming.  All delivered without any control, governance or thought for future maintenance.  So, guess who gets called in to fix a “mission critical” system when the creators have moved on?

No wonder IT doesn’t trust the business to do IT.

The last thing IT needs is maverick business users creating their own solutions, so maybe they clamp down on end user computing, causing further frustration in the business.  A spiralling circle of distrust is normally masked by a resigned acceptance of “that’s just the way things are”.

Random quote I’ve heard from an operational head “IT have slowed the organisation down to a pace where we can’t react to business opportunities and it takes an age to get anything done”.

Random quote I’ve heard from an EA “Business Ops are continually doing their own skunkworks initiatives with no regard to data protection laws, system resilience, disaster recovery or central IT strategy and yet when they fall flat on their face, it becomes our problem to fix”.

As an external vendor interacting with business and IT, I can genuinely see both sides of this argument.  I also think there are ways of reconciling the two views.  More in a later post.

He contends that the IT industry has “lost sight of its primary goal of reducing information management costs” and allowed IT estates to become way too complex.

I agree and I know countless operational people, the customers of IT, who are exasperated not only at the complexity of their IT, but perhaps more importantly the amount of time and money it now takes to make even the simplest of changes.

Martin’s anecdotal evidence of people resorting to spreadsheet management, or “passing around bits of paper” is depressing and as he points out, not the answer.

The reason I am interested in this subject is that Blue Prism is pioneering a new concept in computing aimed at simplifying corporate IT and the way it is interpreted and used by the business.

Freeing the business operation to fulfil its own integration and automation needs, and start hammering the growing IT change list is one thing.  But doing that with workarounds like spreadsheets or bits of paper or hiring temporary staff is ungoverned, insecure and not exactly scalable.  Blue Prism proposes an IT supported software platform, supported by a thorough methodology that business users can work within to make sense of the complexity, improve service, manage ongoing change, and above all reduce costs.

We call this an Operational Agility Platform, but the idea of operational agility is far from limited to Blue Prism.  As Martin suggests, there is evidence of a movement emerging “a revolt is under way”.  I prefer to think of it in the passive voice as a revolution as I don’t support the notion that operational people are revolting!

The basic premise of the article is that whilst the hype around SOA is overblown (no, really?!) the fundamental concept is good.  So the solution is…….change the name to cloud computing and press on.

I have been pretty right wing in my views on SOA in the past but I do genuinely believe that the concept is brilliant.  It is delivery that is flawed and there are two good reasons for this:

1.  Organisations take on too big a challenge in trying to deliver a service oriented architecture.  Grand vision = grand design = big bang = big cost = big risk = failed project.  There has to be a more incremental way of getting to SOA.

2.  SOA projects are almost always run by IT people.  No wonder they never meet business requirements.  Put business leaders in charge and watch the priorities change.

I spend a large portion of my life talking to senior customer service professionals.  The common story is that they are tired of IT projects that don’t deliver, and IT departments that cannot respond to change at the speed of business.

Change happens!  New product launches, regulatory change, product promotions, merger/acquisition, processing errors.  Shouldn’t SOA be enabling the business to provide appropriate responses to such change?

If the principles of SOA are to succeed, it is not going to happen by nomenclature, or adding more layers of complexity.  IT professionals need to distil SOA into simpler, more incremental, more business focussed chunks, and empower the business with platforms that enable them to react to everyday change without the usual lead times.

I believe that the ability to make a business operation truly agile will be one of the defining competitive advantages of the next decade.

I am not sure how many swivel chairs it would take before Sean would see an automated approach as more suitable.  I’ve certainly seen banks of people doing little more than this type of business process, inconsistently and with plenty of errors – in itself a very expensive way of doing things.  I do, however, take his point and this is not a criticism of what is essentially an excellent post that raises a number of important points.

For me, the most important point Sean raises is that “if you cannot build a new end-to-end business process that covers both systems manually then you do not understand the requirements sufficiently to start coding it.”

These thoughts are also picked up by Reg Braithwaite in an equally excellent post Is software the documentation of business process mistakes?  Reg argues that if your code represents the “user manual” of the business process, then if the code is too complex, this may well be because the process is too complex.  In other words, get the manual process right before you automate it.

The only reason swivel chair integration exists is because of the inflexibility afforded to the business user by the existing systems.  Business users are left with manual as the only option available to them.  It is the quickest, cheapest and most reliable way of getting a business process done – which is a sad indictment on the state of affairs in IT.

My interest in this subject is that innovative solutions like Blue Prism are trying to address these issues, bringing agility to the business, but without damaging the integrity of the underlying systems, or creating the need for new code.

There will always be some place for swivel chair integration but let’s keep it to a minimum.  Once a process can be done manually, the only things that should prevent it from being automated are the need for human interaction, or the need for human intelligence (e.g. expert judgement).

Various thoughts on this are neatly covered by Lorraine Lawson at ITBusinessEdge.  Various metaphors are being suggested for SOA including the Lego one (but Lego bricks can only be used once!), the fast food metaphor (puh-lease!), the service contract model espoused by David Sprott.  Actually this last attempt is one of the better ones, but David still dives off into a dry cleaning analogy at one point, and talks in very technical non-business-friendly language.

I still maintain, however, that all these metaphors miss the point.  What business people are interested in is what SOA can do, not what it is.  So as a business head, I might have a desperate need for agility, the ability to react to external events, to capitalise on short term market opportunities.  I realise that my existing IT infrastructure constrains me.  If I ask my IT dept how I can be more agile, then SOA may be a solution, but to be frank, I am not that interested.  I am interested in the cost of course, and how long it takes to deliver.  I am interested in understanding the solution and how it will enable (or constrain) my business processes, but I am not interested in the technology or the architecture behind it.

I know IT people are not going to like my views here – but SOA is just a means of delivering what the business needs.  It is not the only means either.  It depends on what the business needs are.  By “selling” SOA, IT folk are being very presumptive about what the business needs.

I think that there are more similarities between IT and building architecture than most IT people are prepared to admit.  If I commission an architect to build me a house, I am interested in the shape, size, finishes – what the building does for me.  I am not interested in the whether the structure is steel or wood, I am interested in whether the house is still standing after a storm.  I am not interested in whether the foundations are dug with a spade or a mechanical digger.  I am interested in how long it takes and how much it costs.  So if I ask an IT architect to design me a solution, I am not interested in whether they use SOA or P2P architecture, I am interested in whether I get the flexibility I need from the solution.

It makes my blood boil when IT depts and vendors sell technology.  Some even suggest that ROI is not the point of SOA.  Any business investment has to stand up to the scrutiny of return on investment.  I feel really stupid even saying this but if SOA (or rather the business solution delivered using SOA) does not deliver return on investment then don’t do it – simple huh?

As a vendor, I know we are all guilty at times, but we really ought to focus more on business need and deliver against that.

Mr Cane starts with a great point of debate about whether the CIO is the right person to align IT and business objectives.  Then he wanders around an argument that consigns the role of the CIO to the nuts and bolts of IT.  CIOs are responsible for data leaks, buying too many servers, not having a handle on software licences amongst other crimes.

Crimes they are indeed, and I am not arguing that CIOs shouldn’t be responsible for data security, physical infrastructure, and software licence control.  These are baselines; entry points for an IT function; administrative tasks.  But IT is not just about administration, it is about the very strategy of the organisation.  Where would Ebay, Amazon, or Facebook be without IT strategy?  Where would Barclays, RBS or HSBC be without technology at the very heart of their organisations?

IT should be an enabler for 99, if not 100% of organisations.  It is a profession and a discipline in its own right and its time has simply not come yet, in terms of board recognition at least.  So does the lack of a coherent understanding of the CIO role at board level come from the lack of great CIOs?  Or does it come from a lack of understanding of IT from the other board disciplines?  As the latest generation of tech savvy executives make it into the boardroom, I predict things will change.

Any company that gives something as important as IT to the Chief Financial Officer is in trouble.  The two professions are entirely different, Financial Accounting is about the past, whereas IT is about the future.  Both disciplines are essential but I truly believe that it is only a matter of time before the CIO >= the CFO.

The FT article concludes that CIOs should “concentrate on finding ways to use technology to expedite business change appropriate to today’s trading environment.  It’s a formula that should keep CIOs in business for years to come.“  I completely agree with Alan Cane on this point, but the other C level execs also bear a responsibility to recognise the potential, language, and role of IT, if organisations are to get the most from the newest profession.