Linkedin

 These days, I mostly post my tech musings on Linkedin. 

https://www.linkedin.com/in/seanmcgrath/

Balisage Conference 2021 - Call for participation

See https://www.balisage.net/Call4Participation.html

Fully Virtual Legislative and Parliamentary sessions coming in 2020. Forty years ahead of schedule

It goes without saying that we live in interesting times at the moment. Never could I have imagined that the world would change utterly, so rapidly...

In times like this thoughts turn immediately to those most seriously affected. Fingers crossed the measures being taken at the moment will allow us to defeat this virus soon.

When we return to "normal" it is clearly going to be a new "normal". All over the world organizations of all sorts are finding ways to function in fully virtualized environments. The word "Zoom" - already in the dictionary as a verb coming into this  - has acquired a new meaning, in record time. There has never been a more intense focus on finding ways to get things done digitally. It is no longer hyperbole to say that our futures and our lives depend on it.

Legislatures and Parliaments are not immune to this new digital impetus. All around the world Legislatures and Parliaments are exploring ways to work fully digitally. Decades ahead of when I had envisaged that they would.

These institutions face some unique challenges in making this transition. It is not as simple as using conference calls for voice votes and switching on a few video conferencing cameras. Decades and indeed centuries of precedents, statutory provisions and constitutional/charter provisions need to be complied with so that continuity of the rule of law is maintained and to ensure legal authority is preserved.

Rules of Legislative Procedure such as Mason's provide a wealth of good guidance that functions regardless of whether or not a Session is being conducted "in person" or virtually. 77 of the 99 legislative chambers in the US use Mason's as the bedrock of their chamber rules. Mason's allows for the suspension of rules and, on the face if it, this appears to provide a lot of scope for US legislative chambers/houses to adapt quickly to working in a fully virtualized environment.

However, Mason's is also clear that its rules, or the rules in a House or Senate resolution or in the joint rules of a legislature, are all ultimately limited by whatever the constitution may require.

Simply put, the Constitution rules. And this is where the difficulty may lie in some cases. Most constitutions are old documents - into the hundreds of years old. Some specifically state, for example, that legislative sessions are conducted "in person".

This has higher precedence that anything in the joint rules, the chamber specific rules or in Masons/Jeffersons/Roberts etc. So, perhaps a change to the constitution is required in states where there is a constitutional requirement for "in person" meetings?

This is of course possible in all states, but I know of no state where the constitution can be changed quickly. In some states it takes a minimum of a session to pass it, plus a referendum....All of which take time.

I am not a constitutional scholar or indeed a lawyer for that matter, but it may be that the nature of legal language comes to the rescue here. I have written before at length about how I think about law and how it is not a simple, large set of "rules". For example What is Law? and also a series of blogposts starting here.

Simply put, my view is that the open-ended nature of legal language that may appear to be a "bug" at first glance - especially if you are a software engineer seeking to create  "rules" from it - is actually law's most brilliant feature.

Perhaps the time has come - in these extraordinary times - to revisit the interpretation of the phrase "in person" meetings to include "virtual" meetings in certain circumstances. I believe a lot of groundwork already exists for this with the gradual adoption over the last few decades of digital technology from faxes to digital signatures in legally binding environments.

In one fell swoop, such an interpretation of "in person" would fully pave the way for the fully virtual legislative meeting capability in states that have "in person" language in their constitutions. It is a matter for the courts obviously, as that is where the "interpretation" function lies, at least in common law jurisdictions.

I do not mean to suggest that there is some sort of magic wand to be waved here, but I do believe that with all the dedicated, talented legal people looking at enabling virtual legislative sessions at the moment, a legal solution will be found in all states that need it.

In parallel of course, the technology has come on in leaps and bounds over the last two decades to facilitate it, once the legal framework is in place to enable it. The technology in question is my day job and has been for about thirty years. It is very exciting to be in a position to help. We have all the modules we need right now for the technology having spent decades building out digitial systems in Legislatures/Parliaments already.

Indeed, we are already working with a number of legislatures (and also with local government with PrimeGov), to extend our existing solutions to be fully virtual for legislatures and parliaments, covering chamber floors and committees. Deployment time can be as low as a matter of weeks.

For many legislatures, it is already full steam ahead towards support for virtual sessions. For those that need to make some preparatory legal framework modifications, my advice would be to do that in parallel. There is no need to wait. Do them in parallel. The time to start is now. Today.

This is all happening in my lifetime.  I never would have guessed it, but I am delighted to be part of it having spent 30 years thinking about it. The new normal is upon us.

An alternative model of computer programming : Part 2

This is part two of a series of posts about an alternative model of computer programming I have been mulling for, oh decades now. The first part is here: http://seanmcgrath.blogspot.com/2018/08/an-alternative-model-of-computer.html

The dominant conceptual model of computer programming is that it is computation, which in turn of course is a branch of mathematics. This is incredibly persuasive on many levels. George Boole's book An Investigation of The Laws of Thought, sets out a powerful way of thinking about truth/falsity and conditional reasoning in ways that are purely numerical and thus mathematical and, well, really beautiful. Hence the phrase “boolean logic”. Further back in time still, we find al-Khwārizmī in the Ninth century working out sequences of mathematical steps to perform complex calculations. Hence the word “algorithm”. Further back in the time of the ancient Greeks we find Euclid and Eratosthenes with their elegant algorithms for finding greatest common divisors and prime numbers respectively.

Pretty much every programming language on the planet has a suite of examples/demos that include these classic algorithms turned into math-like language. They all feature the “three musketeers” of most computer programming. Namely, assignment (e.g. y = f(x)), conditional logic (e.g. “if y greater than 0 do THIS otherwise THAT”) and branching (e.g. “goto END”).

