Later Edit: I would take what is written below with a grain of salt. It is not N-tier architectures which gave birth to SOA, but rather the drop in communication costs which made feasible connecting various applications which previously could not be connected. At about the same time EJBs were released and coincidentally they became the main way to connect applications. As time moved on the EJB complexity started to become the main cost of communication (once bandwidth became cheap the costs of communication moved up the stack onto the protocols used for communication) and competitors to EJBs (Spring, REST, etc…) started to appear and claim marketshare. As the costs of communication between nodes went down (first the physical costs, then the costs of connecting to the applications thru a thick stack) more and more applications started to get inter-connected and issues such as overlapping responsabilities between applications, release management in a distributed environment, etc… started to become the main costs of communication. SOA governance (a set of policies for interactions between applications and enforcement mechanisms for these policies) is the main attempt at solving these problems and at pushing these costs down.
The term N-tier architecture used below is a bit stretched: while most of N-tier applications consists of 3 tiers (presentation, business logic, data storage), I used the N-tier architecture term for an architectural style in which functionalities are assigned to a tier and each tier is hosted and developed on a dedicated application, a tier being more or less close to a node.

And now the original post: 

The more I read about SOA the more I get the feeling that it grew out of N-tier architectures and that one its boosters was the so maligned EJBs.

When you are looking at an N-tier architecture you will probably notice the communication between various nodes providing various services to each other: this node gives you data on commodities, another one on users, another one on tax transactions, etc… The result of such an architecture is a proliferation of services on various nodes, services which have to be managed one way or another. In comes SOA to the rescue which manages the relationships between the services provided by various nodes thru governance (it is a lot more complex that this, but let’s keep things simple). It is the distributed nature of the N-tier architecture that created all these conversations between nodes, conversations which were then turned into services, services which started being managed with an SOA mind-set.
I think I am right when I say that SOA comes from distributed computing and that once the interaction between various computing nodes reaches a certain threshold it becomes mandatory to manage this interaction. If I was to look at the various distributed computing platforms I would pick EJBs as the ones which were dominant in the last 4-5 years, the ones with the greatest mind and market share. The built-in distributed nature of the EJBs has been frequently denounced as resource-hungry, backward, one-size-fits-all design. It would be ironic if this very nature played a part in the birth of the SOA paradigm, a paradigm that promises to start a whole new era in IT development.
What would be interesting to watch is if the various design patterns that the EJBs have spawned (business delegate, service locator, data transfer object, etc…) and that were sometimes denounced as band-aids to EJBs’ horrific problems will appear in one form or another in the IT environment which enables SOA. After all, the above designs patterns are mostly concerned with distributed computing.

Later edit: Communication between various systems existed long before EJBs, this is for sure. However, the EJBs increased the communication between various systems due to their distributed nature.

I have picked up economics as a hobby. It is a very interesting field and I think it pertains significantly to software development since it deals primarily with the efficient allocation of scarce resources.
Anyway, I started looking at various applications thru an economists’ glasses. Let’s take a look at various P2P applications. Peers on a P2P network have a weird economic status: they are both consumers and producers (distributors?) of the same good, namely content, a peer downloads content from another peer and then publishes the same content on the P2P network. Well, this is pretty interesting, but what I found more interesting was the differentiation between various P2P networks. BitTorrent emerged as the dominant P2P network primarily because its P2P client distributes the content (the product in our example) as soon as it gets it. The rest of the P2P networks do not do this, they wait for the whole file to be downloaded before making it available to the rest of the network. When you treat a BitTorrent peer as a producer/distributor you see that it makes its product (the content shared by the P2P network) available much sooner than a peer on a competitor’s network, you can say that a BitTorrent peer has a greatly reduced time-to-market than a peer on a competing P2P network. And we all know that companies with reduced time-to-market usually beat the competition ;-), this would explain both BitTorrent’s incredible success as well as the rush to copy its economic model (namely having the peer share content as it receives it rather than at the end of the file reception which translates into a reduced time-to-market) by the competing P2P networks.

