Sunday, 18 August 2013

Optimism vs. Pessimism

Recently I've read a nice maxim by Bill Clinton "Every person has an optimist and a pessimist side. The trick is to be optimist on bad days and pessimist on good days".

In the technology world, we still live up to the optimism of the 50ies, it's considered anti-innovative, even anti-social, when concerns are brought up - unless you directly describe how you solved them. This begins with interviewers looking for  10x, Ninja and Rockstar programmers, assuming agile processes will work more productive amongst superstars, born with success and hyper-productive. Or people argue resilience is a bunch of fault-tolerant servers and session state in a distributed database that will make sure transactional safety for us (we don't care how), or delegating it to a messaging system that will encapsulate flow from us (we don't care how), or a hardware load balancer that will normalize access (we don't care how). But it's not relying on superpowers that creates successul networked systems. Evolution has told us: it's communication, the best communicating group of the fittest will win.

We're only at the very beginning of understanding complexity and peer-to-peer-networks. The military has a long history in understanding complex networked systems involving humans and therefore error. Looking at the current discussion around drones the problem does not seem to be ultimately solved. For our systems to achieve a kind of "Byzantine fault tolerance" against infrastructure errors, we need a new approach to concurrency and consistency. Once we include business-critical processes in distributed systems, we need to make sure information is valid - in the eye of the beholder. Usually, transaction safety is considered ubiquitous, but we need systems more like MVCC, that gives one user the impression of consistency, yet allowing concurrent modifications in limited scope. True Resilience is about having the user chose between optimistic and pessimistic locking, and providing a relevant consistency context for the user, hyper-consistency if you want. In military, logistics is key. In the same way, having access to trusted, coherent, resources, is key in our distributed systems.

Posted by at No comments:

Sunday, 21 July 2013

Seek out feedback and learn from your mistakes as you go along

At the end of the tunnel, there is always light; It just might be a train.  
The Streets, Going through hell

The headline is a quote from the Palchinsky Principles, via Gojko Adzic's worthwhile talk "Make impacts, not software" (via @jbandi).

In May I visited the Lötschberg-Basistunnel, a recently completed 35km tunnel through the Swiss Alps. I learned two amazing things from the guide:
  1. Most complex tunnel drills stay in the tunnel. It would be too expensive to get out of the tunnel (the costly heads are unmounted sometimes) – because they start plastering the inner shells right after it.
  2. In the beginning it’s not really clear where the tunnel drill will take its way. As the head moves forward, rock formations can require changes in the trajectory.

Gojko Adzic merges Design Thinking, SMART objectives, architecture assumptions documentation and business case calculation into “Impact Mapping”, singing the old hymn about analysis-paralysis and Water-Scrum-Fall. He claims that pre-planned software development “it's not a road, it's a tunnel”; rather than sticking to a linear backlog, project should have “something like a GPS”, a vision. Funnily that's how, in fact, tunnels are built. Roads on the other hand often are grids. It's not the question of a tunnel or a road - the distance makes the difference. A straight planned product with tons of features in a neat grid will not enhance usability. Creating a vision – an impact that everyone understands – will.  Being able to define a long-term goal allows for adjustment. Rather than just to “divide and conquer”, this is the art of the product owner.

As someone who moved from startups and design/advertising into traditional consulting I am amused by the now-mature generation of Web 2.0 firms which start to look into the very same traditional processes: product planning, sticking to delivery, definition of requirements which are backed by business cases, business process management and simple interfaces. It's good to see that the mechanic and the organic approaches to software development finally merge, creating a mature, objective and tolerant way of building technology that helps the people using it. 
Posted by at No comments:

Something between Micro Services and ROA

A post from July 2013 on Microservices I never finished but now, in 2014, like to reference. It's unchanged, so take it with care and read Fowler's and Richardson's stuff first.

I've read two interesting articles recently one on Divide and Conquer and another one on Simplicity*. Both advocate a new pattern of maximum decoupled services called Micro Service Architecture (by Fred George).

...

This reminds me of NoFlo and Mathematical Visualizations and Abstractions. The strength of Micro Services is not the Continuous Deployment or Decoupling but enforcing to think about organization and the connections of functionalities, because one cannot simply tangle them.

