Wednesday, 27 February 2013

An architecture of predators and monuments

Mario Carpo’s, in his essay “Alphabet and Algorithm”, tells the story how Alberti invented the modern architect. He managed to invent plans which allowed the architect to stay away from the actual work, concentrate on the plan, yet keep all the fame. All of this in the best intention to foster collaboration and nurture the crafts. Many software (and particularly enterprise) architects see themselves in this tradition - unfortunately only the planning part. But Carpo goes on and explains how modern algorithms sorta turned the Renaissance around, bringing back participatory authorship into real-world architecture. While identity and idiosyncrasy become less important, the remix, versatility and sustainability in terms of longevity come back to architecture.

The rupture of individualism in architecture can be linked to the megastructure movements of the late 60ies. As Annette Urban points out in “Mythos Monument”, the very concepts which wanted to turn cities into moveable, flexible, flowing structures became the megastructures par excellance. By neglecting centralization, the city planners effectively turned themselves and their structures into the center. When Haussmann tore apart the arrondissements of Paris to allow industrialization and military vantage, rather than introducing the “service bus”, he froze the versatility. In realization that any structure is totalitarian or at least aristocracy, and thus can never provide actual needs for citizens, Architects like Superstudio began ironically playing with monuments and city limits. From them we learn that planning always ends in itself.


Courtesy: Archivio Superstudio, Firenze via Megastructure Reloaded

However, this reminds me of a story from Emergence. When W. Daniel Hillis's self-emerging AI algorithms showed signs of perfect structures, but less-than-optimal local maxima, he introduced predators. By doing so, he encouraged the algorithms to develop in the right direction, becoming stronger, and eventually near-optimal. The lesson for architects is: Become a predator, one that collaborates just like Alberti did.

Sunday, 20 January 2013

Resilience, responsive design and vertical integration

Jason Grigsby had an excellent post recently on responsive design for mobile apps. In short he says that one always need to design in a responsive way, because the lines between screen sizes, input models and form factors are so blurry that, in fact, it's impossible to know how the user expects your app to work.

I like to put this in context with mixed model mobile apps (Frameworks like Calatrava) and the new trend infrastructure trend of "vertical integration", i.e. expand cell architectures into the hardware domain.

BlackBerry 10 is a new type of platform which is streamlined (managing user experience) and open at the same time. It allows polyglot programming, hence not only mixed model apps but a cross-tier, cross-device integration of components. You could have a database model in Java, covering almost all platforms. A UI which is responsivly designed for each platform, and business logic which is in a DSL. The latter is most imporant because, with vertical integration, it could be aware of the consistency models offered by the backend. Independent of data storage, the business layer could offer several consistency models. If one or the other model is favoured, only this kind of hardware could be scaled. Just like with Facebook's photo storage, all parameters can be negotiated by both server and client. Which will eventually lead to emergent and resilient systems which will be able to run for longer than most platforms.

These cross-device, cross-tier software systems work like swars. The benevolent dictator nudges the swarm, bringing in new systems, monitoring both user experience and infrastructure efficiency. Now the question would be - how to control? Agile software development aims toward one product, this is clearly not  enough. So how would be build, distribute and manage these kind of systems? How would we manage the API's to connect them, the directories to find the services and the resilience to learn from our mistakes?

Saturday, 22 December 2012

Spaceship Earth


There is the (correct or not) story Steve Jobs choosing the personalities to appear in the „Think Different“ campaign. One of the “crazy ones” to appear is Richard Buckminster Fuller, a person Steve Jobs was particularly fond of. Both, with Buckminster Fuller’s Operating Manual For Spaceship Earth being published at the same time, admired the “Whole Earth Catalog”, a book Jobs’ took his famous quote “Stay hungy, stay foolish” from. Their admiration came from the trust in self-regulating systems, more specifically the belief that a better society could be built on the foundations of technology. This view was shared not only by them but similarly in economics and urbanism, which had at the same time discovered cybernetics and were busy weaving everything into Gaia theory.


via Andrew Reynolds


Emergence touches some aspects of self-organization and maybe even Gaia theory. The difference is, though, that emergence does not assume a stable state but rather “Black Swans” – Disruptions, it embraces change.

You can illustrate the difference if you look at the iOS and Android (or Windows) ecosystems. iOS is like “intelligent design”, it creates a sophisticated, stable state by aristocracy. An invisible hand shapes the ecosystem. But Adam Curtis uses the picture of Buckminster Fuller and Hippie communes to show that obedience to this stability in favour of egalitarianism is not always best. Actually, making everything the same is industrializing it and thus, maximizing differences. Even real world architecture accepts that it cannot be eternal without authority. Android is the other way round. It’s chaotic, nudged by an evil force, Google. While this force is always tempted to control the system, it realized that innovation can only happen from within. While the system is less robust, more fragile, it is also quicker to adapt. 7-inch tablets, wrist watches and Lego Mindstorms can only happen with Android.