Another software design aspect which I tried to treat from an economist’s perspective is the managed environment (EJB containers, IoC containers, AOP-enabled environments, etc…). In the managed environment the developer is focusing exclusively on the business logic that has to be implemented while outside actors manage transparently issues such as concurrency, security, transactions, etc… Such a managed environment ressembles a vertically integrated organization which outsources its tasks (out-tasking is a pretty popular word these days, did you know that ;-)?) to a specialized work-force. Such an environment adapts itself to a changing environment more easily because it is the sum of some loosely coupled entities rather than a rigid entity whose elements are hard-coupled one to another. The modules that make up an application running in a managed environment would be very similar to the resources making up a multi-national: the modules/resources can be loaded/hired or let go according to the application/multi-national’s needs as these needs come or go. The result is a leaner application that responds to changes in the business environment more easily (again similar to a multi-national). The application would be a composition of various modules carried out by different actors, just like a multi-national is increasingly a composition of various tasks carried out by different actors. I’m not sure if I am seriously going off-road…

Anyway, I find mixing software design and economic theory fascinating and I will try to continue to treat various software design issues from an economic perspective. Comments welcome!!!

I’m looking at how the business processes become more and more complicated and I get a feeling of deja-vu. Business processes are becoming more and more complex, they are increasingly inter-related, they are created by persons not trained in security and more often than not they are done by ear. A business process resembles more and more a piece of software in the 70’s before electronic pirates started looking in it for exploits. Currently a business process is created for primarily for carrying out an economic activity, there is not much thought given to the possibility that someone could exploit it. One more thing which brings this 70’s flavor to it would be the legal vacuum in which business processes dabble (is someone guilty if it registers with an organization and that organization lets its user role access to an asset it should not have access to?).
The question that I am asking myself is: is it possible to “hack”* a business process, that is, to find weaknesses in it and exploit them? Is it possible to twist it to ends not considered when the process was originally conceived?I think this question is an early question, the current low level of complexity of business processes doesn’t allow much room for extensive re-engineering of the original process. So far the re-engineering of a business process is more often than not an innoucous mash-up and not a hidden attack against various assets. I searched the web for information on business process hacking and I didn’t find much, an attack against ChoicePoint and another one against Lexis Nexis. It could be that (just as computer hackers in the 70’s) these hackers are flying below the radar and not attracting much attention.
I don’t think we will see business process hacking on a massive scale for a while, but it remains a possibilit which should be seriously considered when designing a process.

* In this posting I will use the term “hack” as with the meaning of gaining unauthorized access to various capabilities (not necessarily computer systems) due to the new complexity found in business processes. I am not including here the larger and more accepted term of tinkering with a “black-box” in order to gain understanding of its internal workings.

Later Edit: From this article (read to the end) it looks like process re-engineering is slowly emerging as a threat of disruption of normal business activity.

I was reading (belatedly) Crazy Bob’s rant about Spring. It is an interesting point, the fact that your configuration settings become code because they do what code is meant to do, that is, they implement a desired behavior. Yes, the lines between configuration and code blur, just look at the number and size of various XML descriptors which are popping up everywhere. So, I would say the Bob was right about the fact that your Spring XML descriptor is code.
However, he was definitively wrong about Spring configuration file being intrusive. Yes, you need such a file for your application to be bootstrapped correctly, but you do not need to abide by Spring’s XML descriptor. The Spring XML descriptor is a window onto a particular binding mechanism, there is nothing that requires you to use this particular file. You can set-up your configuration syntax, write a parser around it, plug this parser into the IoC for application bootstrap and have Spring use your own bootstrapper with your own semantics. It is not going to happen over-night, you will probably need an in-depth knowledge of Spring, but if you are concerned about developing in an intrusive environment you may want to look at it. (One danger of going this route is that your syntax will diverge from Spring’s syntax and new additions to the framework’s syntax (such as AOP) will have to be re-developed according to your environment. In the case of an IoC container using a different syntax is very similar to forking a project and has pretty much the same synchronisation problems.)
Another option would be to create your syntax, have a translator which converts your XML descriptor into an Spring XML descriptor and have your application run on the Spring descriptor your translator would produce. You are running the same dangers as before since you are basically forking a language.
Or you could take a look at the XML namespaces that have been added to Spring 2.0 which include extended XML authoring and have all your problems resolved (you can find a small tutorial here). I really like the fact that the Spring community decided to do away with the only thing in the framework which cold have been regarded as intrusive and to do it in style ;-). Again, the Spring XML descriptor was just a window onto a binding mechanism which could have been replaced/enhanced with another window at various costs. It was not intrusive, it just carried a lot of weight. Well, this weight disappeared. Nice move.

