Ian,

Hat tip appreciated. Thanks!

I'd like to modify a few of your remarks, though, nonetheless.

"... once delivered, applications do not change much, if at all. Just like we don't go moving buildings around just because they are now inconveniently placed."

I think you are letting the analogy lead you astray here. The fact is applications MUST and do evolve. Meanwhile data, or more specifically data structures, change hardly at all. Enterprise Java Beans (EJBs) were an attempt to incarnate this realization. SOA (Service Oriented Architecture) was another.

Both of those seem to be giving way to REST style data presentation, where SQL is tossed out in favor of a return to hierarchical data. Couple that with the Semantic Web, that binds REST style data to semantic schema, and the entire idea of an application disappears into the mists of time.

In such an environment “Programming In The Large” becomes all important. “Mash Ups” are one tool in vogue for doing that. BPEL is another. Generated from a BPMN diagram, it allows access to data by different users to be structured into business processes with a very high degree of agility. To continue with the Urban Planning example, BPM would be analogous to the expediting orders at UPS or FedEx. The drivers and package handlers have no idea of the contents, but they pick them up, pass them from one to another and drop them off, on every kind of “driveway” there may be, even purposely distributed drop boxes.

So I beg to differ when you say, “There are also many others applications, and each of them can be analogised to a building”. It would be much more accurately representative to say, “There are also many data structures, and each of them can be analogised to a building”.

To go further, you say, “It is tempting then to extend the application scenario and simply view an organisation as a very large application.”, but not one of your three arguments against that is very convincing. They all say, in effect, “Accept institutional rigidity”. Management may surrender to that, but the market will not. Excessively rigid institutions go under. M & A activities subject applications to tidal forces that break them up into fragments.

So to summarize, and to risk the impudence of paraphrasing you, “There is only one application and it is the Internet.” The only clearly discrete units in that vision having any kind of durability are the Data Element and the Use Case. We need to grow out of the bad habit of binding them into “applications”.

Hasan

I assume you are looking down from 20,000ft with your view, and thus miss out on what is at ground level and below?

Below the streets is where the "services" are all the basic utilities (gas, water, electricity, sewers) but also communications that transport information and occasionaly (in large city areas) people via the metro etc.

It is these that the city planner is most woried about not what goes on at ground level and above. And invariably architects don't conciously think about them in their designs they just assume they will be available in the required capacity as required.

And it is at this almost unseen interface that most things go wrong. After all your local metro is not going to be happy if the foundation auger just drills into one of it's tunnels likewise the neighbours are not going to be to impressed when the lights go out or sewerage backs up through their toilets or onto the streets or god forbid a gas main ruptures and causes an explosion that causes death and destruction.

It is this non apreciation of the "not immediatly visable" where most "information architecture" goes badly wrong. Architects are more artist than engineer (they try not to sully their lilly white hands with what they see as blue collar work) where as city planners realy do have to be full on engineers with many disciplines under their belt and they tend to call themselves "Civil Engineers" with good justification.

I don't know about you or the rest of your readers but I suspect they are going to say "Ahh yes" we had a major issue with System / Enterprise Architects making assumptions about the "not immediatly visable" and that's what we need ICT "Civil Engineers" to keep the Bl**dy Archtects feet on the ground.

However your "Street view" does have an interesting analogy with Google and security.

Most are aware that Google have little cars driving up and down every road taking photos of people on the walkways (there's one of me with my middle finger up at one, on the web if you want to find it ;) and peoples homes with their cars in the drive way etc.

Now this wonderful source of information is just what burglars and car thieves need. This has become such an issue that some legislators are trying to push through legislation to add 5 or more years to a persons sentence if it can be shown they used "street viewing" information from the Web...

The problem with the "street view" of Information Architecture is thos little camera cars or "service discovery" systems. All applications have weaknesses and just dumping them on some Enterprise Highway connected to the rest of the road system with no let or hinderance is just asking for trouble.

The thing is as architecture most applications dont have doors or windows or even walls just random holes through which anyone may pass if they know where one is. Primarily because when the applications where designed the System Architects behaved more like "decorators" and decided to concentrate on the "office decor" not the "protection from the external environment" they "just assumed" it was there provided by some other Architect...

In short most applications do not have sufficient security built in to be "opened up" to "everyday traffic" let alone naredowells with an eye for oportunity. And trying to is only going to lead to a world full of hurt.

What the Enterprise Architects need to do is differentiate between the infrestructure, building fabric and office contents 9which they appear congenitaly incapable of doing).

They then need to build new buildings correctly connected to the infrastructure above and below ground and move the office contents in then demolish the old buildings.

The problem is they are currently doomed to fail because there are no ICT "Civil Engineers" to help the Enterprise Architect put the building on solid foundations and correctly engage with the infrastructure. It is why so many big projects fail you cann't build castles on clouds, you need solid foundations on mountains to put them in the clouds, but for them to work you have to secure your "services" otherwise your castle will not be habitable etc.

Importantly though time has moved on and Castles are not even "so last century" the design of secure modern buildings is very much the same as prisons and it is that our Enterprise Architects should be looking at for inspiration.