What is Architecture?		Date	2024-09-04
		Tags

Back in 2021, I in­ter­viewed for a job in Model Based sys­tems En­gi­neer­ing. Dur­ing the in­ter­view, one of the in­ter­view­ers hit me with the ques­tion:

What is sys­tem Ar­chi­tec­ture?

He clar­i­fied by ask­ing what dis­tin­guishes ar­chi­tec­ture from de­sign. A daunt­ing ques­tion, es­pe­cially as the in­ter­viewer was the au­thor of a well known primer on sys­tems ar­chi­tec­ture that I’d not long ago read. I got the job, but I was un­happy with my an­swer to the ques­tion. Three years and a lot of self re­search into cy­ber­net­ics lat­er, I think I’m ready to give an an­swer that I’m happy with. On the way to an­swer this ques­tion we’ll meet a mad ma­jor who could build snow­mo­biles and the Ar­chi­tect (of build­ings) whose work paved the way for MB­SE.

Lat­er, the man who in­ter­viewed me ex­plained that he saw ar­chi­tec­ture as a ten­dency dis­tinct from de­sign but still in­trin­si­cally linked—whereas de­sign moves to­wards solv­ing the prob­lem at hand, ar­chi­tec­ture ab­stracts, finds pat­terns (keep this word in mind!). At the time this was rev­e­la­to­ry. Ar­chi­tec­ture to me be­fore then was a stage be­fore de­sign but some­how less so. You must ex­cuse young Tom—I’d just got my CSEP badge and was locked into a very chrono­log­i­cally strict Vee model in think­ing. This thought wedged a crow­bar into the cracks in that men­tal mod­el. I am an en­gi­neer and a mod­el­er, so I could­n’t leave this at the level of fuzzy things like ‘ten­den­cies’. I needed a pre­cise model of the di­alec­tic of ar­chi­tec­ture and de­sign.

The Ar­chi­tect

In the 70s the ar­chi­tec­ture world was dom­i­nated by mod­ernism. Dri­ven by ad­vances in art, phi­los­o­phy, de­vel­op­ments in ma­te­ri­als and, of course, the ne­ces­sity of re­build­ing from two dis­as­trous world wars, cu­bic con­crete build­ings be­gan ap­pear­ing every­where. Though some in the ar­chi­tec­ture world were crit­i­cal of Bru­tal­ism and sim­i­lar styles. One such dis­si­dent was Christo­pher Alexan­der.

Alexan­der, in­flu­enced by nascent cy­ber­net­ics, be­gan look­ing for a time­less way to con­duct the cre­ation of build­ings and towns. His work dur­ing this pe­riod takes on a Promethean char­ac­ter— Alexan­der worked to col­lab­o­rate with and em­power the very peo­ple who would live, work and use the spaces he ar­chi­tect­ed. This cul­mi­nated in a trans­for­ma­tive project at the Uni­ver­sity of Ore­gon. A tril­ogy of books was pro­duced out of this pe­ri­od:

The Time­less way of Build­ing

A beau­ti­ful and po­etic book lay­ing out Alexan­der’s be­lief sys­tem be­hind his ar­chi­tec­ture prac­tice and an at­tempt at de­scrib­ing and cap­tur­ing the qual­ity with no name that ex­udes from cer­tain build­ings—a sense of life, be­long­ing & pur­pose.

A Pat­tern Lan­guage

A col­lab­o­ra­tive ef­fort guided by Alexan­der to de­velop a set of pat­terns that can be used by any­one to de­sign bet­ter spaces to ex­ist in.

The Ore­gon Ex­per­i­ment

An ac­count of how the the­ory set out in the first two books was put into prac­tice at the Uni­ver­sity of Ore­gon.

Alexan­der’s treat­ment of the qual­ity with no name and his later de­vel­op­ment of this into an idea of life that cer­tain ob­jects and build­ings pos­sess de­serves a proper treat­ment else­where. Here though, we’re more in­ter­ested in his pat­tern lan­guage.

