The Raven

SOA from the trenches

I'd like to report a little on one of my last year's SOA projects. The goal of the project was to establish a basic J2EE infrastructure with SOA in mind. A basic Business Use Case was picked, that forced us to integrate with various backend systems (via Web Service, JMS and JCA). So we just decided to go with a JBI-based ESB and give JavaEE 5 (in particular EJB3 and JPA) a try.

The customer didn't have too much experience in neither J2EE, SOA nor Project Management so things went the wrong way very quickly.

Business Requirements

A lot of time was wasted until we had figured out, what would be the valid Business Requirements. I'm not sure, but I think the Use Case (and it's description) was not fully fixed even after 6 months when we left the project. The problem might have been, that the people from the Business Departments didn't get, what the project was all about.

Tool Hell

Even before we had a first architecture draft at hand various parties (internal and external) popped into the project and demanded that we used MDA, a BPEL engine, a Registry, a new Build Tool, a new GUI Rendering Framework, etc. All different vendors you can think of, partly Beta-quality software. Did I mention, that there had also newly been introduced a full blown Project Management and Collaboration Tool noone ever had worked before with?

Waterfall-modell

Since the customer was a government related organization we had to proceed after the V-Modell 97 (the old version), which is the standard for german federal administration and defense projects. It is very document centric and Waterfall-like, changes were only hard to integrate. All the lessons we learned were dismissed, since we had to proceed to the next  mile stone. We didn't have a chance to correct our earlier errors and thus the overall result was extremly bloated, fragile, imprecise. The stack of documents consistently inconsistent, the implmentation awful.

Wrap and Re-Use

We had to integrate one of their latest, greatest and newest services, that was considered to be SOA-ready out of the box. No earlier than during implementation we discovered, that there were several design flaws inside the service. First it was tightly coupled to a service from a completely different domain. Secondly it exposed only a non WS-I BP compliant RPC-encoded Web Service interface. Believe me, the solution to ship around that issues was quite ugly.

Consequences and my personal Advice

• Don't start to introduce SOA by implementing a Business Use Case. The Business Use Case isn't what your SOA Project is all about. Yes, I know, we're preaching Top-Down at almost every SOA Architect's presentation. The point is, that you first should take a deeper look on the Services you're going to need. If you are going to "Wrap and Reuse", take a look at the interfaces first. If the service not SOA-ready (or not even ready to be "SOA-tized"), consider implementing it new. So, I think a little Bottom-Up can't hurt.
  
• Start with a (very) slim tool set. Otherwise you end up in spending a lot of time integrating a number of different tools and best practices, that hadn't been designed to work together.
  
• Last and most important thing: Understand that your Service-oriented Architecture is a living thing. At least plan for some iterations when setting up basic infrastructure and architecture for your SOA.
  

 Disclaimer: This is my personal opinion and not Sun's
 

Posted at 04:50PM Feb 06, 2007 by Armin Wallrab in SOA, BI and Governance  |  Kommentare[2]