Vaughan: People get new tools, like Web services, but as they work with them they use familiar patterns, and the new tools start to look like the old Corba tools or the C tools. The first thing a lot of people did with SOAP was RPCs. Is this now about stepping up one more level of abstraction to get a better view?
Toufic Boubez: I think it is. I think we're back on that track, which makes me feel better. But you're right. You mentioned the two big "C" words: CORBA and C. As a matter of fact, part of the whole vision of service orientation when I was at IBM--specifically because I had fought CORBA wars for a while, built CORBA projects for my customers, and I had seen a lot
of the issues of interoperability and vendor specific stacks and so on--was to learn from CORBA what's good in CORBA and actually fix it by making things interoperable and using standard interfaces and standard data formats and so on. But the whole RPC camp at that point I think sidetracked us and put us back several years, where people constantly just wanted to do RPC. And that I think was very, very detrimental to the whole service oriented architecture vision.
Yea, again from personal experience, I hear and I see a lot of people talking a lot more now about the concept of architecture, service architecture or service-oriented architecture versus the nitty gritty of bits on the wire, using SOAP or REST, or that kind of stuff. I think there's a general consensus that that adolescent phase is over and now we're a little more mature than that.
The other aspect is the maturity of the technology stacks people use. If you want to look at the WS stack, it's usable. You have security, reliability, etc. There's a usable technology stack that you can abstract at this point.
You don't need to know it completely, you just have tools that you build and the tools will generate anything that you want. There's not this obsession with the bits and bytes on the wire and now people are free to think on a little bit higher level in terms of service-oriented architecture. So on that level, there's a consensus about the maturity of the tools. Furthermore, MDA has brought back a little bit more architectural rigor to what we're doing. When you build a platform independent model, for example, you're abstracting out the bits and bytes. You're just making a model. When you actually want to implement them you go to platform specific model. I think it's just natural maturity.
Vaughan: Governance became the 'watchword' for SOA for awhile. Where is that going?
Toufic Boubez: Ah yes, the "G" word. I think it was part of the problem and I think it will be part of the solution. It was part of the problem because people were building services willy-nilly, and developers who got their hands on a tool kit were building stuff without a long view or an upper view of things. So governance became a problem until people started realizing that we need to get a handle on that. For a variety of reasons, the IT folks need to get a handle on it because of waste--there's no reuse--as well as security issues and management issues.
And the business folks realized they need to get a handle on it because of regulatory issues and because of absolute corporate governance issues. So everybody now is in alignment that they need to get a handle on those kinds of things, and the vendors started realizing that, and they started bringing solutions so that governance becomes part of the solution. That's where it moves from being part of the problem to part of the solution. And that's where we are now.
I do believe governance is fundamental. I don't think you should be thinking about building SOA without having a roadmap--if not, then the beginnings--of a governance solution at the start to understand how you're going to manage it. To me, governance, the "G"word, comes down to visibility, control, and compliance. For me, these are the three things that come to the fore when you're starting to think about what governance means.
Control is being able to activate things or deactivate things or move things back forth; having control over the components that go into building your IT organization, being able to create, delete, deploy, un-deploy. Compliance is making sure that whatever you build actually conforms or complies to your policies, whether they're IT policies or corporate policies.
Vaughan: What's next?
Toufic Boubez: We're dealing with SOA right now, but all of a sudden there's this big train that's coming our way which is virtualization. Another buzzword for it is "the cloud," but its virtualization. That's going to have a huge impact because we can barely deal with services in our data center now. Once we start using services from the cloud or putting services out on the cloud it's going to add another complicated layer to what we're dealing with. We're not even starting to be ready to deal with that kind of stuff.
This was first published in June 2009