A Pat­tern Lan­guage is a phe­nom­e­nal work. The book aims to arm nor­mal peo­ple and com­mu­ni­ties with a lan­guage with which they can use to de­sign their own spaces. As well as a large col­lec­tion of pat­terns, the book con­tains guide­lines for us­ing the pat­terns and dis­cov­er­ing your own.

Look­ing at Alexan­der’s pro­jects, he of­ten achieved his goals. His build­ings of­ten do feel time­less, re­flect­ing their en­vi­ron­ment and the hu­man ac­tiv­i­ties and re­la­tion­ships that they sup­port. How­ev­er, un­like many fa­mous ar­chi­tects of the pe­ri­od, his build­ings do not stand out as his. Per­haps this is the rea­son that his mark on the mod­ern ar­chi­tec­tural canon is small.

How­ev­er, the soft­ware en­gi­neer­ing world took Alexan­der’s ideas and ran with them, es­pe­cially in the C++/­Java/OOP com­mu­ni­ty. This cur­rent led to the (in)­fa­mous Gang of Four Soft­ware De­sign Pat­terns book which has be­come an in­te­gral part of the very cul­ture of Java pro­gram­mer­s.It was then in­her­ited by the UML and later SysML com­mu­ni­ties which has re­sulted in some great work in the dis­cov­ery of mod­el­ling pat­terns such as those doc­u­mented by the IN­COSE UK MBSE Work­ing Group.

This idea of find­ing pat­terns in de­sign and ab­stract­ing up is not new—Alexan­der of­ten al­luded to his work as dis­cov­ery rather than in­ven­tion. In the mid-70s, while Alexan­der was writ­ing his tril­o­gy, an Amer­i­can ex-pi­lot was be­gin­ning his work that would rev­o­lu­tion­ize war.

Snow­mo­biles

As Alexan­der was de­vel­op­ing ar­chi­tec­tural pat­tern lan­guages, an Of­fi­cer in the US Air Force was ru­mi­nat­ing on the af­ter­math of the Viet­nam and Ko­rean Wars. John Boyd had al­ready made a name for him­self with his de­vel­op­ment of En­er­gy-­Ma­noeu­vra­bil­ity the­ory in the 1960s which in­flu­enced the de­sign of the F-15. A mav­er­ick, he was known for steal­ing com­puter time to run sim­u­la­tions of his the­o­ry. His nick­name, 40 sec­ond Boyd, was earned from his ap­pli­ca­tion of E-M The­ory en­abling him to win sim­u­lated dog fights by bait­ing op­po­nents into a tail chase—­some­thing that was be­lieved to be a cer­tain kill sce­nar­i­o—be­fore us­ing his op­po­nen­t’s own en­ergy against them to shoot them down.

In 1976, Boyd pub­lished a pa­per en­ti­tled De­struc­tion and cre­ation. This pa­per was built on his wealth of ex­pe­ri­ence dur­ing Ko­rea and Viet­nam as well as his keen in­ter­est in con­tem­po­rary sci­ence. Boy­d’s fo­cus in the pa­per was to map processes of think­ing to im­prove warfight­ing. De­struc­tion is Boy­d’s process of tak­ing ex­ist­ing so­lu­tions and tear­ing them apart. Cre­ation is the op­po­site process of build­ing up those parts into new things. Boy­d’s later anal­ogy was that win­ning mil­i­taries can build snow­mo­biles. Mil­i­taries al­ready have tanks, boats, mo­tor­cy­cles &c. but, if faced with snow, they get stuck. Yet hid­den in their ex­ist­ing equip­ment are tank tracks, boat bod­ies, mo­tor­cy­cle en­gi­nes—all the parts for snow­mo­biles are there. If that force is em­pow­ered to tear apart their ve­hi­cles and build snow­mo­biles.

