Mother Russia

Russia 2005

what an amazing country -- how many surprises -- and how many stereotypes that i carried around and had to adjust. Most of all impressed me the extremely friendly people; such a difference to the rude folk you meet at the russian embassies. then the rich cultural heritage and the strong european influence (and cross-weaving). there was so much cross-fertilization: e.g. napoleon - aleksander II, voltaire, josephine (napoleon's wife) - kathrine the great. peter the great studying in holland and italy, etc ....amazing all this history! all this certainly awakened my taste buds and i'd love to go and explore more of this beautiful country in the future. e.g. the provinces further east of Moscow, etc ....

ST PETERSBURG

Dostojewski Haus (crime & punishment)

Eremitage: Da vinci?? Madonnas …?

Peter & Paul Fortress: the fortress was the first building in St P. constructed and designed 1703 by Peter the Great. The original timber construction was over the next few years replaced by a stone building. Under the protection of the fortress the town rapidly developed. Never used as a fortress, but served over two centuries as the country’s main political prison: Tsarevitch Alexey, son of Peter I who was against the policies of his father was incarcerated here. And princess Tarakanova who claimed to ascend the throne died a horrible death (see paintings) when the prison was flooded by the Neva.

Cathedral of Peter & Paul: The golden angel on top of the spire is said to watch over St. Petersburg. Served as a royal burial vault: Peter the Great, Alexander II. The last Russian Tsar Nicolas II and Alexandra Fedorovna + their children and servants (the Romanovs). ???

Princess Tarakanova:

Claimed to be Elizabeth’s daughter

Seduced by count Orlov, Kathrine the Great’s lover who secuded her to come with him from Paris?? To St. P and on the ship imprisoned her.

Peter the Great – 2m tall, traveled incognito to many European countries, e.g., studied shipbuilding in Holland; big modernizer of Russia

Cathedral – architect was chopped off his hands

Tsarskoye Selo (literary - "tsar's village") – Pushkin:

Preferred palace of Catherine the Great

Lyceum where Pushkin studied

Great damage during WWII – the Nazis dismantled the Amber Room which mysteriously disappeared after the war. Sunk with the Wilhelm Gustloff? The reconstruction opened in 2003.

Saviour of the Blood Cathedral :

Built on the site where Alexander II was assassinated 1 March 1881. the original part of canal fencing and cobblestones is still visible in the middle of the church. Built 1883-1903.

Archangels in orthodox churches: Gabriel with 8 wings symmetrically attached to a bodyless, cherub-like pink face.

Gipsy taxis: riding at 120km/h through Moscow! Lots of traffic accidents at night. Overturned cars, head-on collisions with Mercedes and all airbags deployed.

Smolny Cathedral and monastery: Built by Elizabeth, dauger of Peter the Great.

Like many other churches used as a storehouse during communist times.

Alexander Nevsky Monastery:

- Tikhvin Cemetery: Dostoevsky, Mussorgsky, Rimski-Korsakov

Kaviar & Vodka & champagne :

Swan Lake Ballet:

Bridge Opening Neva:

St Isaac Cathedral: like St Peter’s in ROme

Plattenbauten: in the 50s/60s super: running warm water, heating, bath rooms

Kunstkammer:

Lomonossow Museum; first observatory of Russia; Riesenglobus: transport from Germany; first in Peterhof

Curiosity collection of peter the great: aborted fetuses, grim!

Nevsky Prospect

Peterhof:

Conceived by peter the great in 1714 he took an active role in the construction and design of the palace (incl. intricate details of the architecture and of the fountains).

100s of remaining

Russian Hydrofoil

Sea canal – like mirror pond in Versailles but oppeninig out onto the sea

Monplaisir

Practical jokes: hidden water jets in trees and in the ground.

100s of fountains

Samson fountain with the spewing lion is a monument to the Russian victory over the Swedes in 1709. Its symbols can be easily interpreted as the lion was depicted on the coats of arm of Sweden and Peter the Great was often compared with Biblical Samson. This victory was significant as it opened naval access to the Baltic sea (“window to Europe”) and was the beginning of the royal Russian navy.

Lots of reconstruction work necessary after WWII.

MOSCOW

Metro:

Gorki Park

Gorki Leninskije :

- Lenin Statue und originalappartments from Kremlin ; brought here by Yeltsin

Jaroslavl:

Madame Butterfly (Puccini) in Bolshoi Theatre.

Torquato tasso: tankred & Herminia

Kremlin:

Jonah and the Whale

Stalin-gothic skyscrapers (The Seven Sisters): Kotelnecheskaya appartments is one of seven Stalinist-Gothic towers that were built just after WW2. The architects used a "wedding-cake style" construction, to give each building a sense of "upward surge" toward a central tower. Built by POWs, it is said that when prisoners expired while working on site, their bodies were immured!

The towers owe their design to a monumental building that was never built, the Palace of Soviets. Starting in the early 1930s, planning competitions were held for the proposed 1,410-foot-high structure, which was intended to stand on the banks of the Moscow River where Stalin had destroyed the Cathedral of Christ the Savior in 1931. But despite 25 years of plans and revisions, the gigantic palace never materialized. On the same site today, Moscow Mayor Yuri Luzhkov rebuilt the original cathedral. ( In between swimming pool!)

Testing Outside the Container

At JavaOne I've heard a talk by Jim D'Ambrosio on the problems of EJB testing. Frequently, unit testing is done after deployment onto an application server which creates a set of nuisances:

• configuration and setup is time-consuming
• debugging is complicated (remote debugging)
  
• Too much time waiting for the server to start
• Bugs in other areas slow you down

Jim concludes that it is better to unit test EJBs outside of the application server. For this purpose, mock objects can simulate the EJB container's runtime environment. EJBs are unit tested as plain Java objects. This should make developer's lives easier and more productive (see the article Streamlining Your EJB Tests With MockEJB).

These arguments are equally true for ESB service development! Deploying service types into an ESB container before unit testing them makes the development process slow and complicates debugging. Mock objects to the rescue! One problem remains though: there are no off-the-shelf mock object libraries for ESB containers. ESBs are still less wide-spread and there's no standardised API yet for ESB service implementations.

In my current project we are working with the Sonic ESB container. Given the lack of mock libraries for this container, we just built one ourselves. We are now in a position to simulate the Sonic ESB Service Container and therefore greatly improved our development lifecycles and code quality.

Because there’s no time required to start up the container (and no resources consumed), this streamlines testing -- a fact that makes test-driven development feasible. Since services are tested in isolation, there’s no dependency on other system components. Sometimes we test several services within one unit test when they act as counterparts of each other (e.g. FileDropServices/FilePollServices, FTPPut/FTPGet).

However, this approach is no panacea for developer woes: Integration testing must still be done on the container.

IBM entering ESB market

Two articles on IBM's latest ESB strategy announcements:

IBM trots out muscle-bound SOA
http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci1124772,00.html

ESB Guru Dave Chappell Welcomes IBM's Big SOA-Related Push
http://webservices.sys-con.com/read/129795.htm

In this article Dave calls IBM's current product offering a "Sargasso Sea" of components.

Enterprise Service Buses Hit the Road

Just noticed via Ramesh that InfoWeek has a comparison of different ESB products in its latest issue.

Bern under water

Have been through Bern on the bike this afternoon: The damage on the Matte quartier is huge. From the safety of the high level bridge I watched in awe with other "disaster tourists". Draft wood blocked off one of the normal water passage ways, so the flood took another route: straight along the Matte main road! All 1.100 inhabitants of the Matte area have been evacuated from their houses -- some by force.

The water is still 1-2 metres high and there's a very strong current (20km/h?). I saw one house where water came in through the front and came out gushing through the rear. It looked like this house had been built bang in the middle of a torrential river! Lots of cars totally submerged with only the antenna sticking out of the water – some of them badly damaged and with the roof torn off (wonder how this happened?).

Bern Matte Film 1
Bern Matte Film 2

Java Business Integration (JBI)

For ipt I've given a talk on the topic of JBI recently. The rationale behind JBI is the current lack of standardization on the concept of ESB. Services developed for Sonic cannot be migrated to Iona or BEA. Different vendor’s ESB buses cannot seamlessly be integrated. This seriously hampers the adoption rate of ESBs in their current incarnation. The following statements are maybe a bit cynical, but let’s say I’m playing devil’s advocate:

ESBs are proprietary:
While most ESBs are standards based in their low-level implementation (XML, XSLT, BPEL, etc), they are proprietary at the level where custom services and integration components (such as BPEL engine, XSLT engine, BRE) live. Custom services developed on the basis of one ESB product cannot be migrated to another product without modification. Sonic's service API is incompatible with Iona's or BEA's, for example. Integration components, such as process engine, XSLT engine, BRE are tied to the vendor; no choice is possible. This may be perceived as risking vendor lock-in: who wants to build their enterprise infrastructure on a technology from a single vendor?

Different ESBs are incompatible on the transport level:

Most current ESB implementations are built on JMS. JMS guarantees reliable and guaranteed delivery of messages between components, an important basis for critical business processes. Since the JMS specification does not define a wire protocol, different ESBs are incompatible on the transport level.

On the other hand, it is unrealistic to assume that just a single ESB product will be available or can be deployed enterprise-wide. In most situations there will be variations in the installed software base, possibly as a result of mergers. What happens if external business partners want to join the service network but have invested on a different, incompatible bus? In such situations, interoperability can be established only via message bridges that link together the different ESBs. This can hardly provide the illusion of a seamless ESB service network.

Is JBI the solution?
JBI is out to change all that. JBI doesn't require a J2EE stack. This means that third-party vendors of integration components can plug their wares into the JBI framework even without having a full J2EE stack. Customers can therefore build "their" ESB server using a best-of-breed approach, e.g., take the XSLT engine, a BPEL engine, BRE engine of their choice. These might all come from different vendors who focus on their core strengths. Since components are portable between different JBI implementations, this approach avoids vendor lock-in. Different transport implementations can also be plugged in. This makes incompatible wire protocols much less of an issue.

JBI Overview

Service Engines (SE) from different vendors (e.g., an XSLT engine, BPEL engine, container for custom ESB services) plug into the normalized message router (NMR). The NMR mediates all communication between SEs. If the destination SE happens to be on a foreign host, remote communication is initiated via an appropriate protocol binding component (BC). The BC might provide JMS transport, WS-RM transport, even CORBA or EDIFACT. The meta-container maintains a routing table for this purpose. Proxying of JBI services to remote consumers is transparent at the SE-level.

Disadvantages (or why didn’t IBM and BEA join the initiative?)

Do we still need it or are WS-frameworks sufficient? They don’t see it as a sufficient step forward and believe that the area covered by JBI can equally well or better be addressed with upcoming WS-* Standards.

It is still early days to predict whether JBI will catch on or end up as yet another container architecture. The inceptors’ vision is to see JBI play an important role in enterprise integration as J2EE did/does today for application development. They also envisage the emergence of an ecosystem of pluggable SEs from different (niche-) vendors.

A few articles on JBI:

• Mark's post on JBI.
• Ron Ten-Hove Interview 1 (SearchWS)
• Ron Ten-Hove Interview 2 (Artima)
• Mark Hapner Interview on JBI (SearchWS)
• New JBI Standard could change Java (SearchWS)
• Toward Integration (IEEE Internet Computing)

Biking the Himalayas: Lhasa - Kathmandu

In October 2002 I did a Bike Trip Lhasa - Kathmandu. This has been a dream for a long time and it was the experience of a lifetime --- well worth all the physical exhaustion! Recently many people have been asking questions on my experiences and recommendations for repeating such an adventure. I've collected a few of the answers in the hope that they're useful to others.

- How hard was the trip (how good does one's physical condition need to be)?
It's hard but absolutely feasible if you are trained and physically fit. Factors to take into account are the altitude, wind, dust in the air (be prepared to wear a dust mask for severeal sections), sun impact, lack of humidity. All these can be compensated for, but you feel what you've been missing on the 4000-m descent back to Nepal!

- Did group members experience severe signs of altitude sickness?
No, just minor

-Over a longer period?
The response is very individual. For some people the symptoms come back with every 500-m climb, for others it's just one/two days upon arrival in Lhasa. I've heard that sometimes people need to fly back again, but it's very rare. I've complemented my diet with iron and vitamin tablets and found this useful.

- What month did you do the trip and how were weather conditions?
October - fine weather - cold at nights (-15 degree Celsius on everest base camp), comfortable temperatures during the day. The support team were fantastic - on the coldest night they even brought us hot-water-bottles into the tent and every morning we were awoken with freshly brewed tea delivered straight to the tent.

- Would you recommend Makalu trekking for this trip?
Absolutely! They were fantastic and I'm still in touch with some of their staff. They are very competent and efficient.

- If you have any knowledge of other organisations offering this tour, how would you compare Makalu to them?
DAV Summit Club is offering a similar trip but I don't know the details.

- Would you travel with Makalu again for similar trips?
yes

- How would you rate the accommodation and the food?
Superb - given the circumstances.

- How would you rate the logistical support?
Excellent - we had one truck and one jeep with us over the whole distance. Food and all supplies were brought in from Nepal in advance to our arrival in lhasa.

- Did you have many problems with your bike? Could the guides help you to fix your problems? What spare parts should we bring?
Bike problems were minor: a few flat tyres and loose bottom bracket. I carried standard replacement parts (inner tubes, tyres, brake and gear cables, plastic click-on pedals for SPD, lube, oil, spokes) and tools (pump, all allen keys for my bike, spoke key, chain tool, etc.) with me. In Tibet it's impossible to get spares! If something breaks en route the only chance is to find a good/creative mechanic/welder in one of the few towns.

- Did you find your bike guide useful or is it also possible to do it without bike guide (only land cruiser support)?
By chance we joined a group led by a bikealpin guide. This was useful, especially since we had fantastic mueslis and sausage flown in from Germany as well as the more bulky tools (e.g., sprocket remover, crank puller) and extra spare parts available.

The SOA Triangle

Recently I’ve worked on a SOA Readiness Assessment for a client from a data-centric perspective. Some deficiencies I observed there are probably representative of other enterprises with a heterogeneous IT system landscape that has grown organically and was integrated as need arose in an ad-hoc and piece-meal fashion:

Limited Flexibility

• mainly batch base file integration between a fragmented system landscape
• difficult to implement new services and answer to customer needs in an adequate time

Data Duplication and Inconsistencies

• Data assets are stored in a wide array of disparate systems and sources ranging from mainframes to relational databases;
• Data is replicated between individual systems that each use disparate databases and directories. Data replication takes place with time delay. Consequently there’s a window of time where conflicting changes to replicated database records can happen. This makes it a challenge to maintain an aequate level of data quality. Manual intervention is frequently necessary.
• Every disparate system has its own master dataset. There‘s no clear concept of what information is relevant where at what point in time. Data is fragmented, no unified view of enterprise data exists; in some instances this becomes obvious to the customers (e.g., multiple call centers, letters going to two different addresses).
  

Unreliable Data Exchange

• Risk of losing in-flow information during a crash (ad-hoc and often batch-file-transfer based processes).

To address these issues I came up with a graphical representation that I want to call the "SOA triangle" (not to be confused with the Bermuda triangle -- although you can get lost in both):

---

Data Access Services (DAS) : A critical foundation and abstraction layer for the access of enterprise information. They isolate both applications/service and underlying datastores/directories from change by acting as a layer of abstraction.

Data Ownership

• Role- and area-based access concepts can be implemented based on a multidimensional CRUD matrix
• Fine grained access control based e.g., on process-level authentication tokens
• Tighter management/operational controls

Encapsulation

• Provide a data model that is specific to the operational unit or a process
• Shield applications from the complexities, location, access protocols and consistency requirements of underlying enterprise data source
• Useful to percolate updates simultaneouosly to multiple backend datastores (see performance/caching later). This improves the consistency/integrity/quality of enterprise data.
• Basis for a step-wise enterprise architecture transformation: Applications/services and underlying datastores are not directly dependent on each other. Therefore, applications are isolated from structural changes/merges/etc of underlying datastores. At the same time, applications can be modified to use the new DAS-interfaces without modifying the databases.
  

Avoid impedance mismatch

• The DAS can offer an multiple process- or OU-specific interfaces to the same backend datastore with high level, business-event oriented semantics.
• This is more realistic than a unified company-wide data model on which everybody must agree (or face a winner-loser situation with some OUs being forced to use a model that doens‘t fulfil their expectations)

---

Messaging/ESB : Serves as the SOA Communication Backbone/Infrastructure

Abstract Communication Layer with Virtualised Service Endpoints

–

• Avoids "SOA Spaghetti" : Services are connected declaratively. Crosscutting concerns, such as delivery guarantees, security, messaging patterns should not be in the responsibility of services.
  
• Reliable Information Exchange between Disparate Systems: Once-and-only-once semantics guarantee that messages are not lost during machine or network failures.
• Asynchronous Communication: Failure of a component in a business process delays the process rather than failing it.
• Improved overall system reliability. This is important, because in a complex IT landscape like Cablecom‘s the chances of individual components failing increases exponentially. Store-and-forward means a process can continue once a failed component comes back online.
• Different message exchange patterns (point-to-point, publish-subscribe) possible

Straight-Through Processing (STP)

–

• Improved agility through harnessing the real-time data that are flowing around the business
• Ability to quickly acquire, analyze, and act on both opportunities and issues within the SOA implementation.

---

Caching : A caching layer can decrease the frequency of interaction with backend data stores.

Performance is of concern in a SOA

• DAS require frequent interaction with backend datastores
• In addition, services ideally are statless; i.e., services keep their state in persistent storage rather than in-memory (see next slide)

•

This issue can be addressed by software caching:

• Products like Times10 offer in-memory replicated reliable caches with persistence guarantees comparable to database.
• Physical database access is therefore reduced (since most requests can be served from the cache)
• greatly improving data access performance.

Extra Special Bitter

ESB

- Naturally leads to a document-oriented processing model

- document-oriented vs. RPC: Not separate methods are called, but instead a document is passed around asynchronously between various steps that make up a business process

- Integration on the level of business events (STP) rather than nightly batch file transfers

- Are data services more RPC-oriented, whereas higher-level business services are document-oriented?

- Virtualisation of service endpoints; therefore a more flexible adaptation of business processes. In addition, the connection complexity is reduced to attaching a service to the bus and then defining the message flow declaratively using high-level graphical tools (see screenshot).The ESB mediates all communication between services – services never communicate directly (although such optimisations can be used internally, as e.g., in SonicESB).

- ESB is a distributed system in contrast to the hub-and-spoke architecture of typical EAI-products. This offers advantages in terms of reliability and scalability.

- Because of ist distributed nature, ESB deployment can be Step-by-step.

- Disadvantages: unrealistic that a single ESB product can be rolled out across the enterprise. It’s likely that there will be multiple ESB products installed (e.g., mergers, fragmented IT strategies, organic development)

Message-Oriented Middleware (MOM)

- guaranteed delivery semantics (e.g., exactly-once, at-most-once, best-effort)

- different messaging domains: point-to-point, publish-subscribe

Possible process steps within the ESB

- intelligent message routing based on message contents (content-based routing)

- transformation (XSLT) between different technical formats

- enrichment of data with additional information

- archival of entry data

- access control verification

- logging

- throughput monitoring

- delegation to existing applications or web services

Paragliding "Schnupperkurs"

A message especially for my mate Jim: Eventually I've done it -- a whole day of paragliding, on my own. Last Saturday I went together with Stefan to Flugschule Diemtigtal where we completed a one-day "schnupperkurs". I came directly from Spicherweid cottage where I stayed the night before with Thomas and his family.

I’d done two tandem flights in the past, but this is the first time that I was on a glider just by myself. The experience was both scary and exciting. Flying 5-10 metres above ground in the flying school was not something I had expected from a beginner’s day! I managed to look stupid with one botched start (landing on my tummy!) and two crash landings.

Our teacher Andy (who’s a test pilot for Thun-based paraglider manufacturer Advance) was excellent and never got out of the calm (despite me constantly ignoring his radio instructions J) --- thanks a lot for a great day!

Altogether it was great fun and hopefully I can repeat it sometime again. On the other hand, I've decided against taking up a full course, because it's too time-consuming for me right now (waiting for the right weather/wind conditions, etc ...), a bit expensive and I'm not convinced about safety. Let's see, maybe I come to another conclusion next year :-)

New MTB

After riding hardtail bikes for the best part of the last 15 years and fervently disapproving of fullies I've eventually changed my mind. I now believe that the technology is good enough to avoid any bobbing going uphill and the only disadvantage of full suspension is the extra weight and less reliability.
I've been convinced that rear suspension is a great advantage downhill and can even be beneficial on tough uphill sections with very rough surface --- you can pedal more evenly and therefore safe energy. And the rear shock is so much fun that you actually start looking for obstacles! I've gone for the Specialized Epic Marathon 2004 with Fox Terralogic Fork and Brain IQ rear suspension.

Aare Marzili Fun

It's very hot in Switzerland at the moment -- so for lunchtime I went running along the Aare river but then for the way back couldn't be bothered and just jumped in with my running gear on. Water temperature has reached a record 22"C (live recordings here). Even on a weekday like this hundreds of people are on the river floating downstream. Sometimes the speed is around 15 km/h. great fun!!!

Next plan is to go Waveboarding on the river. I've seen some people do this with home-made boards and elastic ropes attached to the trees. Tension is built up on the rope by drifting downstream (stalling the board against the flow); then they get quite some speed as the rope contracts again. Excellent! Now i just need to find somebody who can teach me how to build one of these ....

WorldWind: Aletsch Glacier

An amazing satellite image of Aletsch Glacier from WorldWind: Aletsch is the largest glacier in the Alps. It emerges from a giant snow bowl called Konkordiaplatz where three ice streams meet. This bowl is surrounded by the Bernese Oberland's highest mountains: Eiger, Jungfrau, Mönch.

Lake Thun and Lake Brienz are visible in the background. The Aare river emerges from Lake Thun and from which it makes its way to Bern. The city itself is just clipped off the top of the image.

JUnit Testing von Sonic ESB Services

Da Services ja nur via Message-Austausch (im Idealfall) kommunizieren faende ich es ideal, wenn man die korrekte Nachrichtenverarbeitung eines Services durch In/Out/Fault/Error Endpoints simulieren koennte. D.h. der Test wuerde Messages auf dem In-Endpoint produzieren und korrekte Resultate auf den anderen Endpoints ueberpruefen.

Ich koennte mir folgende Vorgehensweisen vorstellen:

1. JUnit standalone Testing der einzelnen Services: Befuellen der init(…) und service(…) Methoden via Mock Objects. Exit/Fault-Endpoints koennen ueber weitere Mock Objects simuliert werden. Vom Service produzierte Messages koennen damit wieder dem Test zur Verfuegung gestellt werden.



2. ESB-basiertes Test Framework fuer Einzelservices :
• Automatisches Deployment des Einzelservice in einen ESB Container incl SonicFS Eintraege, Service Configuration;
• Automatische Verbindung und Konfiguration von Service Endpoints, notwendigen Queues und Verbindung der Endpoints mit dem Service;
• Eine solche ESB-Konfiguration fuer einen Service koennte z.B. in XML (oder einem XAR File – ausser Queues) beschrieben werden und automatisch via esbadmin-Skripting bereitgestellt werden.

Sonic at CERN

SonicMQ has been used by CERN from the early days. They started developing the architecture on SonicMQ 2000.1. The deployment platfrom is OC4J and currently they have 2 projects running. The 2 projects are called TIM (Technical Infrastructure Monitoring) and LASER.

TIM is responsible for the monitoring and reporting of alerts triggered by malfunctioning smoke detectors. LASER is resposible for the monitoring of the particle accelerator's state and event display. Note that shutdown during malfunction is managed entirely at the hardware level.

The Kaif is in Switzerland

A while ago my friend Tusitha told me the Sri Lankan story about the elephant and the monkey:

The monkey jokes with an elephant, asking for a ride up the elephant's trunk. Annoyed, the elephant sucks the monkey up through his trunk. Somehow it gets trickled and loses control and so the monkey passes all the way through the elephant's internals until it reappears at the elephant's backside. Both, elephant and monkey are a little surprised but then decide that it was fun and that they should give it another spin. After repeating the procedure a couple of times, they have the glorious idea of connecting the elephant's trunk to his backside. an infinite loop of pleasure or as Tusitha says they call it in Russia: "Kaif"! The ultimate feeling of well-being ;-) [Not so good Kaif is called "Bale" if I remember correctly]

