As Vice President of the Finance and Enterprise Services Group, and chief IT architect, Prasad Rampalli is at the forefront Intel's quest to fully leverage the company's IT investment. Last week, for example, Intel announced that it has transacted more than US$3 billion in customer orders and US$2 billion in supplier purchases using RosettaNet electronic commerce framework this year. The company is also making its first foray Web services, focused on harnessing and unleashing the data in legacy applications. ZDNet caught up with Rampalli at a recent conference covering Web services.
ZDNet: How would you define Web services?
Rampalli: There are two definitions of Web services. One is the rigorous definition: The establishment of what goes on the wire, how it's described and how it's discovered-XML, SOAP, WSDL, and UDDI.
But if I step back from technology, the real focus goes back to the 100 percent e-corporation journey that Intel has been on for the past five years. We have gone from the fundamental Web-based foundation building phase to what is called value of integration, which is the realization of business value. As you get through the integration of heterogeneous environments of 1000-plus applications, five to 10 different programming languages and many database environments, we need platform operating system and programming language independence in the integration space.
This is not news to anyone who has been in the IT world. We have been on this quest for the holy grail of complete encapsulation and independence for a long time. I think Web services for the first time gets us to that promise.
How would you differentiate Web services from what came before, from traditional EAI?
EAI has been extremely valuable for Intel over past three or four years. It's based on the same conceptual principles [as Web services] but does have "proprietariness" about it. In that sense you are locked into a specific proprietary transport layer of a middleware product that you might have bought. For example, we've got an information bus that is extremely scalable but also locks us into a level of "proprietariness."
The ultimate speed measure of what we are doing in e-business or in enterprise applications is integration. It's got to be integrated across different problem domains and to be agnostic to the legacy heterogeneous environment. Web services gets us there.
Given you have 1000 applications and 45 locations, how do you decide what to attack first with Web services integration?
Web services is going through its initial maturity phase or, to some of the skeptics, the euphoria phase. It's really another reincarnation of enterprise integration from my standpoint. The problem domain that for which we have chosen to implement Web services as part of an overall integration framework is not in the publish-and-subscribe space, but in the synchronous messaging space. We believe we can get a complementary implementation of Web services with the significant investments we have already made in an overall integration picture.
Is that looking at total cost of ownership and taking what you have today and getting more leverage out of it?
That's right. It's not that we are starting from scratch. We've been on the journey for the past five years. In the past three years we have implemented significant integration across all of our applications.
For example, 60 to 70 percent of all core transactions across all applications that touch a foundational ERP transaction system go through an EAI middleware layer. We have a significant investment in the middleware that we are not about to abandon because Web services came along. We want to leverage the EAI platform and implement Web services on top of it, and then partition an appropriate use model of Web services against the advantageous publish-and-subscribe model that EAI offers today.
Based on how your IT shop is running today, you might want to implement the specific paradigms that you are disadvantaged on and leverage Web services for that. In our case we have chosen to implement the whole synchronous messaging capability using Web services for the internal enterprise. We are absolutely not going to the B2B space for known issues in security.
Encryption and security
How are you dealing with security today? Are you just ignoring it or waiting until security standards are more mature?
We are looking for all the SAML standards to come to fruition, but we are not passively waiting for the event to happen. We are actively engaged with Microsoft, looking at the their TrustBridge capability. We are doing some controlled pilots, but the real issue is how do we get to a level of encryption and security, a trusted machine-to-machine conversation using a B2B XML kind of message formatting.
We have championed the whole B2B commerce space with a lingua franca based on the RosettaNet standard. It is based on an XML messaging format and has a sufficient level of encryption to enable secure B2B conversations with the multitudes of trading partners that we've got. The SOAP XML-based messaging format, unfortunately, doesn't have the appropriate level of security we need to have a trusted conversation with our trading partners.
We do have an advantage of having embarked on the RosettaNet journey for over two years to the point where 13 percent of all our machine-to-machine, B2B transactions today are happening through the standard--roughly 30,000 transactions a month.
Over time, we can get away from B2B RosettaNet specific interactions to something that's customisable to whatever conversation you want using SOAP/XML, as long as we can get to a SAML standard that enables encryption. We have SSL that enables transport level encryption but anybody can spoof the destination of that message.
At this stage many vendors are claiming or do have Web services implementations, but they only work with their own set of products. How are they overcoming that problem?
We've got a breadbasket of ISVs [independent software vendors] who are rushing to the door to implement Web services. It's a given if you are a large enterprise you will have multiple infrastructures talking to the Web services in the environment. But the beauty of Web services is just that-it's essentially enabling isolation and encapsulation of your core back-end infrastructure.
That's the beauty, but is each ISV its own silo of Web services or are they communicating across those applications?
I am not aware of any cross-enterprise level partnerships at the semantic level of Web services interaction between these partners, but I am encouraged by the fact that all of them are enabling one form or another of Web services, which to me is sufficient for a faster pace to integration.
I'm not too concerned whether the back-end foundation is based on .Net or J2EE as much as an SAP connector running XML Web services is available that I can harness for integration. I am optimistic, seeing the glass as half full. Just getting to a common mechanism of how you publish information to a unique URL using Web services gets us to a level of standardization in the industry that we have never seen before.
You mentioned Java and .Net platforms. Do you think those platforms will interoperate sufficiently on their Web services implementations?
I think it remains to be seen. In the platforms we have built--mostly on .Net today--we haven't tested out complete interoperability at the transport level. Interoperability has to happen at multiple layers of the stack. At the messaging level you would expect complete interoperability. The question is will there be interoperability and synergy in the manageability aspects of Web services-the performance management and transport level management--of Web services. That is where the underlying protocol enabling Web services comes into play, and that remains to be tested.
Those are significant issues when you consider the notion of Web services as more of a distributed, decentralised environment. In the case of Intel, you've got a complex infrastructure in place full of nodes with intelligence that are passing messages through a Web services infrastructure. Is that complexity a huge issue, especially when you try to do it synchronously?
Even though it's distributed, it's not random or chaotic. It is [done] with a grand design. It starts with an overall data centre strategy that has overlaid on top of it specific business process threads that translate to specific applications that translate to specific pieces of infrastructure that are managed in clusters in such a way as you have security enclaves that you can implement down the road with disaster recovery and enable the right level of optimization of traffic on the network.
Hopefully, we can get to an appropriate Web services platform based on what we are building today, and by design have it built to a single hop from any application trying to discover Web services and talk to another application.
If you architect this right, you can establish a distributed computing model that gets you to the lowest TCO and the right agility without loss in performance or scalability. I'm not saying it's easy, but that's what we get paid for.