Boy­d’s De­struc­tion & Cre­ation map to the ideas of De­duc­tion & In­duc­tion or Ab­strac­tion & Reifi­ca­tion. It’s all about con­tin­u­ously build­ing a play­book of moves (Pat­tern­s!) which you can use to ap­ply to new sit­u­a­tions. Boyd con­tin­ued this think­ing for­ward into his later work on the OODA loop frame­work and his pat­terns of con­flict pre­sen­ta­tion. His con­tri­bu­tion to mod­ern Ma­noeu­vre war­fare can­not be un­der­stated and the use of tac­tics such as thun­der runs with dev­as­tat­ing ef­fect in Iraq and Ukraine, draw on Boy­d’s lega­cy.

Mod­el­ling Boyd & Alexan­der

I’m a model based sys­tems en­gi­neer—this gives me a drive to give the fuzzy pre­cise de­f­i­n­i­tion, es­pe­cially if done in a pic­to­r­ial man­ner. We’ll start, as in pre­vi­ous posts, with the Cy­ber­netic loop model of en­gi­neer­ing:

                     ┌───────────┐          ┌───┐
             ┌───────┤  LEARN­ING ├──────┬───┤DEV│
             │       └─────┬─────┘      │   └──┬┘
        ┌────┴────┐        │       ┌────┴────┐ │ 
        │         │        │       │         │ │ 
        │         │        │       │         │◄┘ 
    ┌──►│   ENV   │◄──────┐└──────►│   UND   │   
    │   │         │       │        │         │   
    │   │         │       │        │         │   
    │   └────┬────┘       │        └────┬────┘   
┌───┴─────┐  │      ┌─────┴────┐        │        
│EVO­LU­TION├──┴──────┤  AC­TION  ├────────┘        
└─────────┘         └──────────┘                 

FIG­URE 1: THE CY­BER­NETIC LOOP

To re­ca­pit­u­late this mod­el, there are two en­ti­ties:

The En­vi­ron­ment (Env)

Rep­re­sents the states of the en­vi­ron­ment that we’re try­ing to en­gi­neer.

Un­der­stand­ing (Und)

Our model of the en­vi­ron­ment that al­lows us to nav­i­gate the En­vi­ron­ment.

Then there are the process­es:

Evo­lu­tion

The process of the en­vi­ron­ment chang­ing.

Learn­ing

The process of up­dat­ing our un­der­stand­ing by ob­serv­ing the en­vi­ron­ment.

Ac­tion

The process of us­ing our un­der­stand­ing to change our en­vi­ron­ment.

De­vel­op­ment

The process of up­dat­ing our un­der­stand­ing based upon it­self.

It is the de­vel­op­ment loop that we’re go­ing to fo­cus on in this part of the es­say.

Boy­d’s De­struc­tion & Cre­ation im­plies that our de­vel­op­ment process is ac­tu­ally two process­es—one of de­duc­tion, de­struc­tion or ab­strac­tion and one of in­duc­tion, cre­ation or reifi­ca­tion. What are we do­ing with those ab­strac­tions? Well, an­other name for an ab­strac­tion is a Pat­tern.

De­struc­tion & cre­ation are the processes of cre­at­ing/up­dat­ing and us­ing a Pat­tern Li­brary.

Let’s see how that looks as a di­a­gram:

             ┌───────────┐            
     ┌───────┤ DE­DUC­TION ├──────┐     
     │       └─────┬─────┘      │     
┌────┴────┐        │       ┌────┴────┐
│         │        │       │         │
│         │        │       │         │
│   UND   │◄──────┐└──────►│   WIS   │
│         │       │        │   DOM   │
│         │       │        │         │
└────┬────┘       │        └────┬────┘
     │      ┌─────┴────┐        │     
     └──────┤ IN­DUC­TION├────────┘     
            └──────────┘               

FIG­URE 2: THE AR­CHI­TEC­TURE LOOP

I’ve given the name wis­dom to the Pat­tern li­brary as a more generic name. It is worth not­ing that De­duc­tion is not re­quired for an en­gi­neer­ing process to build un­der­stand­ing via In­duc­tion. I’d like to dig into this at a later date by us­ing this sim­ple model as a di­ag­nos­tic frame­work, es­pe­cially with how it links to the con­cept of tech­ni­cal debt, but for now we’ll fo­cus on ar­chi­tec­ture.

