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 helium.”
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.
Oh dear.
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 higgledy-piggledy labyrinth.
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 global structures.
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 6x4 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 re-architect.
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 trick.
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.
Comments