These three concepts get dressed up in all sorts of fine clothes in different programming languages but, as Alan Turing showed in the Nineteen Thirties, you only need to be able to assign values and to “branch on 0” in order to be able to compute anything that is computable via a classical computer – a so called Turning Machine. (This is significantly less that everything you might want to compute but that is another topic for another day. For now, we will stick to classical computers as exemplified in the so-called Von Neumann Architecture and leave quantum computing for another day.)

So what's the problem? Mathematics clearly maps very elegantly to expressing the logic and the calculations needed to get algorithms formalized for classical computers. And this mathematics maps very nicely onto todays mainstream programming languages.

Well, buried deep inside this beautiful mapping are some ugly truths that manifest themselves as soon as you go from written software to shipped software. To see these truths we will take a really small example of an algorithm. Here it is:

“Let y be the value of f(x)

If y is 0

then set x to 0

otherwise set x to 1”

The meaning of the logic here doesn't matter and it doesn't matter what f(x) actually calculates. All we need is something that has some assignments and some conditional logic such as the above snippet.

Now ask any programmer to code this in Python or C++ or Java or and they will be done expressing the algorithm in their coding environment in a matter of minutes. It is mostly a question of adding the write “boilerplate” code around the edges, and finding whatever the correct syntax is in the chosen programming language for “if” and for “then” and for demarcating statements and expressing assignments etc.

But in order to ship the code to production items such as error handling, reliability, scalability, predictability.... – sometimes referrred to as the “ilities” of programming end up taking up a lot of time and a lot of coding. So much so that the coding for “ilities” that needs to surround shipped code is often many times larger that the lines of code required for the original purely mathematical mapping into the programming language.

All of this ancilliary code – itself liberally infused with its own assignments and conditional logic – becomes part of the total code the needs to be created to ship code and most of it needs to be managed for the life time of the core code itself. So now we have code for numeric overflows, function call timeouts, exception handlers etc. We have code for builds, running test scripts, shipping to production, monitoring, tracing...the list goes on and on.

The pure world of pure math rarely needs to have any of these as concerns because in math we say “let x = f(x)” without worrying if f(x) will actually fall over and not give us an answer at all, or, perhaps worse, work fine for a year and then start getting slower and slower for some unknown reason.

This second layer of code – the code that surrounds the “pure” code is very hard to quantify. Its very hard to explain to non-programmers how important it might prove to be, how much time it might take and then to make matters worse, it is very unusual to be able to say its “done” in any formal sense. There are always loose ends. Error conditions that code doesn't handle – either because they are believed to be highly unlikely or because there are an open ended set of potential error scenarios and its simply not possible to code for every conceivable eventuality.

Pure math is a land of zero computational latency. A land where calculations are independent of each other and cannot interfere with each other. A land where all communications pathways are 100% reliable. A land where numbers have infinite precision. A land of infinite storage capacity. A land where the power never dies...etc. Etc.

All this is to make the point that in my opinion that for all the appealing mapping from pure math to pure algorithms, actual computer programming involves adding many other layers to cater for the fact that the real world of shipped code is not a pure math “machine”.

Next up. My favorite subject. Change with respect to time....

An alternative model of computer programming : Part 1

Today, I googled "How many programming languages are there?" and the first hit I got said, "256".

I giggled - as any programmer would when a power of two pops up in the wild like that. Of course, it is not possible to say exactly how many because new ones are invented almost every day and it really depends on how you define "language"...It is definitely in the hundreds at least.

It is probably in the thousands, if you rope in all the DSLs and all the macro-pre-processors-and-front-ends-that-spit-out-Java-or-C.

In this series of blog posts I am going to ask myself and then attempt to answer an odd question. Namely, "what if language is not the best starting point for thinking about computer programming?"

Before I get into the meat of that question, I will start with how I believe we got to the current state of affairs - the current programming linguistic tower of Bable - with its high learning curve to enter its hallowed walls. With all its power and the complexities that seem to be inevitable in accessing that power.

I believe we got here the day we decided that computing was best modelling with mathematics.

The day I found Python....