What is ar­chi­tec­ture vs de­sign?

Be­fore we an­swer the ques­tion orig­i­nally posed in this es­say, we should prob­a­bly make a point on the de­scrip­tive na­ture of the Eng­lish Lan­guage. The Ox­ford Eng­lish Dic­tio­nary takes a de­scrip­tivist ap­proach to Eng­lish—it records the Eng­lish lan­guage as it’s used, not how it should be used. De­spite what your Eng­lish teacher told you, there is no cor­rect way to use Eng­lish, just keep in mind that oth­ers need to faith­fully un­der­stand what you write.

Us­ing words against their dic­tio­nary de­f­i­n­i­tions or con­struct­ing non-­s­tan­dard gram­mat­i­cal sen­tences en­ables us to ex­press and em­pha­size thoughts in ways that Acad­e­mie Français French would for­bid. As an Eng­lish speak­er, know that you are em­pow­ered to boldly split in­fini­tives when­ever you please.

Given this, Ar­chi­tec­ture is a loaded word. Yes we have free­dom to use it wher­ever we want, but we’ve got to keep in mind that the us­age is loaded with pre-ex­ist­ing mean­ing. There­fore, us­ing the model con­structed in the last sec­tion, I’d like to pro­pose a de­f­i­n­i­tion of ar­chi­tec­ture and de­sign based on the de­duc­tion-in­duc­tion loop.

Ar­chi­tec­ture is the ten­dency to ex­er­cise the de­duc­tion process whereas de­sign is the ten­dency to ex­er­cise the in­duc­tion process.

To make this con­crete by re­fer­ring to job roles, a sys­tem ar­chi­tec­t’s job is to fa­cil­i­tate the iden­ti­fi­ca­tion, record­ing and us­age of de­sign pat­terns within a project whereas sys­tem de­sign­ers fo­cus on the ap­pli­ca­tion of pat­terns to the prob­lem at hand.

There­fore, a sys­tem ar­chi­tec­ture is a col­lec­tion of pat­terns and rules for their ap­pli­ca­tion that al­lows de­sign­ers to com­plete their role quickly on sub­se­quent prob­lems. This is em­bed­ded in the adage let’s not rein­vent the wheel. The wheel is a pat­tern—with­out a pat­tern lan­guage/wis­dom repos­i­tory we’re doomed to rein­vent it each time we en­counter the prob­lem of mov­ing heavy things.

I be­lieve that the de­f­i­n­i­tion pro­posed here some­what matches the com­mon us­age and that used in the ISO 420XX Se­ries of stan­dards. I’ve cer­tainly found the loop of Un­der­stand­ing-D­e­duc­tion-Wis­dom-In­duc­tion a use­ful di­ag­nos­tic tool in my work as a Prin­ci­pal Sys­tems En­gi­neer As al­ways, I’m in­ter­ested in your thoughts on the above—do you agree? Have I missed some­thing im­por­tant or lost the plot en­tire­ly! Drop me an email or com­ment be­low.

Be­fore we fin­ish here, I’d like to leave you with a cou­ple of ways that I in­cor­po­rate this think­ing into my day-­to-­day work.

Sys­tems Ar­chi­tec­ture Praxis

There are two main ways that I in­cor­po­rate this idea of ar­chi­tec­ture into my team’s prax­is. The first re­lies on our use of MB­SE, but the sec­ond is ap­plic­a­ble to any area of en­gi­neer­ing (or even life!). Be­fore I ex­plain those though, its worth not­ing that the doc­u­men­ta­tion of process­es, meth­ods & stan­dards is an im­por­tant part of the Ar­chi­tec­ture loop—after all a process or stan­dard is a pat­tern that’s in­dis­pens­able.