...

However, Micro Services are still services, which means verbs. If they would be nouns, there would be no need to manage tangling because the complexity would already be in the hypermedia.

Maybe something in between is the future of Software Engineering, where Data is managed in REST but logic as Micro Services can be moved between the tiers, as horizontal view of vertical data.

....

*) The solution to this within Yammer is DropWizard, an approach going in the direction of Cell Architecture, with Autodeploy features added and a noun-based approach. A little bit like the Java answer to the 12 Factor App and Docker but, in my opinion, too much of a data expose layer with some PaaS candy.
Posted by at No comments:

Sunday, 26 May 2013

Design Thinking for Ecosystems

Bret Victor’s talk about “Drawing Dynamic Visualizations” (via Stilkov) inspired me to go a little further on design thinking. Not in particular because of his amazing visualizations but rather his quote of Alan Kay referencing Jaques Hadamard, who did a survey amongst great mathematicians what kind of tools they use.  In this study Hadamard found that only a few of them “claimed to use mathematical symbology at all […] they did it mostly in imagery or figurative terms”.

Alan Kay in Bret Victor's Talk

I am sometimes surprised to see hardcode-science-educated colleagues struggle when I apply techniques and methods learnt in design and architecture school. Sometimes even simple brainstorming seems to disqualify me as proper nerd peer. This also applies to systems or enterprise architecture when I draw systems in the size according to the importance of their interfaces on the whiteboard, print out code to show its asymmetries or refuse to include technical layering in early system drafts (in the end it’s all indirection).

Design Thinking is everything but new – d.school has shaping it for a while. But via the organizational implications mobile is putting upon enterprises, it’s entering the world of technology architecture rapidly. Agencies like R/GA, Frog or recently-Accenture-acquired Fjord take giant steps towards the convergence of innovative service and product design with technology. What they call “functional integration” is often coined an ecosystem in the technology world. It gets more interesting though if we ask why this integration has not reached all the platforms we know of. Apple is usually considered one of the best ecosystems – yet, its technical platforms are surprisingly heterogeneous and task-based, you could argue skeuomorphic in the way they act. Android and Windows 8 are much more “flow-based”, trying to support an externally planned long-running activity through multiple channels. In a way, they are more technical – but then again, in the long-term, they might very well bring the benefits of good design: a product that is unobtrusive, long-lasting, essential and pure.

Our architectures must become like good design, like an unobtrusive ecosystem that shaped the components living in it. As Triarchy writes:
“Deleuze and Guattari talking about the structural and genetic aspects of organisations and the need to consider the shape of the formed organisation on the structural plane as well as the evolution of the formed organisation on the genetic plane. This echoes the debate about whether to prioritise structures or processes in management. For D and G, it's necessary to do both.”

Or as Bjarne Stroustrip, again quoted by Bret Victor, said: “A lot of thinking about software development is focused on the group, the team, the company”. Evolution, i.e. predators, are important in emergent, especially in agile, iterative systems. However, systems don’t end in themselves; they need to fulfill a purpose. In a world where all kinds of systems are possible, design thinking can find this purpose.

UPDATE: A good write up on why design thinking is a discipline, not a process: http://www.fastcodesign.com/1663558/design-thinking-is-a-failed-experiment-so-whats-next
Posted by at No comments:

Thursday, 25 April 2013

Ätzende Architekturmetaphern

On JAX 2013 I gave a talk "Ätzende Architekturmetaphern". The main thesis was that software architecture has arrived at a point very similar to one in the history of urbanism, where two main streams merged. The one coming from the tradition of society, the "organic" one. The other coming from the machine age and functionalism, the "mechanical one". Via a short detour over emergence, a new kind of theory materialized - what Vidler called "the third typology". It lead to a new approach of "bottom-up" research, cumulating in the analysis of informal architectures, i.e. slums. This new way of critical theory could very well apply to the current state of our profession, where we are looking for a way to include resilience, rhizomatic structures, information flows, evolutionary design and agility into our architecture.



As Prezi does not feature longer transcripts, this is the reading list (received on April 25th 2013):





Posted by at No comments:
Subscribe to: Posts (Atom)