This is the outline of a “Lighting talk of two parts” delivered at Agile on the Beach 2014 (#agileotb)
UPDATE: Video is now online This talk starts at 23:30 (but please watch them all!)
Everyone knows that architecture is just “box drawing” so today I’ll just talk about boxes (forget contexts, components, containers, modules, classes, packages etc). This lightning talk is intended to help explore some of the terms used and (controversially!) suggest 5 rules…
This is a term I heard used in maybe 4 out of 5 of the talks I attended today.
Abstraction has two (relatively subtle) different meanings:
RULE 1: LEVELS When communicating about Architecture, converse at a single level of abstraction (elevation), and ergo, an appropriate level of granularity.
RULE 2: EXAMPLES Abstract by example, not speculation.
• (Not one for the Snapchat generation) but we used to say in Java, don’t expose your privates.
RULE 3:: BOUNDARY Understand your component boundaries (and therefore contracts) at every “level of elevation”.
All of the above (in box terms) defines how to build your boxes but misses an important question….
The easiest way to look at this is Rule 2. Q. What sort of examples? A. Business examples.
So when determining what’s in the box think, verticles, verticles, verticles.
A typical architecture diagram shows technological concepts in horizontal layers (we’re really good at this… think front-end and back-end teams or gui, service and dao packages…) and (sometimes) business concepts in vertical “slices”.
RULE 4: ALIGNMENT ??but to what??
I said I’d deliver 5 rules to let’s “right size” RULE 4…
RULE 4 (a): ALIGN your Architecture (portfolio/components) with your Delivery (people)
AND MOST IMPORTANTLY!!!
RULE 4 (b): ALIGN both with your Domain (the reasons why your business changes)
So let’s summarise!