IT Systems Architecture is quite similar. Of course it’s stupid to start from scratch every time you build a new system. But it’s as limiting to have an architecture department dictate every change. Focault showed us that individuals which are exposed to a system will always try to use their power, turning the system into a machine. Hence, industrializing it and stopping innovation. Allowing to stay on the edge by managing properties at the same time is what systems architecture is about. Looking at nature and embracing emergence in order to achieve resilience is a virtue. But narrowing down natural organizations to a randomly chosen system, calling it perfect just to be able to cut everything else down is a tragic. Regardless whether you call it Mechanisazion, Singularity, Ephemeralization or Machines of Loving Grace.


As Jez Humble writes in his review of Nassim Taleb’s Antifragile: “The problem with robust organizations is that they resist change. They aren’t quickly killed by changes to their environment, but they don’t adapt to them either – they die slowly”. Or, as Adam Curtis would say “they are stopping people who want to change the world. They’re actually even stopping people from having the framework to think that they could change the world”.

Sunday, 9 December 2012

RfC: Decoupled Client Architectures

Preparing a talk about decoupled client architectures (coming from Multi-Screen/Responsive Design et.al.) I am trying to work out the different trends.

The currently most trending client architectures could be:
1) SOFEA (as in Flex, GWT, AngularJS, Backbone.js for instance)
2) ROCA (as in Play for instance)
3) CQRS (might be orthogonal, not sure, maybe Calatrava and Cocktails could be an example)

If I try to categorize them, ROCA stands out because it relies on "Unobtrusive JavaScript". So obviously it could be considered "Static" rather than "Dynamic" (i.e. the representation is fixed, might only be augmented for usability reasons). SOFEA and CQRS differ in how they handle parallel events. SOFEA stems from a more traditional GUI heritage, abstracting client/server away from the client, while CQRS makes the client very aware of parallel events by forcing it to react to events. That's why I would consider SOFEA close to ROCA, but have an independent representation which can only work locally without the server because they quite heavily rely on something coming back. I am not yet convinced the distinction is rock-solid as one could also argue ROCA is asynchronous because it allows for more versatility by enforcing hypertext.

Hence, a possible matrix could be:



Now, the lower right corner is native Android (not web-based so it does not really count) because Activites (Screens) themselves are usually rather static but rely on messaging and have almost no control about the task flow.

Glad about comments.

Sunday, 25 November 2012

Nexus and distributed computing


“Nexus is the name of the humanoid robots in Blade Runner. Taking this name discloses Google’s strategy: To turn Android into an indistinguishable part of our lives. Nexus are stronger and weaker at the same time, they are us on speed. A prosthesis or Surrogate (to bring another movie reference). Our technology systems will become a prosthesis, and as such not only ubiquitous and seamless but also versatile to changes. Ubiquitous and seamless we are working on, in the terms of affective computing and responsive design, but versatility is still a big issue. In a world changing faster and faster, the Achilles heel of contemporary technology is change.”

That’s the paragraph I forgot to mention in my W-Jax Keynote. This is going to be a post on what I meant with that example of the prosthesis. It would have continued on how Android is facilitating change, with message driven API’s and data update functionality; on how Google wants to introduce Web Intents and cloud providers start early concepts of application and data versioning. Let’s leave this aside for a while. Let’s talk about mobile apps and how we could start to embrace chance in them.

There should be no extremely complicated mobile apps from user perspective. Not due to platform or performance restrictions but context restrictions. What you want to use on mobile devices should be the happy case. Mobile Applications should allow deep-diving into information because "the value of interfaces today is the information it wants to present", even simple rules can get you anywhere. In Desktop interfaces with an exact mouse pointer, every page can contain multiple actions. With mobile and tablets, this actions have to be morphed into flows (which can be event- and gesture-triggered). That's why I think metaphors of urbanism are better suited to describe mobile application architecture then concepts derived from, in the end, military structures.

This flow is the link to the left out paragraph above. I am not a believer in Singularity, and I do not think we will end up in a Blade Runner world. In it's current state it's much more likely that the technology will be so resistant to change that we will have to learn to innovate completely without out. Luckily, some systems, like Android, start to introduce concepts of flows, messaging - generally, versatility. This can only be achieved by decoupling data representations from functions and human interfaces, for instance by leveraging CQRS, Mixed-Model-Mobile-Apps or ROCA. All of those three towers (I would draw them 90° turned to what we call tiers today because they would be accessible from everywhere) would be decoupled, freely linkable and versioned. The technology itself would become a truly representative tool. Just like the Nexus, but focused on what computers can do best: data and functions.

I imagine something like Erlang actors, OSGi or Server-Side-JavaScript (think Cocktails or Calatrava) to exchange business logic. A concept where data and logic can be exchanged seamlessly and across versions; a concept that could up to this point not make it into any statically typed programming platform. However there is a chance that Java (after JRebel, Jigsaw and Nashorn) could natively support versioned interfaces one day, maybe together with richer declarations for layers, tiers or towers. That fine day might be the brink of a new era of pervasive computing.