InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Optaros and MuleSource Help Nespresso With Next-Generation SOA Solution

Posted by Dilip Krishnan on Jan 30, 2009

Sections
Enterprise Architecture
Topics
SOA Appliance ,
SOA ,
SOA Platforms ,
ESB
Tags
SOA Adoption ,
Casestudy ,
Mule

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.
 

  • This article is part of a featured topic series on SOA

No comments

Watch Thread Reply

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.