By: Robin Bloor Published: 17th May 2006 Copyright © 2006

SOA Rant

Mentioning that Judith Hurwitz, Carol Baroudi and I are writing “SOA for Dummies” (our deadline for finishing this is towards the end of June) has generated more interest than I would have expected. SOA software vendors express a great interest, of course. They inevitably would because we will mention a number of them in the book. However I have also had other inbound email because of this.

One correspondent asked “What are your thoughts on vendors that claim to be 100% SOA today? I'm not a technical person, but have a basic (very basic) understanding of the concept of object oriented programming and also of exposing objects to be called by web services. I hear that many vendors are working on these kinds of the things, but for anyone to claim today that they are 100% SOA seems a bit of a stretch.”

These are my thoughts.

Anyone claiming to be 100% SOA is selling snake oil. Even SOA is not 100% SOA, so to speak—in the sense that there are still some unsolved problems to grapple with should you want to have wall-to-wall SOA throughout an organization. (You may not want that, of course.) Also, the most advanced vendors cannot provide everything needed for a SOA.

As our correspondence progresses, it turns out that the vendor who is apparently making such claims is Epicor. A visit to the Epicor web site reveals that they are a vendor of software packages. According to my correspondent, Epicor “claimed that 100% SOA means all parts of the application are Web services versus other vendors who have just wrapped a layer of Web services around the application and claim to be Web services enabled.”

Yes, but those other vendors didn't claim to be 100% SOA, did they?

However, it all starts to make sense now. Epicor is really claiming to be 100% Web Services enabled. A package vendor could make such a claim. But WEB SERVCES IS NOT SOA!!! I think many analysts are going to have to say that many times before the world takes note. Epicor might just be able to get away with saying that its products are SOA-ready. Maybe they are? But if so, that requires a little bit more than exposing all the application interfaces and functions as Web Services. For example, how has the namespace for these Web Services been constructed?

Epicor is trying to steal a march on its competitors, who include SAP and Oracle. So, it is claiming SOA credentials. In my view, it can only claim Web Services credentials. SAP and Oracle, by the way, could make some realistic SOA claims, but neither would dare to suggest 100%. They'd get laughed into the orchestra pit.

I tell this to my correspondent, who pings me back to say that Syspro is making similar claims to Epicor. So we are not dealing with a single aberrant vendor here. We may even be dealing with an epidemic. Web Services is not SOA in the same way that a squirrel with a limp is not a rat with a hat on. They are not the same thing and they are not even close relatives.

Something has to be done about this mangling of terminology and I propose the following:

Everyone in the marketing department of those companies that are deliberately or even accidentally confusing SOA with Web Services must stay behind after work and write out 100 times (to be later sent to me):

I must not bend, fold, spindle or mutilate industry terminology and architectural concepts without expecting to incur the appropriate sarcasm from the IT analysts.

The above sentence is based on the school lines I had to write out when I had misbehaved at school, and writing it 100 times will be a chore. The punishment surely fits the crime. And by the way, I will not accept these lines sent in a Word file. They have to be written by hand in pen, with accurate punctuation and NO CROSSINGS OUT.

We're done here.

AVID: Shame Again

AVID, which stands for Anti-Virus Is Dying, is a semi-regular item in this Blog. AVID is my quixotic campaign to dismantle the $3.7 billion AV industry. The AV industry doesn't deserve to disappear because its signature-based AV products offer inadequate protection to their users—if there were no alternatives to such technology, it might be excusable, but as it happens software products from at least 3 vendors; AppSense, Bit9 and Securewave (and possibly others) can and do make computers 100 percent virus-proof—and in the right way. Let's stop the madness.

My last AVID posting published a League of Shame, exposing the amount of time that the AV vendors leave their customers vulnerable when a new virus appears. Was it a surprise to you that the two biggest AV vendors, Symantec (27 hours 10 minutes) and Network Associates, which markets the McAfee AV product, (26 hours 11 minutes) were among the three worst responders in this particular survey? It didn't surprise me. “Par for the course” was my thought.

An AVID reader pinged me, saying she thought that maybe I should also publish the names of the companies that were at the bottom of that League of Shame. Should I or shouldn't I?

I think I should, because it gives an indication of how long it takes to get an AV fix out, even if you do the job as quickly as it can be done. In the survey the fastest responses came from Kaspersky (6 hours 51 minutes) and Bitdefender (8 hours 21 minutes).

My correspondent also mentioned that her company was now looking for alternatives to AV, but wouldn't be doing anything until their current license expired. Is this a straw in the wind? Well it might be, but it isn't a whole haystack. One swallow doesn't make a decent meal—as friend of mine from Liverpool used to say.

Nevertheless time is on my side. You will understand why I believe that, as the AVID blog postings roll out.

Reader Comments

We are no longer accepting comments against this item. We suggest contacting the author directly.

17th May 2006: 'Stanley Goodrich' said:

The claims made about SYSPRO being at the forefront of SOA were made, not by SYSPRO, by a very prestigious research company, AMR Research.

Reply to Stanley Goodrich?

17th May 2006: 'James Norwood' said:

Perhaps Robin would care to get a full briefing from one of Epicor's technical team on our 100% SOA. Whoops! I'm a marketing person so I better go write those lines....Seriously, if it helps we would be happy to discuss our approach to service-orientation.

Reply to James Norwood?

18th May 2006: 'Sean Wheller' said:

Admittedly, marketing can stretch and blur the lines. Yet, even when they don't, it is not uncommon for people to become confused. When you consider the subject of SOA, it is complex and often difficult to grasp in the abstract. If it were not so, then everybody would be understanding and we would not have to go to such lengths as writing entire books on the subject. The truth is, there must be hundreds of misconceptions about SOA, but this problem is not unique in technology. In my opinion, the most prevalent misconception people have about SOA is that it is about a technology or a vendor product. It is not difficult to understand how this misconception evolves. Often, in an attempt to add clarity, explanation using implimentation methods and their associated technologies are the only way some audiences can understand the abstracts discussed. Well presented descriptions, illustrating the technical nuts and bolts of an architectural implimentation do add remarkable clarity. As a result, the mere mention of one or more technologies in the same sentence as SOA is, over time, bound to confirm the notion that SOA is technology. Some technologies that may be used in the implimentation of SOA are given greater favor and so greater exposure. Web Services (WSDL), is one such name that has become synonymous with SOA to the point where people think Web Services are SOA. In reality Web Services are not SOA, this is true, Web Services are one of the many technologies that may be employed in a SOA. In practice, the use of Web Services as a technology for implimentation is preferred by many vendors. A simple Google for 'web services SOA' or a visit to http://www.service-architecture.com/ will both confirm this and illustrate how the misconception arises. As for statements to the effect that something or somebody is "100% SOA." In context of what I have just said. As professionals with an expert opinion, I think we must guard from taking one or two words and using them out of context. It would probably be wiser for us to read the full text in an attempt to understand the intent. Yet, it is not unreasonable for either Epicor or SYSPRO to state that they are, "100% SOA Compatible" or have built a solution "based 100% on the principles of SOA." Which, having read several articles by both companies and AMR, seems to have been the intent. Next, in my humble opinion, we also need to guard against being baited into impassioned opinion based on the out-of-context request from a correspondant and therein attaching derogatory connotations. There are better ways to get publicity for your work and besides, it just creates a storm in a tea cup that makes it even harder to get the message of SOA across. On a more upbeat note, I am delighted to see that Judith Hurwitz, Carol Baroudi and yourself will publish a book on the subject. I look forward to reading it. -- Sean Wheller (Author of the book, "SYSPRO on SOA")

Reply to Sean Wheller?

10th April 2007: 'Dean' said:

Epicor has many applications and I know a few of them quite well. I can vouch this much regarding the application named ITSM (Information Technology Service Management); the client application makes 100% of its API calls to the server via Service Orient Architecture (SOA) over SOAP.

The client as well as the sever were created in the C# using the .Net framework 1.1. The client uses WinForms as the presentation layer rather than WebForms. So you can see this is not a web application, but a SOA application that uses port 80 (the web port) for service calls.

Reply to Dean?

2nd May 2007: 'John Walsh' said:

This architecture may be responsible for the apparent issues with performance with Epicor Vantage when using MS SQL Server as it's database rather than it's "native" Progress database which appears to still "manage" the schema even when SQL Server is deployed ? Certainly I have seen many forum posts which suggest that under Progress Vantage runs fine, whereas under SQL Server it has some serious throughput issues. See posts in ERP-Select in ITTOOLBOX forums. Most posts are by unhappy Users. SOA is still a very wide church and to claim 100% SOA compliance assumes there is something to comply to ? Which clearly there isn't. The closest you can get is in two camps A) exposed API's for all objects, all transactions, and B) transaction threads which deliver a complete transaction end-to-end with certainty (as is expected with good old EDI). There are no other forms of this technology except in the minds-eye of the pundits. Lets try to keep the application of technology to things that TRANSACT in one way or another. Otherwise SOA will just become another income generator for the industry and its advisors/consultants. Call me cynical if you wish. Regards John
X :)

Reply to John Walsh?

3rd May 2007: 'Clint Murdoch' said:

Without a doubt, Epicor's Vantage product has significant issues. It requires massive system requirements, but doesn't seem to benefit much beyond a certain level. For example, client machines should be P4 3.2GHz w/1GB RAM but client forms still take a fair amount of time to open (complex forms can take up to 20 seconds). Putting the client on a new Intel Core 2 Duo E6600 system with 2GB PC26400 RAM doesn't significantly improve the user experience. Even massive servers with impressive disk arrays and gobs of RAM make almost no difference. There are still situations (like receiving large POs) where there is enough delay moving from line item to line item where I’m sure your staff will grow extremely frustrated. Additionally, Epicor does offer SQL Server as an alternative to its native Progress database, but even with SQL Server installed, there is a “Progress Layer” which holds the schema for the database. This added layer of complexity makes doing upgrades a real treat and a source for Epicor employees to constantly remind you how you should be using Progress instead. However, in my talks with other Epicor customers, they have been very vocal about the fact that the product underperforms and has a fair number of bugs no matter the database platform. To Epicor’s credit, they’re working very hard to remedy these problems. Unfortunately, the fact that they’ve had so many troubles for the past two years with their 8.0 Vantage product says that their architecture still has a long ways to go before it’s a truly customizable, well performing product.

Reply to Clint Murdoch?