I was finally able to post the seventh episode of IT Insight (Spanish). It turns out that managers work much harder than previously thought This episode is mostly about planning carefully an SOA implementation and avoiding common pitfalls. With this episode I think that I have covered the most important aspects of SOA for now. In the next episodes I will cover other aspects of enterprise computing. I will also publish a special podcast about Apple’s WWDC (World Wide Developers Conference) which I hope will be an exciting event.

A couple of days ago I attended a meeting of Java programmers sponsored by SUN to be part of a round-table discussion around SOA with people from BEA and other local companies. I had a lot of fun but this really isn’t the point of this entry.

During the discussion we were trying to explain what SOA was and how to design SOA based applications. What really stuck me was that we were all explaining how to implement and ESB from scratch and use it to create new applications designed from the beginning to use it.

The fact is that this is simply not true. SOA is not something that most people plan from scratch. What really happened is that in the late 90s, companies just started to lose faith in their IT departments. They started to buy ERP systems because they promised better reliability, functionality and performance. ERP and other CRM systems are the great failure of the corporate IT departments. Corporate developers in midsize companies could just not deliver the value their employers expected from them. As a result, the number of development jobs started shrinking.

However, the promise of ERPs did not hold totally true. Most companies need functionality not provided by their corporate systems and implementing it using BAPIs or other proprietary systems to extend them is normally much more expensive than doing it quickly in languages such as Java or PHP.

So, SOA is really the last chance for corporate developers to save their jobs. If they can use it to successfully provide additional functionality at a lower price than their ERP providers, then they can show value to their upper management and will probably be asked to continue developing. Otherwise corporate IT will lose their remaining developers and will finally be completely outsourced as systems administration is usually not strategic.

I got an email from Ana who disagreed with one of my statements over AJAX in my latest episode of IT Insight. What I said (translated from Spanish) was roughly:

“The MVC paradigm was designed to separate the application layer from the presentation layer. AJAX is a step back as it makes this virtually impossible”

She pointed out that the goal of AJAX is precisely to separate those two layers and that AJAX emphasizes the value of the code that resides within the server.

I must say that at first I was quite surprised that she wouldn’t agree with my statement since AJAX pages usually include a hell of a lot of JavaScript code. To me it was evident that this got in the way of having a clean “view” layer. However, after rereading the e-mail I realized that Ana had a web-designer background and I started to understand.

From a web designer perspective, it makes a lot of sense to consider the “view” layer everything that runs inside the browser. This allows them to work on a much larger projects and grab a larger part of the total application value. Today, most web designers working on large web applications only have a marginal role in the application development. They usually only develop templates that are later used by the application developers.

However, from an enterprise application developer perspective, this doesn’t make a lot of sense. Web pages developed using AJAX, specially recent complex applications such as Zimbra (http://www.zimbra.com) cannot usually be designed by web designers. That is because those pages do include some application code that is not trivial. Therefore, developers will argue that they have to develop those pages. They will probably also argue that web designers usually do not use version control systems or understand customer requisites. The idea is that by separating the two layers it becomes more difficult to manege the project as a whole. Using different languages for each tier (JavaScript and Java, for example) doesn’t make the problem any easier. That is why large corporations tend to prefer a single programming model such as J2EE.

In the end we must recognize that there is a power struggle going on between developers and designers. Both want a large share of the pie. Right now designers have the higher ground in smaller accounts while developers rule the corporate world.