Form Follows Fashion

“Form follows function” is a building architecture principle. The tenet, which is a shortened and punchier version of the full quote – “form ever follows function”, came from an American architect, Louis Sullivan. It’s actually worth a couple of quotes from the source article, because of its eloquence and poetry:

Whether it be the sweeping eagle in his flight, or the open apple-blossom, the toiling work-horse, the blithe swan, the branching oak, the winding stream at its base, the drifting clouds, over all the coursing nun, form ever follows function, and this is the law. Where function does not change, form does not change. The granite rocks, the ever brooding hills, remain for ages; the lightning lives, comes into shape, and dies, in a twinkling.[i]

The principle was widely quoted and adopted in the design of modernist and industrial 20^th century buildings. Some might argue that the worst excesses of 20^th century architecture were the result of focusing too much on the function or purpose for which it was built!

So what has this got to do with enterprise architecture? Well the principle of form follows function was a hotly debated topic in software engineering circles – especially in the 1970s and 1980s. Two camps were evident – there were those who thought that software engineering should start from a data perspective – so that data structures preceded and determined the structure of an application; then there were those who believed that process and function should come first. The idea was that the form or structure of an application was based around the functionality required by the business.

To some extent we still find this dichotomy in enterprise architecture; for example, Phase C of the TOGAF ADM is divided into the Data Architecture and the Application Architecture. Which one should come first? If the EA initiative needs to build capability around business intelligence or around sharing or integrating information, then data might be the best starting point. If a request for architecture work is more about improving business functional capabilities or processes, then application architecture might be the best start point.

In EA best practice, both data and application need to be considered in parallel. It is not actually a question of form follows function, or even function follows form... which brings us to a quote from another building architect, Frank Lloyd Wright, who has been quoted as saying:

Form follows function - that has been misunderstood. Form and function should be one, joined in a spiritual union.[ii]

Now a serious scholar might argue that we don’t know whether Wright actually said this or not! But when it comes to EA it is a useful reminder that every component is united with every other component within the architecture. It is one of the foundational principles of systems thinking, which underlines EA practice, that the functioning of a system as a whole depends on the complex set of interactions between each and every one of its component parts.

In other words, as architects we need to understand:

• The architectural form of a system. This includes cataloguing its components, understanding their structure and configuration, how components are related to one another, how the architecture is layered and segmented, and how we deconstruct components and separate concerns.
• The function of a system and its architecture. This includes understanding the dynamic behaviour of a system, seeing the links between requirements, strategies, outcomes and consequences, and understanding the constraints, limitations and opportunities inherent in the architecture. 

You can’t have one without the other. Form influences function, and function influences form. They are symbiotic.

Ah! I hear you say – but the title of this blog is Form follows Fashion! I’m not sure that any building architect has claimed this as a quote. But maybe they should have done, because in the 21^st century, whether we are talking building or enterprise, fashion has a huge influence on both the form and function of an architecture.

Let me explain. Fashion is all about style. It is a way of doing something. We talk about popular fashions or the latest fashions. The fashion of today will become passé tomorrow.

Now when we look at enterprise architecture there are clearly ways of “doing” enterprise architecture that are currently fashionable. Service orientation is popular. TOGAF is popular. Structured design and functional decomposition are less fashionable.

If an enterprise adopts a service oriented approach, then the service becomes one of the prime components that form the architecture, and the service becomes the prime mechanism to deliver functionality. The switch from one fashion or style to another can cause a lot of disruption, and frequently takes several years or even decades to achieve. Think of the switch from standalone, silo applications and processes based around mainframe technologies to networked services and apps based on internet platforms. Or consider the often clumsy transition from keyboard based inputs to touch screen interaction.

These are frequently fashion dictated changes. For example, for many tasks, a keyboard interface is better than touch screen, and yet there is an expectation is that a screen will be touch-responsive. There is much proof to show that deconstructed component-based architectures are more resilient, adaptive, and sustainable than ones with less formal design principles, but there is less evidence to show that service-orientation is any better as a modular approach than object-oriented or event-driven architectures. From an architectural perspective, it is important that there are sound principles and rationale behind decisions about form and function. Precisely how these are then implemented becomes more of a fashion statement, reflecting decisions made at the solution level of understanding – rather than at the architectural level.

Contemporary enterprise architecture needs to consider form, function and fashion. Form and function are mutually interdependent, so it is impossible to say that function follows form or vice versa. But fashion does make a difference. We have certain architectural styles that are currently popular, but are certainly not the only way to architect. While they are in fashion they will have a determining influence on the form and function of our enterprise architectures. When the fashion changes, we may well have to reconsider both the form and function to adapt to a change of style.

We need to separate form from fashion. Instead of form following fashion, we need architectural form (and function) that can be delivered in a variety of fashions. This is one of the reasons that TOGAF separates the Architecture Continuum from the Solutions Continuum – form and function are primarily architectural decisions, whereas fashion should be more a solutions level choice.