In their paper about the discipline of application architecture*, Mike Blechar and Daniel Shollar offer four major design principles to observe:
- Leverage: focus on robustness, interoperability, and shareability to ensure designs are optimised for leverage.
- Evolveability: think about how the application will change as its own software and the artefacts upon which it depends change and grow.
- Simplicity: seek highly-maintainable and efficiently-adaptable patterns when creating or changing applications.
- 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:
- change the integration from system of record to send sequence#
- change the database structures so they can hold sequence#
- change the application integration logic to accept and store sequence#
- 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