Oth­er­wise, the two ways that I in­cor­po­rate ar­chi­tec­ture into my team’s praxis are a do­main spe­cific lan­guage and a pat­tern li­brary.

Liv­ing Do­main Spe­cific Lan­guage

One way to think of a pat­tern lan­guage is as a form of in­for­ma­tion com­pres­sion for hu­man com­mu­ni­ca­tion—a pat­tern be­ing un­der­stood by two in­di­vid­u­als al­lows the short Ut­ter­ance of a few words to un­fold into a whole host of at­trib­utes & re­la­tion­ships in the lis­ten­ers’ head.

When fol­low­ing Model based sys­tems En­gi­neer­ing (MB­SE), stereo­types and/or Meta­classes can be used to en­code these pat­terns. In my cur­rent project we use a Do­main spe­cific lan­guage in­stead of SysML. This en­ables us to more pre­cisely de­fine the mean­ings of each meta­class, their stan­dard at­trib­utes and their al­lowed re­la­tion­ships.

Our de­duc­tion loop comes into play when we find our­selves un­able to eas­ily model a con­cept in the lan­guage, or, we find our­selves cre­at­ing the same pat­tern of at­trib­utes and re­la­tion­ships again and again. We can eas­ily cre­ate new meta­classes to cover these cases and adapt our mod­el­ling lan­guage on the fly.

If you find your­self us­ing SysML or UML, stereo­types, tags and pro­files work well for this pur­pose. In fact, I have a strongly held opin­ion of lit­tle con­se­quence that pro­files are nec­es­sary for SysML mod­el­ling to re­duce am­bi­gu­i­ty. The key is to en­sure that you are con­tin­u­ously eval­u­at­ing and up­dat­ing your pro­file and refac­tor­ing your model as it changes. Oth­er­wise, your pro­file will be­come overly con­strain­ing and make work harder than it needs to be.

A Pat­tern Wiki

Con­nected to our mod­el­ling but to also cover pat­terns in other ar­eas, we cre­ated a pat­tern wi­ki. A pat­tern wiki is a search­able repos­i­tory for pat­terns that your team dis­cov­ers. Any search­able tool is good for this. Com­mon cor­po­rate tools that are great for this are At­lass­ian con­flu­ence or Mi­crosoft Of­fice One Note—it just needs to be a search­able, link­able, shared repos­i­tory of knowl­edge.

Each pat­tern should have its own link­able sec­tion or page. Here’s the pat­tern that I use for pat­terns (A meta pat­tern!) as a start point. As Cun­ning­ham’s ¹ law states, the best way to elicit a cor­rect an­swer is to present a wrong an­swer. This meta­p­at­tern is pre­sented hop­ing that you’ll adapt it to your own needs.

A Tem­plate for Pat­terns

Sum­mary

A short de­scrip­tion of the pat­tern.

Prob­lem

A de­scrip­tion of the prob­lem that the pat­tern solves, so you know when to ap­ply it.

De­scrip­tion

A de­scrip­tion of the pat­tern and how to im­ple­ment it.

Re­lated

A set of links to other pat­terns men­tioned in the de­scrip­tion and other re­lated pat­terns.

We’ve also cat­e­go­rized our pat­terns based on whether they are for our work prod­ucts or whether they cover ways of work­ing. We also link out to col­lec­tions of pat­terns that work well in cer­tain cir­cum­stances. Ex­am­ples are TRIZ re­sources for prob­lem solv­ing or the Gram­mar of Sys­tems book for sys­tems Think­ing.

Based on this, I’m putting to­gether a project for a sys­tems en­gi­neer­ing pat­tern wiki fol­low­ing the pat­tern above. I will write more on it once its up and run­ning, but I hope that it will be­come a col­lab­o­ra­tive af­fair for a dis­ci­pline-wide Ar­chi­tec­ture loop. If you’d be in­ter­ested in this en­deav­our, drop me an email via my about page.

---

1. the in­ven­tor of Wikis↩︎

Site proudly generated by Hakyll | Theme based on Oskar Wickström's Monospace Web.