Well, seems I discovered Kaif swimming in the Aare river. There is an incredibly tight bend just a few k below Bern. The loop is about 1.5k long, but at its extreme points connected by a 150m pedestrian tunnel. You can jump in the river, swim all the way round and then race through the freezing tunnel to do it all over again!

Excellent weekend

I spent an excellent weekend packed so full with events that it seemed like a mini holiday:

• Friday evening straight after work we went to Montreux for a swim in Lake Geneva and afterwards attended the famous Jazz Festival. What an experience even staying on the fringe and not attending the "official" concerts. We saw a Swedish a capella group that had 20 singers and about that many voices. Lovely food too!
  
• Saturday BBQ and swimming in the Aare in Bern. We went to the amazing Aare loop in Felsenau.
• Sunday mountain biking in Valais. Thomas and I cycled from Fiesch to Kühboden and on to Märjelensee with views across the Aletsch glacier (26km long, 81sqkm surface), then back downhill via a single trail above the Fiesch glacier. From there, Thomas in his usual kamikaze manner took an almost vertical downhill. Having sweated enough with fear already I descended more leisurely over Riederalp and Bettmeralp towards Brig and also took in the panoramic views from the top of Eggishorn.
  

Loss of Agility?

In many software projects the business goals are poorly understood, in flux and hard to communicate. That’s where the agile/iterative approach comes in. Because you can quickly adapt to moving targets it’s much easier to deal with unstable requirements. Now consider a company that wants to put into place a new software system. If they were to start from scratch, they’d probably start playing around with a prototype, throw this at pilot-users and iteratively adapt according to feedback and a more mature requirements. What however, if they decide to build on top of a commercial platform and customise in-house? Then they need to decide for a commercial vendor that *fulfils their requirements* and that’s where the crux lies. How can they evaluate and decide for one or the other vendor when the requirements are everything but clear and stable? Furthermore, a decision is irreversible (more or less, after the licensing fee has been shelled out).

Effectively, you are forced to switch back to the good old “requirements-design-build-test-deploy-manage” approach for this step of the process. All agility is lost! As far as I can see, the only solution to somehow mitigate the problem lies in playing around with open source software before making the vendor-decision. This way you can establish some need-to-have requirements on the basis of which to pick the commercial vendor.

What do you think about this problem? Am I overlooking something, stretching the agile methodology too far? Can you see a solution consistent with the premises of agile development?

Also see Item 6. on the "Overly Long Guide to Being A Software Architect"