Nestlés Nespresso SA division, which is headquartered in Paudex, Switzerland, recently announced the successful completion the first phase of their SOA initiative 'NesOA' in just six months! Optaros and MuleSource helped define and implement a new middleware architecture called Nespresso Open Architecture, or NesOA.
According to the press release and published case study
Nestlés Nespresso SA sells products in more than 50 countries directly to its customers and operates more than 117 prestigious boutiques in key cities around the world. [...] To enable massive growth in new online channels, Nespresso looked to pursue a new architecture and integration approach to enable these new channels and scale existing ones. Nespresso engaged Optaros and MuleSource to help its Corporate Architecture team define and implement a new middleware architecture called Nespresso Open Architecture, or NesOA.
We had a chance to catchup with Nespresso Enterprise Architect, Joel Schmitt, and ask him a few questions about the initiative.
InfoQ: From the press release, "We are committed to an open source approach, including MuleSource's Mule ESB, because complying with open standards is the key for future extensibility and growth," said Joel Schmitt, Enterprise Architect at Nespresso.
Based on that statement it seems like there might be some ambiguity on the benefits offered by open source vs open standards, both have their own merits but may not necessarily be complementary. Given that integration with a multitude of channels it is very important that the ESB supports the latest WS-* standards or Web standards in the case of RESTful endpoints for interoperability. What is the level of interoperability that the solution supports, and what are the transports and message transports supported?
JOEL: Though Open Source is usually leading innovation when speaking about Open Standards, that's true there is no complete overlap. For example Mule ESB is not relying on the JBI standard and we are still using it. Open Source and Open Standards are part of the strategy as they both guarantee vendor independence, ease the integration with variety of systems and different integration patterns. In term of endpoints, we are looking to support both WS-* and RESTful endpoints, and Mule/JBoss offers that flexibility today. Some integration requirements are about Services, some are more Resources, some are more about Messages – we intend to address all of them.
InfoQ: What is the strategy that is being used for getting various channels on board? Given that "Nestlé Nespresso SA sells products in more than 50 countries directly to its customers and operates more than 117 prestigious boutiques in key cities around the world" what is the channel adoption strategy that can successfuly bring all these channels on board?
JOEL: A standard integration platform does not imply a central instance and we are open to different deployment models (Mule ESB enables us to implement a fairly distributed model) ; also, having an ESB allows to create both corporate standards based services as well as customized facades to them (within limits...), making the integration effort minimal to all parties.
InfoQ: What are the characteristics of this intiative that make it different from a 'lets-integrate-our-legacy-apps-using-xyz-ESB'? For e.g. How much does this effort involves analyzing business processes and re-engineering for efficiency? How much re-use of services would you say is planned for? and how do the various teams (if any) work on services that might end up being reused?
JOEL: Legacy applications have been integrated having in mind to build new corporate services surfaced from each initiative - and reused for the next project when possible. NesOA is a program of re-platforming Nespresso middleware that include both business analysis/modeling as well as the implementation aspects.
InfoQ: What methodologies are being used in defining, designing, developing, deploying and governance of these services. Is there a formal process? What is the implementation strategy? What is the duration that the implementation is slated to take to complete?
JOEL: The NesOA program has been initiated 2 years ago with several pilot projects. It's not a big-bang approach for sure but a evolutionary re-platforming of the middleware based on the project portfolio - managed by the business. Each project brings its functional and non functional requirement, constraints and changes.
InfoQ: Given the recent bru-ha-ha over "SOA is Dead", what would you say are the key factors for success/ things learnt, that other companies with similar efforts could/should use based on your experience from this effort?
JOEL: NesOA is as much about "Open Architecture" than about SOA. We are using the tools and techniques from SOA but no radicalism about it. Moreover "SOA is Dead" does not mean that Enterprise Architecture, distributed system, services orientation and application integration are dead. They are still today reality in large corporation IT - and that's all about it. What may be dead are huge re-architecting initiatives to achieve service orientation for the service orientation's sake.
Given the recent economic trends will SOA; no matter what you call it, be it dead or alive; be the source for cost savings and business efficiency in the enterprise? The NesOA initiative might provide clues to finding the right mix of service orientation and architecture.