Jeff Eaton, Architecture is for Everyone - session notes from DrupalCon Paris 2009

19 Jan 2010 | by Administrator

So here's my transcript of the excellent session on Architecture entitled ‘Architecture for Everyone’ by Jeff Eaton from Lullabot (http://www.lullabot.com). Presented at DrupalCon Paris 2009 (Day 3).

Brightlemon have been lucky enough to work with Lullabot on a couple of projects (which the Bots consulted on) and it has been an awesome* experience. It was great to finally meet Nate and Jeff and also a couple of other nice Bots...

(*use of this specific word proves I spent too much time at DrupalCon Paris...)

Hopefully it’s accurate but I’ll post a link to the slides when they get put online and will mail Jeff to see if he’s cool with this interpretation:

Architecture is for Everyone — J. Eaton (Lullabot)

Ok so Jeff started off by talking about how the term ‘Webmaster’ is now all but defunct; and how ‘Web Developer’ is soon to follow suit. We are all Architects. And as an Architect there are a number of key points to consider on any project before diving right in:

Goals before features

Before focusing on the features of your project focus on the high level goals e.g. the goals could be: increase hits to front page, more page impressions or something similar. But not a feature list first (so not ‘we must have a rotating banner in the top right of the home page’, or we must implement widget X etc.)

See the forest

i.e. look at the (bigger picture) or as we say in England – see the ‘wood for the trees’. Ask what is the high level, helicopter view?
This could be with reference to timeframes, people or performance. Also ask: Who are we communicating with? What systems do we need to integrate with? Do the developers understand how to implement it?

Know the tools

This refers to the detail level. Besides seeing the big picture an Architect must have intimate knowledge of details required: e.g. understand the Views API, Contrib – what is ready for use?

So with this will come important choices/tradeoffs. If you only come up with one solution then you are using the wrong approach. There are always multiple paths. There are always multiple solutions.

e.g. If you needed to speed up your web application there are multiple solutions – add more servers, increase hardware capability, reduce SQL queries, write a views plugin... and so on...

Also, assess the appropriateness of simple tools vs. complex ones - what works for the economist.com does not necessarily work for a florist or a small brochure site. And vice versa.

Co-ordinate, communicate

Someone needs to lead the direction and ensure all contributors are singing from the same hymn sheet. (N.B. someone who is amazingly good at this is Kieran Lal from Acquia – if you are fortunate to see him do this first hand you will know what I mean).

Identify patterns

This is a technique commonly used in Architecture, Design and of course Software Engineering. Jeff gave some references to some acclaimed books at this point (I shall link them through to Amazon in due course):

A pattern language by Christopher Alexander.

Patterns can also be akin to a style guide for design. Any good web designer will provide a style guide or set of rules to follow. See the work of:

Mark Boulton and Larry Garfield in particular for insight relating to concepts around patterns.

Look Around

Don’t just look at Drupal - be aware of other solutions e.g. maybe the client only needs a simple solution and should use Wordpress; or how does django handle caching? What can we learn? (there is always someone smarter than you out there...)

Case Study

(At this point Jeff ran through a case study using the above points talking about: Goals; Cost; Control; Context, Process; Testing; Migration; Road maps; Strategy; Techniques; Unknowns/Risk assessment; Constraints and also asking: Where are we now?

But unfortunately my notes are illegible for this section (must have been paying too much attention to the presentation) so you’ll just have to see Jeff present live for yourself for this part!)

Think big, Build small

Complexity requires more brainpower – sometimes unnecessarily. (Einstein has a similar quote about this principle: ‘Everything should be made as simple as possible, but not simpler.’).

Finally some more references: