q&a George Galambos, IBM Fellow and a contributor to the ubiquitous banking framework, explains the key business drivers behind service-oriented architectures. Also: The future of Java and .Net
Without George Galambos, we might still be stuck carrying cash.
As a longtime employee at IBM Canada, Galambos was a designer on the team that built the Interac network connecting bank machines around the world. The result was an open
system that allowed almost any card to be used in almost any machine, regardless of the user’s financial institution. Many companies are now trying to achieve the same thing with their IT architecture. Today, Web services often have to run on a specific platform, but service-oriented architectures have the potential to create a more “loosely coupled” environment that would be more interoperable.
This is the area where Galambos, who has also designed case management systems for Revenue Canada and Citizenship and Immigration Canada, spends much of his time. He was the first Canadian Big Blue employee to be appointed an IBM “Fellow,” which represents the firm’s highest technical achievement.
ITBusiness.ca spoke to Galambos when he was in Toronto visiting customers on Tuesday.
ITBusiness.ca: Where are you seeing the most rapid adoption of service-oriented architectures, and what are the business drivers?
George Galambos: Not surprisingly, those are industries that are in the highest degree of turbulence, which is finance and insurance, probably because they are continually trying to find how they can grow and at the same time how they get market share of their big clients even if they don’t grow. The other one which is actually quite keen is the retail industry. That’s an interesting area, because you wouldn’t have expected retail to be at the forefront of technology, but in fact they always have been. If you look at the fraction of business processes and activities which have been automated by information technologies or with special devices to help them to move along, retail is quite ahead of the game.
Beyond that, any industry which is heavily relying on business processes – I know that everybody has business processes, but some of them are more reliant than others – would be a good candidate, and in fact are highly interested in service-oriented architectures. I believe the primary value of service-oriented architectures is to bring business processes rapidization, business process understanding, business process modelling much closer to the point, where the information technology is all speaking the same language as the business does.
ITBusiness.ca: SOAs allow you to implement a service in .Net or J2EE but have the application consuming that service running on a different platform or language. How is that going to affect the growth of those competing platforms? How heterogeneous will future IT environments be?
GG: As far as service-oriented architecture is concerned, it thrives on heterogeneity. The whole reason why it has become so popular is because people always wanted to live in a heterogeneous world without paying the price for heterogeneity. In my long career, actually, I must admit I’m guilty of promoting homogeneity – and don’t think it’s because I’m an IBM employee, not at all – but because I do believe that in the IT-driven opportunity for operational excellence in system design as opposed to pure programming, heterogeneity actually causes interruption. And (users) are aware of the impediment. Nonetheless, in this new world, where companies are relying on getting essentially the best packages and the best capabilities they can find available, it demands heterogeneity on the outer boundaries. As you come closer to the consumer, things become very homogeneous. That’s the beauty of it: heterogeneous at the source, highly homogeneous when it’s being consumed. It may or may not promote heterogeneity. It gets clearer that both .Net and J2EE have their successes and they will be there for a while but by there might be other top languages that come along which provide a tighter and better affinity to the underlying substrate, or provide an easier way to a link to how people think. I know that J2EE and .Net are made to drive business value, but they can be improved upon. One could say that service-oriented architecture creates a very clear division between the deployment, which is not really interesting, and the actual result, which is interesting. As long as all the results are projected in a standard way, it may not matter.
ITBusiness.ca: What will then be the future for object-oriented programming?
GG: I’m really talking about component-oriented architecture, and the reason I draw the distinction – although I would not dare to claim components don’t derive from object orientations, they do – but object orientation were very good in solving a part of the business problem. They didn’t prove to be as useful when you wanted to go into the second business problem of the same kind. Components, however, being closer to business functions, they tend to be easier to recognize as being useful and as such they may help a lot and promote reuse. My proposition here is that component-based architectures are the ones which are really going to evolve. In fact, both .Net and J2EE are component-based architectures and they will take the advantages of those best examples of the object-oriented thinking.
ITBusiness.ca: There are so many standards in this kind of work. Were there any sort of lessons you learned in designing the Interac network that you bring with you to the SOA realm?
GG: First of all, I want to emphasize I was a mere member of the team of the Interac interface development. As you may know, Interac was a specification put together by the banks in the late 80s, early 90s and in fact they invited two vendors to propose and then create the other part of the package. IBM was one of them, and both vendors had to develop from the same set of standards, and that’s a very interesting point. Most of the standards were defined the Interac organizations themselves. That was very important, by the way, because here were two professional suppliers to had to make sure they could fully interact and actually pass an interactivity test before they could make a practical network, but by defining standards, you were rolling the die in favour of success. If you go by the standards, you obviously passed the test. Standards which support interactivity are extremely productive, useful, standards. At the same time, standards are very slow to merge. There are some cases where the technology would have been impeded if we were to wait for a standard.
ITBusiness.ca: What do you think it will take to trigger the second wave of SOA development once the banks and retailers have established theirs?
GG: Well, I’m not sure I see such a clear division between the waves. It depends on how we define the wave. One of them is internal and external use of services, publishing of services, that could be one wave. The other one could be a phase of publishing services before thinking about business processes, or thinking about business processes immediately as a motivator of publishing the services. There are companies who are well into service orientation with the express purpose of projecting their influence and capabilities outside of the boundaries of a company. One of them is a very well-known credit card company that automated their dispute resolution by making access to disparate data, including most immediate as well as document around a particular dispute to their clients. And that’s without making an effort to internally transforming a data environment into an SOA. Other companies are working on creating services inside, primarily where it’s a way to promote reuse, and it is much more promising than object-oriented programming used to be.