The latest buzz in IT is “rich clients”. Well, apart from SOA. And AJAX ;-).
It is interesting to see how some people consider this as the emergence of a new paradigm (even though client-server development was hot only a decade or so ago) and consider that this new paradigm would change significantly the IT landscape.
While this development will certainly change IT I don’t think you will see a lot of functionality getting developed on the rich client. What plays against implementing functionality on the rich clients apart from the UI layer is their wide range and the need to avoid duplication across potentially very different environments. Suppose that you have your standard B2C application. Suppose that you need to support both a customer that wants this application to run in a browser and another that wants to have it run inside a Flash component. You may very well have a customer wanting to run this application on a mobile device. In order to avoid code duplication across these very different environments you would have to minimize whatever code runs on the client. Chances are that you will leave only UI code on the client (this is the very minimum) and move everything else to the server. Chances are you will standardize the communication between the rich clients and the server containing the business logic. The large number of rich client types and the need to maximize the return on your investment (code in this example) will push most of the development on the server.
Opening your APIs to the outside world Amazon-style leads to a client agnostic environment, which in turn leads to the possibility of creating many clients across various platforms. Since the funtionality residing on the client has been shrunk down to UI it follows, roughly, that client development is becoming cheap and this renders the option of deploying your application across various rich client types more possible.

One the side issue of web development vs the rich client development:
I still hear developers scoffing at the HTML + Javascript combination while lauding Swing and its environment. Their primary irk at HTML is that it is pretty hard to code in JS all these dropdowns and these menus that interact one with another. They are missing 2 important points: One - there are quite a lot of JS libraries out there that do this for you (for free or for a small sum of money), and two - HTML freed the developer from working on the UI. I have not seen yet a Swing editor that lets a graphic designer work on a desktop app’s screen the way Dreamweaver lets it work on a page. HTML empowered the division of labor in a regular IT shop. If you think of it, a developer is not supposed to dabble in ergonomics, user interaction, usability and other concepts that pertain to UI development and that are second-nature to a graphic designer, it is the graphic designer that should be in control of them. What these developers actually needed but seemed unable to express was an event-driven development environment in which they could apply their expertise instead of struggling with clunky JS. Well, JSF just gave them that.
The benefits of HTML work along 2 axis: the division of labor and the usability of the tool used for manipulating the UI. This is one reason for which I think that rich clients are a bit over-rated, because most of the development environments for the new rich clients don’t come close to providing these benefits. AJAX (especially GWT) puts the developer back in UI development and provide it with a spartan interface. One tool standing out would be Flash. I’m not familiar with UI for mobile phones, I dabbled a bit in J2ME. I hope that these rich clients will not throw the developers back in UI development, but it sure looks like it. This is pathetic.
I didn’t sleep too well last night and it obviosly shows. Too bad…
Later edit: From this article it looks like the Eclipse RCP project aims to abstract the various rich clients platforms so that you could port the client easily across various platforms. If the Eclipse RCP manages to make the client portability easier it would obviate one of my points (about the need to move as much logic as possible to the server in order to accomodate a heterogenous client environment). I wish the Eclipse RCP a lot of success, especially in abstracting the mobile devices UI interfaces, those Midlets are begging to be let go.

I was reading this article. Interesting development… It looks like the mobile devices are starting to have the computational resources (CPU, memory, disk space) that make the creation of complex software for them a reality. However, there is one huge obstacle for the development of complex software for mobile devices: the small dimensions of the screen and (for a while) the lack of ergonomics needed to exploit this screen efficiently. Usability will take on a new meaning when you have to interact with an user thru a 2 inch by 2 inch window…
One more interesting thing about the increasing computational power of mobile devices. The re-appearance of the rich-client architecture coincided with the appearance of the smart phone. It would be interesting to see that once the smart phone will be able to host a “thin” client (i.e. a browser which requires a 6 Meg download ;-)) if the rich client architecture will go back to sleep and everything will be thin-client again.
Interesting to watch…