Design for serendipitous evolveability.

In their paper about the discipline of application architecture*, Mike Blechar and Daniel Shollar offer four major design principles to observe:

  1. Leverage: focus on robustness, interoperability, and shareability to ensure designs are optimised for leverage.
  2. Evolveability: think about how the application will change as its own software and the artefacts upon which it depends change and grow.
  3. Simplicity: seek highly-maintainable and efficiently-adaptable patterns when creating or changing applications.
  4. Serendipity: Wikipedia offers the lovely definition of serendipity as meaning “‘happy accident’ or ‘pleasant surprise’; specifically, the accident of finding something good or useful without looking for it” , and for application architecture this means designing both for the exactness of the situation at hand and also for generalisable reuse in other situations.

i’ve been thinking about these four design imperatives quite a lot lately, both in terms of application architecture, service design, schema design, and enterprise architecture at large.  This afternoon a seemingly-innocent and trivial-seeming end-user request also made me think of these design imperatives, because the request:

  • Please sort the list of items using sequence# from the system of record.

…received the assessment that:

  • “This is bigger than it looks.  The application does not store sequence#, and sequence# is not provided to it through any form of integration with the system of record.

…so, to support the sort-order enhancement request, the following changes are required:

  1. change the integration from system of record to send sequence#
  2. change the database structures so they can hold sequence#
  3. change the application integration logic to accept and store sequence#
  4. perform a one-off data migration to pre-populate sequence#

By neglecting to include sequence# in the initial design, at least the principles of design for leverage and design for serendipity have been broken.  It would not have been unreasonable to imagine from a generalisable-service perspective that sequence# was a good candidate for use in delivering some unknown future service feature.  The outcome of all this has seen capability delivered that is not change-friendly.





* Blechar, M. & Sholler, D. (2010) Defining the Discipline of Application Architecture, Gartner Research, ID:G00205960


One thought on “Design for serendipitous evolveability.

  1. Good post.

    I’d change Blechar and Shollar’s first two terms to 1: Re-use, 2: Change, (and rap therir knuckles for obfuscation – but that’s just me).

    On their third point I wonder if simplicity is the correct objective. Does it matter if how complex an application is ‘internally’ if it meets the first two design criteria and plays nicely in the wider architecture? And can’t a simple application be bound to other applications and data flow is such a complex way as to undermine the other objectives? But casting around I am at a loss for a clear and unambiguous term for this characteristic.

    I also suspect that objective 4 is redundant. If the first three are met wouldn’t 4 follow – especially if 1 and 2 pertain strongly?

    And an inevitable effect of taking these objectives seriously – which I think we should – is more time and effort allocated to the requirements design phases of the solution.

    Lately I have been thinking that the best place for ‘agile’ methodology is prior to the implementation of a project.

    But where is the appetite for the cost-shift this implies?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s