It was 21 years ago. 1997. I was at an SGML conference in Boston (http://xml.coverpages.org/xml97Highlights.html). It was the conference where the XML spec. was launched.

Back in those days I mostly coded in Perl and C++ but was dabbling in the dangerous territory known as "write your own programming language"...

On the way from my hotel to a restaurant one evening I took a shortcut and stumbled upon a bookshop. I don't walk past bookshops unless they are closed. This one was open.

I found the IT section and was scanning a shelf of Perl books. Perl, Perl, Perl, Perl, Python, Perl....

Wait! What?

A misfiled book....Name seems familiar. Why? Ah, Henry Thomson. SGML Europe. Munich 1996. I attended Henry's talk where he shows some of his computational linguistics work. At first glance his screen looked like the OS had crashed, but after a little while I began to see that it was Emacs with command shell windows and the command line invocation of scripts, doing clever things with markup, in Python. Very productive setup fusing editor and command line...

I bought the mis-filed Python book in Boston that day and read it on the way home. By the time I landed in Dublin it was clear to me that Python was my programming future.  It gradually replaced all my Perl and C++ and today, well, Python is everywhere.

Thinking about Software Architecture & Design : Part 14

Of all the acronyms associated with software architecture and design, I suspect that CRUD (Create Read/Report Update Delete) is the most problematic. It is commonly used as a very useful sanity check to ensure that every entity/object created in an architecture is understood in terms of the four fundamental operations : creating, reading, updating and deleting. However, it subtly suggests that the effort/TCO of these four operations are on a par with each other.

In my experience the "U" operation – update  – is the one where there are the most “gotchas” lurking. A create operation – by definition – is one per object/entity. Reads are typically harmless (ignoring some scaling issues for simplicity here). Deletes are one per object/entity, again by definition. More complex than reads generally but not too bad. Updates however, often account for the vast majority of operations performed on objects/entities. The vast majority of the life cycle is spent in updates. Not only that, but each update – by definition again – changes the object/entity and in many architectures updates cascade. i.e. updates cause other updates. This is sometimes exponential as updates trigger other updates. It is also sometimes truly complex in the sense that updates end up,through event cascades, causing further updates to the originally updated objects....

I am a big fan of the CRUD checklist to cover off gaps in architectures early on but I have learned through experience that dwelling on the Update use-cases and thinking through the update cascades can significantly reduce the total cost of ownership of many information architectures.

Thinking about Software Architecture & Design : Part 13

Harold Abelson, co-author of the seminal tome Structure and Interpretation Of Computer Programs (SICP) said that “programs must be written for people to read, and only incidentally for machines to execute.”

The importance of human-to-human communication over human-to-machine is even more true in Software Architectures, where there is typically another layer or two of resolution before machines can interpret the required architecture.

Human-to-human communications is always fraught with potential for miscommunications and the reasons for this run very deep indeed. Dig into this subject and it is easy to be amazed that anything can be communicated perfectly at all. It is a heady mix of linguistics, semiotics, epistemology and psychology. I have written before (for example, in the “What is Law Series - http://seanmcgrath.blogspot.com/2017/06/what-is-law-part-14.html) about the first three of these, but here I want to talk about the fourth – psychology.

I had the good fortune many years ago to stumble upon the book Inevitable Illusions by Massimo Piattelli-Palmarini and it opened my mind to the idea that there are mental concepts we are all prone to develop, that are objectively incorrect – yet unavoidable. Think of your favorite optical illusion. At first you were amazed and incredulous. Then you read/discovered how it works. You proved to your own satisfaction that your eyes were deceiving you. And yet, every time you look at the optical illusion, your brain has another go at selling you on the illusion. You cannot switch it off. No amount of knowing how you are being deceived by your eyes will get your eyes to change their minds, so to speak.

I have learned over the years that some illusions about computing are so strong that it is often best to incorporate them into architectures rather than try to remove them. For example, there is the “send illusion”. Most of the time when there is an arrow between A and B in a software architecture, there is a send illusion lurking. The reason being, it is not possible to send digital bits. They don't move through space. Instead they are replicated. Thus every implied “send” in an architecture can never be a truly simple send operation and it involves at the very least, a copy followed by a delete. 

Another example is the idea of a finite limit to the complexity of business rules. This is the very (very!) appealing idea that with enough refinement, it is possible to arrive at a full expression of the business rules that express some desirable computation. This is sometimes true (especially in text books) which adds to the power of the inevitable illusion. However, in many cases this is only true if you can freeze requirements – a tough proposition – and often is impossible even then. For example in systems where there is a feedback loop between the business rules and the data creating a sort of “fractal boundary” that the corpus of business rules can never fully cover.

I do not let these concerns stop me from using concepts like “send” and “business rule repository” in my architectures because I know how powerfully these concepts are locked into all our minds. However, I do try to conceptualize them as analogies and remain conscious of the tricks my mind plays with them. I then seek to ensure that the implementation addresses the unavoidable delta between the inevitable illusion in my head and the reality in the machine.

Thinking about Software Architecture & Design : Part 12

The word “flexible” gets used a lot in software architecture & design. It tends to get used in a positive sense. That is, "flexibility" is mostly seen as a good thing to have in your architecture.

And yet, flexibility is very much a two edged sword. Not enough of it, and your architecture can have difficulty dealing with the complexities that typify real world situations. Too much of it and your architecture can be too difficult to understand and maintain. The holy grail of flexibility, in my opinion, is captured in the adage that “simple things should be simple, and hard things should be possible.”.

Simple to say, hard to do. Take SQL for example, or XSLT or RPG...they all excel at making simple things simple in their domains and yet, can also be straitjackets when more complicated things come along. By “complicated” here I mean things that do not neatly fit into their conceptual models of algorithmics and data.

A classic approach to handling this is to allow such systems to be embedded in Turing Complete Programming language. i.e. SQL inside C Sharp. XSLT inside Java etc. The Turing Completeness of the programming language host ensures that the “hard things are possible” while the core – and now “embedded system” - ensures that the simple things are simple.

Unfortunately what tends to happen is that the complexity of the real world chips away at the split between simple and complex and, often times, such hybrid systems evolve into Turing Complete hosts. i.e. over time, the embedded system for handling the simple cases, is gradually eroded and then one day, you wake up to find that it is all written in C# or Java or whatever and the originally embedded system is withering on the vine.

A similar phenomenon happens on the data side where an architecture might initially by 98% “structured” fields but over time, the “unstructured” parts of its data model grow and grow to the point where the structured fields atrophy and all the mission critical data migrates over to the unstructured side. This is why so many database-centric systems organically grow memo fields, blob fields or even complete distinct document storage sub-systems over time, to handle all the data that does not fit neatly into the “boxes” of the structured fields.

Attempting to add flexibility to the structured data architecture tends to result in layers of abstraction that people have difficult following. Layers of pointer indirection. Layers of subject/verb/object decomposition. Layers of relationship reification and so on....

This entropy growth does not happen overnight. The complexity of modelling the real world chips away at designs until at some point there is an inflection. Typically this point of inflection manifests in a desire to “simplify” or “clean up” a working system. This often results in a new architecture that incorporates the learnings from the existing system and then the whole process repeats again. I have seen this iteration work at the level of decades but in more recent years the trend appears to be towards shorter and short cycle times.

This cyclic revisiting of architectures begs the obvious teleological question about the end point of this cycle. Does it have an end? I suspect not because, in a Platonic sense, the ideal architecture can be contemplated but cannot be achieved in the real world.

Besides, even if it could be achieved, the ever-changing and monotonically increasing complexity of the real world ensures that a perfect model for time T can only be achieved at some future time-point T+N, by which time, it is outdated and has been overtaken by the every shifting sands of reality.

So what is an architect to do if this is the case? I have come to the conclusion that it is very very important to be careful to label anything as an immutable truth in an architecture. All nouns, verbs, adjectives etc. that sound to you like that are “facts” of the real world, will, at some point bend under the weight of constant change and necessarily incomplete empirical knowledge.

The smaller the set of things you consider immutable facts, the more flexible your architecture will be. By all means, layer abstractions on top of this core layer. By all means add Turing Completeness into the behavioral side of the model. But treat all of these higher layers as fluid. It is not that they might need to change it is that they will need to change. It is just a question of time.

Finally, there are occasions where the set of core facts in your model is the empty set! Better to work with this reality than fight against it because entropy is the one immutable fact you can absolutely rely on. Possibly the only thing you can have an the core of your architecture and not worry about it being invalidated by the arrival of new knowledge or the passage of time.

Thinking about Software Architecture & Design : Part 11

It is said that there are really only seven basic storylines and that all stories can either fit inside them or be decomposed into some combination of the basic seven. There is the rags-to-riches story. The voyage and return story. The overcoming the monster story...and so on.

I suspect that something similar applies to Software Architecture & Design. When I was a much younger practitioner in this field, I remember a very active field with new methodologies/paradigms coming along on a regular basis. Thinkers such as Yourdon, de Marco, Jackson, Booch, Hoare, Dijkstra, Hohpe distilled the essence of most of the core architecture patterns we know of today.

In more recent years, attention appears to have moved away from the discovery/creation of new architecture patterns and architecture methodologies towards concerns closer to the construction aspects of software. There is an increasing emphasis on two way flows in the creation of architectures– or perhaps circular flows would be a better description. i.e. iterating backwards from, for example user stories, to the abstractions required to support the user stories. Then perhaps a forward iteration refactoring the abstractions to get coverage of the required user stories with less “moving parts” as discussed before.

There has also been a marked trend towards embracing the volatility of the IT landscape in the form of proceeding to software build phases with “good enough” architectures and the conscious decision to factor-in the possibility of needing complete architecture re-writes in ever short time spans.

I suspect this is an area where real world physical architecture and software architecture fundamentally differ and the analogy breaks down. In the physical world, once the location of the highway is laid down and construction begins, a cascade of difficult-to-reverse events starts to occur in parallel with the construction of the highway. Housing estates and commercial areas pop up close to the highway. Urban infrastructure plans – perhaps looking decades into the future – are created predicated on the route of the highway and so on.

In software, there are often similar amount of knock-on effects to architecture changes but when these items are themselves primarily software, rearranging everything based on a architecture is more manageable. Still likely a significant challenge, but more doable because software is, well “softer” than real world concrete, bricks and mortar.

My overall sense of where software architecture is today is that it revolves around the question : “how can we make it easier to fundamentally change the architecture in the future?” The fierce competitive landscape for software has combined with cloud computing to fuel this burning question.

Creating software solutions with very short (i.e. weeks) time horizons before they change again is now possible and increasingly commonplace. The concept of version number is becoming obsolete. Today's software solution may or may not be the same as the one you interacted with yesterday and it may, in fact, be based on an utterly different architecture under the hood than it was yesterday. Modern communications infrastructure, OS/device app stores, auto-updating applications, thin clients...all combine to create a very fluid environment for modern day software architectures to work in.

Are there new software patterns still emerging since the days of data flow and ER diagrams and OOAD? Are we just re-combining the seven basic architectures in a new meta-architecture which is concerned with architecture change rather than architecture itself? Sometimes I think so.

I also find myself wondering where we go next if that is the case. I can see one possible end point for this. An end-point which I find tantalizing and surprising in equal measure. My training in software architecture – the formal parts and the decades of informal training since then – have been based on the idea that the fundamental job of the software architect is to create a digital model – a white box – of some part of the real world, such that the model meets a set of expectations in terms of its interaction with its users (which may, be other digital models).

In modern day computing, this idea of the white box has an emerging alternative which I think of as the black box. If a machine could somehow be instructed to create the model that goes inside the box – based purely on an expression of its required interactions with the rest of the world – then you basically have the only architecture you will ever need for creating what goes into these boxes. The architecture that makes all the other architectures unnecessary if you like.

How could such a thing be constructed? A machine learning approach, based on lots and lots of input/output data? A quantum computing approach which tries an infinity of possible Turing machine configurations, all in parallel? Even if this is not possible today, could it be possible in the near future? Would the fact that boxes constructed this way would be necessarily black – beyond human comprehension at the control flow level – be a problem? Would the fact that we can never formally prove the behavior of the box be a problem? Perhaps not as much as might be initially thought, given the known limitations of formal proof methods for traditionally constructed systems. After all, we cannot even tell if a process will halt, regardless of how much access we have to its internal logic. Also, society seems to be in the process of inuring itself to the unexplainability of machine learning – that genie is already out of the bottle. I have written elsewhere (in the "what is law?" series - http://seanmcgrath.blogspot.com/2017/07/what-is-law-part-15.html) that we have the same “black box” problem with human decision making anyway).

To get to such a world, we would need much better mechanism for formal specification. Perhaps the next generation of software architects will be focused on patterns for expressing the desired behavior of the box, not models for how the behavior itself can be achieved. A very knotty problem indeed but, if it can be achieved, radical re-arrangements of systems in the future could start and effective stop with updating the black box specification with no traditional analysis/design/ construct/test/deploy cycle at all.

Thinking about Software Architecture & Design : Part 10

Once the nouns and verbs I need in my architecture start to solidify, I look at organizing them across multiple dimensions. I tend to think of the noun/verb organization exercise in the physical terms of surface area and moving parts. By "surface area" I mean minimizing the sheer size of the model. I freely admin that page count is a crude-sounding measure for a software architecture, but I have found over the years that the total size of the document required to adequately explain the architecture is an excellent proxy for its total cost of ownership.

It is vital, for a good representation of a software architecture, that both the data side and the computation side are covered. I have seen many architectures where the data side is covered well but the computation side has many gaps. This is the infamous “and then magic happens” part of the software architecture world. It is most commonly seen when there is too much use of convenient real world analogies. i.e. thematic modules that just snap together like jigsaw/lego pieces, data layers that sit perfectly on top of each other like layers of a cake, objects that nest perfectly inside other objects like Russian Dolls etc.

When I have a document that I feel adequately reflects both the noun and the verb side of the architecture, I employ a variety of techniques to minimize its overall size. On the noun side, I can create type hierarchies to explore how nouns can be considered special cases of other nouns. I can create relational de-compositions to explore how partial nouns can be shared by other nouns. I will typically “jump levels” when I am doing this. i.e. I will switch between thinking of the nouns in purely abstract terms (“what is a widget really” to thinking about them in physical terms: “how best to create/read/update/delete widgets?”). I think of it as working downwards towards implementation an upwards towards abstraction at the same time. It is head hurting at times, but in my experience produces better practical results that the simpler step-wise refinement approach of moving incrementally downwards from abstraction to concrete implementation.

On the verb side, I tend to focus on the classic engineering concept of "moving parts". Just as in the physical world, it has been my experience that the smaller the number of independent moving parts in an architecture, the better. Giving a lot of thought to opportunities to reduce the total number of verbs required pays handsome dividends. I think of it in terms of combinatorics. What are the fundamental operators I need from which, all the other operators can be created by combinations of the fundamental operators? Getting to this set of fundamental operators is almost like finding the architecture inside the architecture.

I also think of verbs in terms of complexity generators. Here I am using the word “complexity” in the mathematical sense. Complexity is not a fundamentally bad thing! I would argue that all system behavior has a certain amount of complexity. The trick with complexity is to find ways to create the amount required but in a way that allows you to be in control of it. The compounding of verbs is the workhorse for complexity generation. I think of data as a resource that undergoes transformation over time. Most computation – even the simplest assignment of the value Y to be the value Y + 1 has an implicit time dimension. Assuming Y is a value that lives over a long period of time – i.e. is persisted in some storage system – then Y today is just the compounded result of the verbs applied to it from its date of creation.

There are two main things I watch for as I am looking into my verbs and how to compound them and apply them to my nouns. The first is to always include the ability to create an ad-hoc verb “by hand”. By which I mean, always having the ability to edit the data in nouns using purely interactive means. This is especially important in systems where down-time for the creation of new algorithmic verbs is not an option.

The second is watching out for feedback/recursion in verbs. Nothing generates complexity faster than feedback/recursion and when it is it used, it must be used with great care. I have a poster on my wall of a fractal with its simple mathematical formula written underneath it. It is incredible that such bottomless complexity can be derived from such a harmless looking feedback loop. Using it wisely can produce architectures capable of highly complex behaviors but with small surface areas and few moving parts. Used unwisely.....

Thinking about Software Architecture & Design : Part 9

I approach software architecture through the medium of human language. I do make liberal use of diagrams but the diagrams serve as illustrators of what, to me, is always a linguistic conceptualization of a software architecture. In other words, my mental model is nouns and verbs and adjectives and adverbs. I look for nouns and verbs first. This is the dominant decomposition for me. What are that things that exist in the model? Then I look for what actions are performed on/by the things in the model. (Yes, the actions are also “things” after a fashion...)

This first level of decomposition is obviously very high level and yet, I find it very useful to pause at this level of detail and do a gap analysis. Basically what I do is I explain the model to myself in my head and look for missing nouns and verbs. Simple enough.

But then I ask myself how the data that lives in the digital nouns actually gets there in the first place. Most of the time when I do this, I find something missing in my architecture. There are only finite number of ways data can get into a digital noun in the model. A user can enter it, an algorithm can compute it, or an integration point can supply it. If I cannot explain all the data in the model through the computation/input/integration decomposition, I am most likely missing something.

Another useful question I ask at this level of detail relates to where the data in the nouns goes outside the model. In most models, data flows out at some point to be of use i.e. it hits a screen or a printout or an outward bound integration point. Again, most of the time when I do this analysis, I find something missing – or something in the model that does not need to be there at all.

Getting your nouns and verbs straight is a great first step towards what will ultimately take the form of objects/records and methods/functions/procedures. It is also a great first step if you are taking a RESTian approach to architecture as the dividing line between noun-thinking and verb-thinking is the key difference between REST and RPC in my experience.

It is hard to avoid prematurely clustering nouns into types/classes as our brains appear to be wired towards organizing things into hierarchies. I do this because I find that as soon as I start thinking hierarchically, I close off the part of my brain that is open to alternative hierarchical decompositions. I try to avoid that because in my experience, the set of factors that steer an architecture towards one hierarchy instead of another are practical ones, unrelated to “pure” data modelling. i.e. concerns related to organizational boundaries, integration points, cognitive biases etc.

Take the time to explore as many noun/verb decompositions as you can because as soon as you pick one and start to refine the model, it becomes increasingly hard to think “outside the box” of your own architecture.

Thinking about Software Architecture & Design : Part 8

It is common practice to communicate software architectures using diagrams, but most diagrams, in my experience are at best rough analogies of the architecture rather than faithful representations of it.

All analogies break down at some point. That is why we call them “analogies”. It is a good idea to understand where your analogies break down and find ways to compensate.

In my own architecture work, the main breakdown point for diagrams is that architectures in my head are more like movies than static pictures. In my minds eye, I tend to see data flowing. I tend to see behaviors – both human and algorithmic – as animated actors buzzing around a 3D space, doing things, producing and consuming new data. I see data flowing, data flowing out, data staying put but changing shape over time, I see feedback loops where data flows out but then comes back in again. I see the impact of time in a number of different dimensions. I see how it relates to the execution paths of the system. I see how it impacts the evolution of the system as requirements change. I see how it impacts the dependencies of the system that are outside of my control e.g. operating systems etc.

Any static two dimensional picture or set of pictures, that I take of this architecture necessarily leaves a lot of information behind. I liken it to taking a photo of a large city at 40,000 feet and then trying to explain all that is going on in that city, through that static photograph. I can take photos from different angles and that will help but, at the end of the day, what I would really like is a movable camera and the ability to walk/fly around the “city” as a way of communicating what is going on in it, and how it is architected to function. Some day...

A useful rule of thumb is that most boxes, arrows, straight lines and layered constructions in software architecture diagrams are just rough analogies. Boxes separating say, organizations in a diagram, or software modules or business processes are rarely so clean in reality. A one way arrow from X to Y is probably in reality a two way data flow and it probably has a non-zero failure rate. A straight line separating, say “valid” from “invalid” data records probably has a sizable grey area in the middle for data records that fuzzily sit in between validity and invalidity. And so on.

None of this is in any way meant to suggest that we stop using diagrams to communicate and think about architectures. Rather, my goal here is just to suggest that until we have better tools for communicating what architectures really are, we all bear in mind the limited ability of static 2D diagrams to accurately reflect them.

Thinking about Software Architecture & Design : Part 7

The temptation to focus a lot of energy on the one killer diagram that captures the essence of your architecture is strong. How many hours have I spent in Visio/Powerpoint/draw.io on “the diagram”? More than I would like to admit to.

Typically, I see architectures that have the “main diagram” and then a series of detail diagrams hidden away, for use by implementation and design teams. The “main diagram” is the one likely to go into the stakeholder presentation deck.

This can works fine when there are not many stakeholders and organizational boundaries are not too hard to traverse. But as the number of stakeholders grows, the power of the single architectural view diminishes. Sometimes, in order to be applicable to all stakeholders, the diagram becomes so generic that it really says very little i.e. the classic three-tiered architecture or the classic hub-and-spoke or the peer-to-peer network. Such diagrams run the risk of not being memorable by any of the stakeholders, making it difficult for them to get invested in it.

Other times, the diagram focuses on one particular “view” perhaps by putting one particular stakeholder role in the center of the diagram, with the roles of the other stakeholders surrounding the one in the middle.

This approach can be problematic in my experience. Even if you take great pains to point out that there is no implied hierarchy of importance in the arrangement of the diagram, the role(s) in the middle of the diagram will be seen as more important. It is a sub-conscious assessment. We cannot help it. The only exception I know of is when flow-order is explicit in the diagram but even then whatever is in the middle of the diagram draws our attention.

In most architectures there are “asks” of the stakeholders. The best way to achieve  these “asks” in my experience is to ensure that each stakeholder gets their own architecture picture, that has their role in the center in the diagram, with all other roles surrounding their part in the big picture.

So, for N stakeholders there are N "main views" - not just one. All compatible ways of looking at the same thing. All designed to make it easier for each stakeholder to answer the “what does this mean for me?” question which is always there – even if it is not explicitly stated.

Yes, it is a pain to manage N diagrams but you probably have them anyway – in the appendices most likely, for the attention of the design and implementation phase. My suggestion is to take them out of the appendices and put them into the stakeholder slide deck.

I typically present two diagrams to each stakeholder group. Slide one is the diagram that applies to all stakeholders. Slide two is for the stakeholder group I am presenting to. As I move around the different stakeholder meetings, I swap out slide number two.

Thinking about Software Architecture & Design : Part 6

Abstractions are a two-edged sword in software architecture. Their power must be weighed against their propensity to ask too much from stakeholders, who may not have the time or inclination to fully internalize them. Unfortunately most abstractions require internalization for appreciation of their power.

In mathematics, consider the power of Euler's equation and contrast it with the effort involved to understand what its simple looking component symbols represent. In music, consider the power of the Grand Staff to represent musical compositions and contrast that with the effort required to understand what its simple looking symbols represent.

Both of these abstractions are both very demanding and very powerful. It is not uncommon in software architecture for the practitioner community to enjoy and be comfortable with constantly internalizing new abstractions. However, in my experience, a roomful of software architects is not representative of a roomful of stakeholders in general.

Before you release your killer abstractions from the whiteboard into Powerpoint, try them out on a friendly audience of non-specialists first.

Thinking about Software Architecture & Design : Part 5

Most architectures will have users at some level or other. Most architectures will also have organisational boundaries that need to be crossed during information flows.

Each interaction with a user and each transition of an organizational boundary is an “ask”. i.e. the system is asking for the cooperation of some external entity. Users are typically being asked to cooperate by entering information into systems. Parties on the far end of integration points are typically being asked to cooperate by turning around information requests or initiating information transfers.

It is a worthwhile exercise while creating an architecture, to tabulate all the “asks” and identify those that do not have associated benefits for those who are performing the asks.

Any entities interacting with the system that are giving more than they are receiving, are likely to be the most problematic to motivate to use the new system. In my experience, looking for ways to address this at architecture time can be very effective and sometimes very easy. The further down the road you get towards implementation, the harder it is to address motivational imbalances.

If you don't have  an answer to the “what is in it for me?” question, for each user interaction and each integration point interaction, your architecture will face avoidable headwinds both in  implementation and in operation.

Thinking about Software Architecture & Design : Part 4

Any new IT system will necessarily sit inside a larger context. If that context includes the new system having its own identity – from “the new system” to “Project Unity” - it will be anthropomorphised by its users. This can be good, bad or neutral for the success of the new IT system.

It does not matter what form the naming takes e.g. “Project Horizon”, “Bob's System”, “The new HR system” or even a visual identity such as "the new button", or even a tactile identity such as “the new panel under the desk at reception”. In all cases the new IT system may be treated by existing team members in much the same way as a new team member would be treated.

New systems get “sized up”, so to speak, by their users. Attributes such as “fast”, “unreliable”, “inflexible” or even “moody” might be applied to the new system. These may be factually based, or biased, depending on the stance the community of users adopts towards the new system arriving into their team.

One particularly troublesome possibility is that the new system may be seen as causal factor in events unrelated to it. “X used to work fine before the new system came along....” The opposite can also happen i.e. the new system get plaudits for events it had no hand or part in. Causality versus correlation can be a tricky distinction to navigate.

Takeaway: sometimes the human tendency towards the anthropomorphic can be used to your advantage. If you suspect the opposite may be true for your new system, it can be useful to purposely avoid elaborate naming and dramatic rollout events which can exacerbate anthropomorphisation.

Sometimes, new systems are best rolled out with little or no fanfare in a “business as usual” mode. Sometimes it is not possible to avoid big bang system switchover events but if it is at all possible to adopt a phased approach to deployment, and transition slowly, I would recommend it for many reasons, one of which is the sort of team dynamics alluded to here.

As AI/Robotics advances, I think this will become even more important in the years ahead.

Thinking about Software Architecture & Design : Part 3

In software architecture and design we have some pretty deep theories that guide us on our way. We know how to watch out for exponential run times, undetectable synchronisation deadlocks, lost update avoidance etc. We have Petri nets, state charts, entity/attribute diagrams, polymorphic object models, statistical queuing models, QA/QC confidence intervals....the list goes on....

...and yet, in my experience, the success of a software architecture & design project tends, in my experience, to revolve around an aspect of the problem domain that is not addressed by any of the above. I call it the experiential delta.

Simply put, the experiential delta is a measure of how different the “to be” system appears to be, to those who will interact with it – experience it – day to day.

A system can have a very high architecture delta but a low experiential delta and be many orders of magnitude easier to get into production than a system with low architecture delta but a high experiential delta. 

It pays to know what type of experiential delta your “to be” solution represents. If it has high experiential delta, it pays to put that issue front and center in your planning. Such projects tend to be primarily process change challenges with some IT attached, as opposed to being IT projects with some process change attached.

In my experience, many large IT projects that fail, do not fail for IT reasons per se. They fail for process change reasons, but get labeled as IT failures after the fact. The real source of failure in some cases, is a failure to realize the importance of process change and the need to get process change experts into the room fast. As soon the the size of the experiential delta crystallizes.

Indeed in some situations it is best to lead the project as a process change project, not an IT project at all. Doing so has a wonderful way of focusing attention on the true determinant of success. The petri nets will look after themselves.

Thinking about Software Architecture & Design : Part 2

Technological volatility is, in my experience, the most commonly overlooked factor in software architecture and design. We have decades worth of methodologies and best practice guides that help us deal with fundamental aspects of architecture and design such as reference data management, mapping data flows, modelling processes, capturing input/output invariants, selecting between synchronous and asynchronous inter-process communication methods...the list goes on. 

And yet, time and again, I have seen software architectures that are only a few years old, that need to be fundamentally revisited. Not because of any significant breakthrough in software architecture & design techniques, but because technological volatility has moved the goal posts, so to speak, on the architecture.

Practical architectures (outside those in pure math such as Turing Machines) cannot exist in a technological vacuum. They necessarily take into account what is going on in the IT world in general. In a world without full text search indexes, document management architectures are necessarily different. In a world without client side processing capability, UI architectures are necessarily different, in a world without always-on connectivity.....and so on.

When I look back at IT volatility over my career – back to the early Eighties – there is a clear pattern in the volatility. Namely, that volatility increases the closer you get to the end-users points of interaction with IT systems. Dumb “green screens”, bit-mapped graphics, personal desktop GUIs, tablets, smart phones,  voice activation, haptic user interfaces..

Many of the generational leaps represented by these innovations have had profound implications on the software architectures that leverage them. It is not possible – in my experience – to abstract away user interface volatility and treat it as a pluggable layer on top of the main architecture. End-user technologies have a way of imposing themselves deeply inside architectures. For example, necessitating an event-oriented/multi-threaded approach to data processing in order to make it possible to create responsive GUIs. Responding sychronously to data queries as opposed to batch processing. 

The main takeaway is this: creating good software architectures pay dividends but they are much more likely to be significant in the parts of the architecture furthest away from the end-user interactions. i.e. inside the data modelling, inside discrete data processing components etc. They are least likely to pay dividends in areas such as GUI frameworks, client side processing models or end user application programming environments.

In fact, volatility is sometimes so intense, that it makes more sense to not spend time abstracting the end-user aspects of the architecture at all. i.e. sometimes it makes more sense to make a conscious decision to re-do the architecture if/when the next big upheaval comes on the client side and trust that large components of the back-end will remain fully applicable post-upheaval.

That way, your applications will not be as likely to be considered “dated” or “old school” in the eyes of the users, even though you are keeping much of the original back-end architecture from generation to generation.

In general, software architecture thinking time is more profitably spent in the back-end than in the front-end. There is rarely a clean line that separates these so a certain amount of volatility on the back-end is inevitable, but manageable, in compared to the volatility the will be visited upon your front-end architectures.

Volatility exists everywhere of course. For example, at the moment serverless computing models are having profound implications on "server side" architectures. Not because of end-user concerns - end-users do not know or care about these things - but because of the volatility in the economics of cloud computing.

If history is anything to go by, it could be another decade or more before something comes along like serverless computing, that profoundly impacts back-end architectures. Yet in the next decade we are likely to see dozens of major changes in client side computing. Talking to our cars, waving at our heating systems, installing apps subcutaneously etc.

Thinking about Software Architecture & Design : Part 1

This series of posts will contain some thoughts on software architecture and design. Things I have learned over the decades spent doing it to date. Things I think about but have not got good answers for. Some will be very specific - "If X happens, best to do Y straight away.", some will be philosophical "what exactly is X anyway?", some will be humorous, some tragic, some cautionary...hopefully some will be useful. Anyway, here goes...

The problem of problems

Some "problems" are not really problems at all. By this I mean that sometimes, it is simply the way a “problem” is phrased that leads you to think that the problem is real and needs to be solved.  Other times, re-phrasing the problem leads to a functionally equivalent but much more easily solved problem.

Another way to think about this is to recognize that human language itself is always biased towards a particular world view (that is why translating one human language into another is so tricky. It is not a simple mapping of one world view to another).

Simply changing the language used to describe a “problem” can sometimes result in changing (but never removing!) the bias. And sometimes, this new biased position leads more readily to a solution.

I think I first came across this idea in the book "How to Solve It" by the mathematician George Poyla.  Later on, I found echoes of it in the work of philosopher Ludwig Wittgenstein. He was fond of saying (at least in his early work) that there are no real philosophical problems – only puzzles – caused by human language.

Clearing away the fog of human language - says Wittgenstein - can show a problem to be not a problem at all. I also found this idea in the books of Edward de Bono whose concepts of “lateral thinking" often leverage the idea of changing the language in which a problem is couched as a way of changing view-point and finding innovative solutions.

One example De Bono gives is a problem related to a factory polluting water in a river. If you focus on the factory as a producer of dirty water, your problem is oriented around the dirty water. It is the dirty water that output that needs to be addressed. However if the factory also consumes fresh water, then the problem can be re-cast in terms of a pre-factory input problem. i.e. make the factory put its intake upstream from its water discharge downstream. Thus incentivizing the factory to not pollute the river. Looked at another way, the factory itself becomes a regulator, obviating or at least significantly reducing the need for extra entities in the regulation process.

In more recent years I have seen the same idea lurking in Buddhist philosophy in the form of our own attitudes towards a situation being a key determinant in our conceptualization of a situation as either good/bad or neutral. I sometimes like to think of software systems as "observers" of the world in this Buddhist philosophy sense. Admittedly these artificial observers are looking at the world through more restricted sense organs that humans, but they are observers none-the-less.

Designing a software architecture is essentially baking in a bias as to how "the world" is observed by a nascent software system. As architects/designers we transfer our necessarily biased  conceptualization of the to-be system into code with a view to giving life to a new observer in the world - a largely autonomous software system.

Thinking long and hard about the conceptualization of the problem can pay big dividends early on in software architecture. As soon as the key abstractions take linguistic form in your head i.e. concepts start to take the form of nouns, verbs, adjectives etc., the problem statement is baked in, so to speak.

For example. Imagine a scenario where two entities, A and B, need to exchange information. Information needs to flow from A to B reliably.  Does it matter if I think of A sending information to B or think of B as querying information from A? After all, the net result is the same, right? The information gets to B from A, right?

Turns out it matters a lot. The bias in the word "send" is that it carries with it the notion of physical movement. If I send you a postcard in the mail. The postcard moves. There is one postcard. It moves from 1) I have it to 2) in transit to 3) you have it (maybe).

If we try to implement this "send" in software, it can get very tricky indeed to fully emulate what happens in a real world "send" - especially if we stipulate guaranteed once and only once delivery. Digital "sends" are never actually sends. They are always replications, or normally replicate followed by delete.

If instead of this send-centric approach, we focus on B as the active party in the information flow  - querying for information from A and simply re-requesting it if, for some reason it does not arrive, then we have a radically different software architecture. An architecture that is much easier to implement in many scenarios. (Compare the retry-centric architecture of many HTTP systems compared to, say, reliable message exchange protocols.)

So what happened here? We simply substituted one way of expressing the business need - a send-oriented conceptualization, with a query-oriented conceptualization, and the "problem" changed utterly before our very eyes.

Takeaway : the language in which a problem is expressed is often, already a software architecture. It may or may not be a good version 1 of the architecture to work from. It contains many assumptions. Many biases. Regardless of whether or not it is linguistic or visual.

It often pays to tease out those assumptions in order to see if a functionally equivalent re-expression of the problem is a better starting point for your software architecture.