Tuesday, September 30, 2008

[Arch] A Comparative Analysis of State-of-the-Art Component Frameworks

Andreas Pieber and Jakob Spoerk wrote a thorough and very good thesis about software components and Java-based component frameworks. The authors introduce component-based software development, derive criteria to compare frameworks and eventually discuss OSGi, Spring, J2EE, SCA, and JBI on an individual basis and in connection with each other as some problems require the combination of several component frameworks.

Dowload the thesis here.

Thursday, September 18, 2008

[Arch] Pattern Based Development of Business Applications

In a recent series Jos Dirksen and Tijs Rademakers describe "pattern based development" on the basis of Open Source Middleware (ESBs). Specifically their first article describes how to implement and integrate applications using Mule and the second article gives a good introduction into the Java Business Integration standard (JBI) and the implementation ServiceMix plus a Message broker.

Wednesday, September 17, 2008

[Arch] Requirements?!

The Waterfall Requirement

I find this really interesting: In talking with many people who actually do make Software in the last years (not only talk about it *g*) I think I detected that many have a growing problem with the term "requirement". Martin Fowler sums it up greatly in his recent blog post. He makes a strong point in saying that the understanding that many people have about "requirements" is actually still very much driven by a waterfall-like understanding of the software engineering process.

As a matter of fact, requirements seem to be problematic on so many levels: on the level of customer/programmer relationship (do they understand each other), on the level of abstraction, how to manage them, how to test if the implementation follows the requirement that we hopefully have understood correctly, just to name a few. A story often heard is "we spent months with the customer building lists and lists, pages and pages of requirements or bought expensive requirement management software, and in the end the development of the product was very decoupled from these lists; but good to know we have them in the files.".

Now my question is this: the trail from requirements to software seems still very natural to us, and it is stunning for many developers and managers that it actually oftentimes does not work. I would like to add here: sometimes it works very well, but I come to that point later. Now, what could be the replacement of requirements? (In case we agree that they do not work as intended in their traditional sense.)

Observation comes in...

Well, there are modifications of requirements engineering in agile processes like the storytelling in XP. But Martin Fowler makes an interesting other observation: Many successful web-applications actually work out the requirements as they go by providing some base-services, a platform (e.g. for exchanging photos). The very important point in this phase is to build in functionality that allows the management to observe the behaviour of the customers: which functions are they using, what are they annoyed about (forum discussions, email feedback...). Then they add experimental new features and test the acceptance (Or you can as well go the next step: let the customers develop the applications as Yahoo! Pipes shows it).

It's Alive!

The interesting point is, that this procedure was very elaborately described in the book "It's Alive: The Coming Convergence of Information, Biology and Business" written by Christopher Meyer and Stan Davis. A very recommended read. The do not describe so much the process of software engineering but rather strategies of modern enterprises and derive the core principles:
  • Seed: bring in a new feature, idea; probably only to a subset of customers, probably in variations for different customers
  • Select: select the successful variations
  • Amplify: eventually amplify the successful ideas and bring more of that sort
Meyer and Davis brought exampled from "old economy" but actually in software engineering (particularly in web-applications) we have a very good opportunity to rather easily "seed" new features, observe the behaviour and select and then amplify the good ideas. The key point here is, as also Fowler mentions, to focus more on the "observation framework" (in a technical-, but also in a management-sense!) than on trying to get all requirements right from the beginning.

... and back to the Waterfall

Having said that, I want to come back to a point I mentioned earlier: in the "agility euphoria" some evangelists forget to mention, that there is a broad variety of different software products and engineering efforts. (and I am not speaking of safety critical systems here): In many cases actually a "waterfall inspired" process works pretty well. This can be the case in such projects where a technical guy (a developer at best) has already a lot of experience in a particular domain and is either re-writing a legacy application (a case I am observing right now) or is developing a new application that is actually following a series of similar applications and similar customers he had. And this case is quite a regular one in the industry, and we should not forget this scenario. In such cases the requirements of the new application can often be nailed down quite precisely.

Why is that? Well, actually the "Seed, Select and Amplify" process happened in this technical expert. He or she worked with old applications in that domain, often with a broad range of customers that have experiences with several systems of a sort. So he has developed quite a good understanding of (1) the domain (2) the customer (3) the competitors. In such cases the problem often lies more to get the implementation phase right and not to spoil the project on the last steps e.g., with not so experienced developers (either in the technical sense, or in the domain, or in the worst case in both). Hence agile principles as suggested by Scrum for example can be very helpful for the implementation phase to keep control of the process even though the requirements are quite stable from the beginning.

Wednesday, September 03, 2008

[Arch] Google AppEngine & Python

Cloud computing is the fashion right now and Google is positioning it's AppEngine against services like Amazon EC2. However similar on the first glance, the two approaches are rather different in detail: Amazon's service is more a virtual server hosting (where you have all freedoms, however are responsible about administration too) plus a set of webservices (like the storage services S3 and SimpleDB or the Queue Service SQS).

AppEngine offers a concrete application development environment in Python plus a simple database that has to be used. So you are limited to Python code and Python frameworks like Django and you cannot install an arbitrary database, on the other hand you do not have to deal with many administration issues and Google deals with the scaling.

Guide van Rossum, the father of Python (who is now employed at Google) gives a very interesting one-hour presentation on YouTube on how to write and configure a Python/Django web-application within the Google AppEngine environment.