Service Oriented Architecture is the new mantra to ease integration between heterogeneous systems in the enterprise.
Lately, I have been having questions about this approach and this post comes out from different experiences. One being reading Vincent thoughts on the topic on TechItEasy.
The other being this excellent and lively presentation by Jim Webb and Martin “architecture guru” Fowler : SOA without ESB. The last was the presentation from Didier Girard during the excellent Université du SI conference in Paris back in early july. The bottom line of both presentations being : the web works. The Web is resources that are easily accessible.
Using Web Services for different systems integration within the Enterprise should be easy. We should have resources easily searchable and accessible. Hence these questions about how relevant Service Oriented Architecture stands as it is implemented today.
SOA the new J2EE (read bloated) solution ?
Are architecture astronauts taking over again ? Discussing the topic with Vincent it just occured to me that SOA was just like the next EJB around. This type of magical thing which is supposed to help “allowing individuals and businesses to focus on what they do best”. Eventually we end up with only one successful project out of 5.
I remember this serverside symposium back in 2003. (wasn’t there though, I was just reading the coverage). That was a cornerstone : Rod Johnson introduced Spring, Gavin King Hibernate and Bruce Tate presented his Bitter EJB book.
For the first time in Java hostory, J2EE myths were started to be analysed in an objective manner :
J2EE Myths and why they are dangerous :
- There are no simple problems
- Database portability is always required
- It’s ok to defer application server choice
- Distrust relational databases
- J2EE developers always know best
- J2EE allows developers to forget about low-level issues
- Achieve scalability through distributing objects (Stateless SesssionBeans with remote interfaces)
- J2EE = EJB
EJB was also the target :
Bruce looked at one of the classic anti-patterns: the “Golden Hammer”. This is the temptation to use this new tool you’ve acquired to solve every problem. EJB has become the modern “Golden Hammer”. Often, this is because people want to put this relatively new, hot technology on their resume.
Scott Ambler reminded that 65 to 80% of J2EE projects were failure and he contributed to make Agile methodologies popular with his Agile Modeling book.
We know how it ended up : Spring became the new J2EE (over industry standards), Hibernate became the standard for J2EE ORM mapping (again over industry standard JDO), Bruce Tate flew From Java to Ruby, Agile methodologies took off, Floyd Marinescu left java-centric serverside (which he had created) to set up infoq, more hybrid technology wise (Java but also Ruby, Rails, .Net) and topic wise (development, architecture but also agile, SOA, etc …).
SOA Vs Agile
I do like this definition of Agile methodologies by Mike Cottmeyer and V. Lee Henson in their essay The Agile business Analyst :
Agile is focussed on driving towards simplicity versus rather than creating systems that manage complexity
The most successful experience I had with Web Services was with a mere XML-RPC standard : Remote Procedure call in XML format over HTTP. This helped us build very quickly a Web Services Layer around a core of services and have all type of technologies (Ruby, PHP, Python, Java) using these services.
My 2 cents on the success of this solution : XML-RPC standard description is one page long. Compare with SOAP’s which is the SOA industry standard agreed on by all the industry big cats and the de facto protocol used in enterprise applications : 20 pages or so of abstraction to please all stakeholders : a pain in the neck for developers and for Agile development.
Gimme a REST
Back to Didier Girard, Martin Fowler and Jim Webb presentations : the future of SOA will be based on the same receipts that make the web the ubiquitous technology the net quickly became. Web is an infinite set of open resources, and the most appropriate architecture for web services should be based on this paradigm.
Besides, the internet has drastically changed the balance of forces in IT world decision making. As Martin Fowler reports it :
Tim Bray contended that the key decisions on technology are made by the programming community. (…) The reason we have so much bloatware in IT is because IT purchasing decisions are usually made on golf courses by people who have lost meaningful contact with the realities of software development.
My bet : in the same way that open source community naturally adopted standards such as Spring, Hibernate, and, to some further extents, RubyOnRails over bloated industry standards (EJB2, JDO and J2E Web Apps respectively), REST should emerge as the natural SOA standard over SOAP.
REpresentational State Transfer aligns Web Services CRUD possibilities to HTTP CRUD support : GET (Read), POST (Create, Update, Delete), PUT (Update), DELETE (Delete) and bring Web Services back to the web : a set of searchable and accessible resources.
I hope this will help saving Web Services from bloatware and help us aligning technology with the business goal.
#hypertextual 
Hey Cecil, thanks for writing this excellent post! I’m, as you know, a self-confessed non-expert in this area (thought that may change soon), and I can, for now, only base my opinions on very superficial things.
From my discussions with a company, a SOA implementation is really only worthwhile for larger (500+ employees) organisations, as this type of complexity is simply not needed by smaller ones. So the first question is what kind of organisations have you been targeting with your “agile” systems and do you think that these are able to scale?
Open source, in my experience, has some mixed quality-standards. I’m very impressed with Firefox 3 (not 2), and not Open-office. For obvious reasons, I think everyone is impressed with open standards on the internet, such as Apache and MySql. How do organisations respond to the open vs. proprietary solutions. Is it more a matter of price or are the performance-benefits so high that they don’t think about it twice?
I’ll probably come back with more questions later.
Incidentally, SOA stands for some kind of sexually-transmitted disease here in the Netherlands. I imagine there will be a brand-name change pretty soon 🙂
Good post Ceciil, my short experience with SOA also left me quite puzzled and with a feeling of bloat.
Vincent, I find it really strange that someone would think SOA is “worthwhile” in larger organisations. In my opinion, in theory, it doesn’t matter at all what’s the size of the organization, because it has nothing to do with that. What makes this even more puzzling is that everyone knows that agile systems do not scale.
One of the easiest SOA projects I did involved a simple REST-like service from a 5-man company. The only complexity was to prove higher-ups that it really was simple, would really work and, really. The project ended up six months late because of resource issues and our IT outsourcing fucking up firewall configurations, SSL certs, etc.
Kari, Vince ! Waow the TechItEasy mob is in da house. Thanks for your comments.
I was wondering if that was worst posting on TIE, it looks like it was.
Kari, I guess that Vincent is saying that SOA is only worth the investment for larger organisation. But just like J2EE i’m still amazed that this techno remain trendy despite the proven failure track record.
Regarding Agile, I’m not sure about scalability. What I know is that it works pretty well and the main principles are applicable no matter how big the company is : test all your code, integrate continuously, work closely with customer, do not waste time on deliverables that is not bound to run and use the system (eg useless specs etc …).
The main issue with Agile adoption always is more a cultural one than a scalability one.
Yes, expense was definitely a factor, but so was the complexity of the offering, which was felt to be too much for a smaller-to-medium-sized firm. The way I perceive SOA being used as a buzz-word in companies is not so much as architecture, though that is certainly a viable option, but as a collection of services that may or may not be suitable for a customer. In this case, it was deemed not to be so useful for smaller companies. I forgot the exact application, but something like SOA-monitoring software and Data-migration services were the ones in question, I believe. It’s also a matter of compatibility with the company’s existing software. A larger company will more likely be using a proprietary package, like SAP or Salesforce, for which specialised tools can be designed, while smaller ones may be more inclined to use things like open source and 37signals-software, for which a different tool-set is designed.
Thanks for answering the “agile + scaleability” question.
… and I hope to read more from both of you on Tech IT Easy, you hear? 🙂
I certainly do ! I shall be back soon.
Actually I’m reading all your posts on strategy. I’m currently extremely interested with this topic. But i dont have anythin interesting to say at this point regarding the topic. I’m more in an input mode.
Again, thanks for your inputs.
SOA Monitoring and Data Migration are 2 issues we are basically encountering in my current company.
Problem always is the same : since we want to abstract all complexity away from the user but also from the developper, the whole system is just losing ground with reality. Reality being in the IT world the infrastructure usage (performance of the system – network, server) and the database.
And if you dont address this type of issues early enough in your SOA project, they’ll catch you up. As Ray Ozzie puts it : delaying the inevitable inevitably backfires (http://blogs.technet.com/jamesone/archive/2008/07/29/systems-of-belief-and-ray-ozzie.aspx)