CERN Finds Success with SOA

Loraine Lawson

After patiently assuring Loraine Lawson that CERN was not attempting to create a black hole on the earth, Derek Mathieson, section leader responsible for the E-business systems at CERN, discussed why the research organization decided to adopt SOA. CERN, which stands for European Organization for Nuclear Research (derived from the French Conseil Europeen pour la Recherche Nucleaire), is the world's largest particle physics laboratory and home to the Large Hadron Collider.

 

Lawson: As I understand it, you have a good case study involving SOA and BPM (business process management). What was the business challenge you're trying to solve? What were you trying to get done and what were the challenges you were addressing?
Mathieson: We're an international laboratory based in Switzerland and France; it's on the border, near the city of Geneva. We run the world's largest scientific instruments and the Large Hadron Collider, which you've probably seen on the news. On site, we have roughly 2,500 people actually working on the accelerator complex and on all the infrastructure related to the running of the accelerator.

 

In fact, our population is probably near 11,500, so there are over 9,000 scientists who participate in activities with CERN. They are based all over the world - literally all over the world. I think it's 80-odd countries with institutes that are participating in the experiments that we run at CERN.

 

And as well as actually working at CERN and participating in experiments, they obviously have to have business processes, things like purchasing materials, having things delivered, transporting materials across the world. And they need to initiate these business processes, even if they're not located physically on the CERN site, or they need to participate in terms of making approvals, adding comments, adding information to electronic forms and this kind of thing. So, we have basically an international organization spread across the world and yet we have many business processes that we need to be able to get these people to interact with. That was the fundamental problem that we were trying to address: how to build the system to address this issue.

 

Lawson: May I ask how you were doing it before?
Mathieson: CERN was founded in 1954 and the only solution that existed in those days was paper. So we used paper and we had many, many thousands of pieces of paper flying around the world. The scale of CERN was a bit different in 1954. It was basically a European organization, so consequently the paperwork was going around Europe quite a lot.


 

As times have gone on, the collaborations got larger and included more and more countries. So we first started automating processes in an electronic way back in 1989. This was still based on a mainframe system, so you physically had to be at CERN in order to be able to do anything. The only process we automated at that point was an interface, basically, into our purchasing system. So you could more or less do purchase orders using this tool, but not much else.

 

Then from 1989 onward, probably for the next 10 years, we were working on a system that was essentially client-server based. That's when we started having the possibility of using this tool from outside the CERN site.

 

In 1999, we moved to the Web. At that point, we had probably around about a dozen different processes that we were automating. So we had already increased the scope quite a bit and we were handling things like, not only purchase orders, but vacation information, approval of vacation. We were also doing things like logistics, so we were handling the movement of materials around the site and on and off the site.

 

When we moved onto the Web, we increased the scope again. We were also increasing the user base and that's when we were probably in the region of about 6,500 users. Since then until about now, we've increased the size of the application and are automating more and more processes. We're now into the region of about nearly 50 processes that we'll automate using the tool. As I said, we have about 11,500 users and we have about 2,500 business processes active at any time now.

 

Lawson: How would you describe the system? It's SOA-based?
Mathieson: Yes, it's SOA-based. Underneath, it's a BPEL process engine, which is automating all of these processes as much as possible. Then it's Web service interfaces. If you can't talk to it using a Web service, then we typically write a Web service wrapper around the thing we need to talk to.

Obviously, you have to take a pragmatic approach. Not everything is ready to be Web-enabled or Web service-enabled or to operate in a SOA style. We have quite a lot of legacy systems that have never heard of Web services or anything like it, so we have to be pragmatic. Some interfaces are nice and clean and are done as proper end points, as Web services. Other interfaces are basically wrapping up stored procedures into one of the accounting systems or the purchasing system or these kind of old-fashioned, big Oracle applications that we have. You have to make a decision and wrap it up as a Web service so the rest of the system can continue to work in a SOA style.

 

Lawson: So was there one particular problem you couldn't do that forced you to reevaluate your approach and move to SOA? Or was it just evolving the system so that everything was moving in that direction?
Mathieson: This was more or less forced upon us. Originally, we were using a BPM tool from Oracle called Oracle Workflow. That was automating all of our processes. Basically, it was a big server application that did all of the process automation within the database engine itself. That product reached the end of its life and we started looking around at the next thing that we should use in order to do business process automation.

 

That's when we started coming across BPEL as the next logical step. The difficulties that we had been having up until then were the integration issues. We have many, many different systems, many different technology stacks, and we have to somehow have some kind of unified view of all of these different systems. So it fit quite nicely into this idea of building a standardized interface between the different systems and so that was basically building a Web service interface to each of the different systems.

 

Then as soon as we had the Web service interface, it was fairly natural to automate it using something like BPEL, which is very much a service-oriented style of process automation where everything is an end point and every process is in itself a Web service.

 

Lawson: In the U.S., people are disillusioned with SOA. Since you seem to have found success with it, do you have anything to say to those of us here in the United States about SOA?
Mathieson: I think a lot of it comes into being pragmatic. It's not the panacea, it's not the answer to all of your problems, but it does allow you to have a much cleaner interface if you have -- which a lot of people do, I'm sure -- a wide variety of different technology stacks in your organization and you need to find some kind of common interface. Then the SOA approach of having a well-defined technology-independent interface is a very good approach. It's something that has served us quite well in building interfaces between the different systems. I mean, it's coming down to the contract-based programming, where you define up front the contract between two systems and SOA allows you to do that.



Add Comment      Leave a comment on this blog post

Post a comment

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.


 
Resource centers

Business Intelligence

Business performance information for strategic and operational decision-making

SOA

SOA uses interoperable services grouped around business processes to ease data integration

Data Warehousing

Data warehousing helps companies make sense of their operational data