Architecture is more important than any individual vendor, said JP Rangaswami, CIO of global investment bank Dresdner Kleinwort Wasserstein, at a conclave of leading enterprise software practitioners held in London last week.
The invitation-only summit, held at DrKW's City headquarters overlooking London Bridge, was an attempt to begin drawing up a practitioner-driven manifesto of key principles for enterprise application development. Rangaswami dropped in to deliver his keynote vision of what enterprises expect from IT vendors and practitioners over the next few years.
One thing that has to change is that the IT function is going to have to deliver, he said. "Why do I have to wait for my business to come to me [as a CIO] and say, 'I want things to be better, faster, cheaper'?" CIOs already know that breaking down silos and achieving vendor independence will allow them to deliver faster collaboration at lower cost. They must get on with it, he said. The pace towards "consumerization" in the IT industry is accelerating, with today's graduate entrants expecting the same ease-of-use and rapid innovation from IT as they get from their mobile phone providers.
Open-source software plays a pivotal role in Rangaswami's vision. DrKW has been an early adopter of open source, funding the development of openadaptor, an extensible, Java/XML-based platform for rapid business systems integration. Rangaswami's experience leads him to turn conventional wisdom on its head and laud the lower risk inherent in open-source software when compared to proprietary alternatives:
There's no need to escrow the code in case the vendor disappears
Vendor independence means no one can withdraw support
Shared development leads to better quality code, with faster time to market
Publicly reviewed code is more secure than proprietary code
What all this means is that, for DrKW and other enterprises with a similar outlook, "the vendor community is now an open-source community," he declared. Instead of having to hand over huge license and maintenance fees to proprietary software vendors every year, enterprises now have the option of turning to open-source alternatives, or even clubbing together within an industry to fund their own open-source project (as, for example, a number of banks are said to have done in the AMQ message queuing project). This applies a form of utility model to the software infrastructure stack, he said, in which users collectively outsource the development of the stack to vendor-neutral open-source projects.
"The days when competitive advantage is based on code are gone," he added, citing business processes and shared expertise as the true differentiators for any modern business.
Service-oriented architecture reinforces the supremacy of architecture over individual vendors, he concluded. "I can't believe that we need more than one generic instance of service-oriented architecture. I do not see that we have to choose vendor x or vendor y ... We have to concentrate on taking platform-independent approaches."
Which of course brings us back to the reason the summit was taking place the need to establish some kind of statement of key principles that will help systems architects and developers standardize on a vendor-neutral, generic architecture for their organizations and the applications within it. Loosely Coupled will be writing more about the results of last week's deliberations once the results of the meeting have been finalized. All I can say at the moment is that the pedigree of the participants suggests that their output will be highly valued by the wider community and to watch this space for further news.
In the meantime, I plan to set the scene over the next couple of weeks with a series of postings looking at several pivotal questions that have emerged recently as vendors and early adopters struggle to arrive at a practical definition of what a service-oriented infrastructure should look like and consist of. I have been so busy over the past month briefing and researching on the subject that I have not had time to post. But there are a whole series of knotty questions that I'd like to explore, such as: What form should a repository take? How should policy be managed and mediated? Where does ESB fit into the picture? What is the SOA lifecycle and how to manage it? Where are the performance bottlenecks and how to avoid them? It's going to be a challenging but hopefully fascinating journey through these topics.
I shall also be posting more later this week on my ZDNet software as services blog on what JP Rangaswami said [update: now posted] about the future of enterprise applications it's controversial, provocative and insightful.