It’s really tough dealing with technologists.
It is like the old discussion of the businessman in the hot-air
balloon who is lost. He spies a chap on the ground and asks if he knows
where he is.
The guy looks up and says, “you are about 35 feet in the air,
supported by a vehicle comprising cloth and ropes, and filled with
The business man looks puzzled and says, “you must be a technologist.”
“Wow”, the guy says. “I am. How did you know?”
“Because what you have told me is technically accurate, but of absolutely no use to anyone.”
“Ah”, says the guy. “You must be a businessman.”
“I am”, says the businessman, “but how did you know.”
“Because I was minding my own business and you asked me to help you
out, so I gave you assistance in the best way I could, and now you
blame me for the mess you’re in.”
Ouch. Business and technology folks really don’t get on well.
The reason I raise this today is because I spent yesterday with a bunch of technologists.
The focus of the discussion was SOA, Service Oriented Architecture.
Is that Customer Service Oriented Architecture, I hear you ask?
No, it’s Web Service Oriented Reusable Objects for Interoperability Architectures.
At this point, most business people have left the room.
Now, I think I know what they were trying to say, as I used to be a
programmer, but if I were a business person then I’d probably have no
idea what they were talking about because you end up using a bunch of
acronyms and words from foreign lands, such as SOA, SOAP, J2EE, BPEL,
XML, CDL, MDDL, FpML … you name it.
No wonder business folks would rather smell a monkey’s armpit than talk to a technologist.
The real point is that through SOA, firms claim you have
re-usability of code to be more agile through being able to plug and
play and evolve into highly flexible systems.
Apparently, according to the technologists, no business person wants
to hear the plea for investment in this stuff however. Investing
in building future, flexible architectures for their technology
operations just falls on deaf ears. As a result, they tell me that SOA
is an IT investment, not a business investment. Business people don’t
want to hear about it, and so it’s snuck in under the regulatory
change, compliance and discretionary investment budgets. There is no
budget for ‘re-architecting’ the bank.
I do not like that view, as I think SOA should be a business dialogue and investment, not something hidden under the radar.
What the business people need are business conversations.
First, a business discussion around why SOA is felt to be important.
Second, a business discussion about why SOA will deliver business benefits.
Neither of these discussions normally comes up with a technology
group because we talk about objects, modules, standards and
technologies. However, there is a business dialogue that could be
proposed, and it would go something like this.
First, how to position SOA for the business crowd.
Well, imagine you are building a house. Most house builders employ
architects to ensure the foundations and structures are right. Most
house builders also employ one architect, not many.
So you first of all need an enterprise architect to create the overall architecture for the bank’s systems.
Relating this to house building, you cannot have multiple architects
as then the doors and windows, joists and beams might all be different.
Sure, if you want a quirky house then that is fine but, if you want a
great house, you give the job to a single expert architect.
So that’s what we need in a systems context.
We’ve built many systems over the past fifty years without an
architect involved. Designers and developers for sure, but house
designers and developers create buildings that are inappropriate for
secure long-term structures.
This is the point of SOA. It allows us to create a technology house
built as a long-term secure structure for the bank, rather than some
The reason why this is important today is that we have technologies
today that conform with international standards. In other words, if our
systems were built like a house today, we would be using global
standards for cement, bricks and glass, whereas much of what we had
before was built using local materials that were good, but not for
We have global structures and this means we can rationalise into a
global architecture using standardised materials. That’s why we need an
enterprise architecture, an enterprise architect, and a clear long-term
secure technology infrastructure to evolve the bank into the future
with agility, flexibility and simplicity.
The second piece of the dialogue is that, if we did this, what’s the benefit to the bank?
This should again be clear, and it’s not woolly benefits about
re-usability and agility. Nope, it’s about reduced cost and increased
revenues. Using standard materilas means that if you’ve created a
program for a card payment once, for example, you can use that program
again and again and again. A little like if you manufacture a 6×4
glass window frame once, you can manufacture that frame 1,000 times for
zero cost overhead. That's what we can do today with systems.
And that’s the real point. Scale efficiency, standardised materials,
re-usability and repeatability. This way you minimise costs and
maximise returns. Before, many banks had systems that hinder
efficiency becuase they used non-standard materials and cannot be
re-used, replaced or redesigned easily. So what we had
before maximised costs and minimised returns. That's why we need to
In this context, an illustration of approach with results always
helps, so I’ll pick on HSBC’s CIO, Ken Harvey, who was interviewed by Financial Services Technology magazine last month.
In the article,
it states that he was “tasked by the Board with the goal of cutting
HSBC’s unit processing costs by 10 percent each year, and managing an
annual IT budget of around £2.5 billion.” This led to a complete
redesign and rationalisation of HSBC’s global systems infrastructures
and applications, with results that leverage global scale. Mr. Harvey
states that the “benefit has been 85 percent on the revenue generation
side, with only 15 percent on the cost reduction side.”
The whole point is that, by rationalising systems and making them
reusable, you can scale the efficiencies and leverage the capabilities
of a single design, many times.
I’m not saying that this discussion resolves the fact that
technologists and business folks don’t get on well, nor that SOA is the
right and only way forward, but technology folks should realise that by
sneaking IT rationalisation into the IT budget, they are missing a
The trick they are missing is that they are behaving as a silo
function without getting business buy-in. Without business commitment,
IT investments such as SOA, will just be some half-cut, half-hearted
effort, rather than realising the results that could have been
unleashed if this was delivered by the enterprise, for the enterprise.