Architecturally Significant

“Architecturally significant” is a simple and useful concept that covers a few things…

It’s anything the architect (or anyone doing the architecture) needs to actively spend time and effort on.  It’s relatively more important, and getting it wrong would be “sub-optimal” – it won’t be easy to change and would have far-reaching consequences (e.g. costs and re-work).

Sometimes its about “picking your battles”.  Designing and developing solutions can be described as one long stream of decision making; in such a context the architect is going to be heavily involved in making these decisions, and sometimes the number of decisions that need to be made are more than they can easily handle – so picking the right ones is important.  (Putting aside for a moment the extremely valid point that decentralized decision making is a useful approach and so maybe the architect shouldn’t be the one making all of these decisions – at least not alone).

Working out when something is architecturally significant is a key part of an architects role (if you aren’t going to do it, not one else is), and given all too familiar time-pressures you’ll want to spend your time where it adds the most value.

Confused?  Being able to “separate the wheat from the chaff” is a key skill for anyone performing the role of an architect.

Let’s take an example

Imagine you were talking with someone about what they needed, and they said:

1. We need an online form that the user can fill in.
2. The submit button needs to be red.
3. The form needs to load in [x] seconds.
4. As part of the form they need to upload a file.

Which of these is architecturally significant?

“We need an online form that the user can fill in”

The lesson here is that, like a lot of things, this is unlikely to be architecturally significant in of itself, but, hiding underneath this might be something which is significant.  It’s one of those situations where you just need to keep a watching brief on it in case something comes out of the wood work.

As always, context is critical.  If this is part of a solution where there is already an identified way of implementing forms, then it’s less likely to be architecturally significant as there is already a solution in place.  If this is a “first” for the project and there isn’t an identified way of implementing the form then it probably is architecturally significant.  How many forms are you building, one?  Probably not so significant; 50 – that sounds significant.

“The submit button needs to be red”

Aesthetics aren’t architecturally significant – red Ferrari’s might go really fast, but red doesn’t have the same implications for databases (yes, shocking, I know).

But there might be a wider need here, one that as an architect and thought-leader within the project you are well placed to raise: “Is using red for the submit button good from a usability perspective?  Isn’t there something about colour-blindness we should think about?  Who’s looking after usability anyway”?

Sometimes being an architect isn’t to solve all the problems, it’s to help identify the skills that you need.  “Yes, because this is a new 30 million dollar multi-region, multi-language e-commerce initiative we think having a usability lead is a good idea”.

“The form needs to load in [x] seconds”

In general terms, anything that involves System Quality Attributes¹ (SQA), i.e. the concepts that underpin non-functional requirements (NFR), should immediately receive the attention of the architect; they may not be architecturally significant, but NFR’s are usually one of the architects key areas of attention.

In this case is it architecturally significant?  It largely depends on what the value of X is, and how the architecture and infrastructure compares to that.

As a stake-in-the-ground, I suggest to you that the 80/20 rule applies: 80% of the time a new solution will meet the performance needs of most users, without needing any “special” performance enhancing work.  In such cases performance isn’t architecturally significant.  It’s often something that is discussed – but it’s not common (in my experience, i.e. in more than 20% of projects) that something “serious” needs to be done for performance reasons.  By all means keep an eye on it but don’t loose sleep over it.

When might it be architecturally significant?  If the value of X is especially high, you know the infrastructure is especially poor (slow, known to not meet the requirement), or if there are other functional or computational factors which are out of the ordinary – then yes, it might be architecturally significant.

Don’t forget that you can always push-back: “yes we understand the performance targets you want to hit, but are you aware it looks like it may cost between $x-y,000,000”?

“As part of the form they need to upload a file”

This is an interesting one, for which I have a real-world example.  So before we continue, do you think this sounds architecturally significant?²  After all, handling file uploads is nothing new these days.

For this project:

1. We were using a COTS package which allowed users to upload files.
2. The client was relatively large organisation and successfully managed their own infrastructure.
3. Internal policy required all files coming into the organisation to be virus-scanned.
4. Their infrastructure included a server-based anti-virus solution that was used to verify email attachments going through the email server(s).

Unfortunately, whilst the anti-virus solution had no problems scanning attachments in the email flow it wasn’t able to scan the files being uploaded through the application – as these were embedded in a custom application web-service call from the client back to the service layer, and got inserted into the application database as a blob, and not as a separate file that the scanning solution could read.  And as strange as it might seem, yes we were the first project where web-based file uploading was a thing.

Without doubt, this scenario is of architectural significance.

For a start, what’s going to happen if we are unable to scan the embedded files?  Will functionality be disabled, affecting users?  Or will the entire solution scrapped for one that can? (not likely after >18 months work & associated costs).

Can we get dispensation to just not apply anti-virus scanning?  If so, the architect will be leading those discussions from the projects point of view, probably taking it to the relevant design authority, and documenting the decision(s).

In scenarios like this there’s often no immediately obvious “slam-dunk” technical solution, instead there’s probably going to be a number of technical solutions – all with trade-offs and implications that need to be considered (i.e. “it depends”).

There’s also the non-technical / “business” angle to consider.  If the business/client/users are happy to change the way they do things this can open up new technical solutions, or make existing ones more viable.  Remember that bending the business to meet technology half-way is not always a bad thing, the more aligned the two are the better the end result usually is.

To briefly expand on the technical options, in this case we could change the way the COTS package works and obtain a new module for the existing anti-virus solution so that it can be called by the COTS API.  But even then there’s still a raft of technical options and detail to work through (starting with a proof-of-concept would be wise), and not forgetting we’d also need to convince the COTS vendor that they should change their product and the client that they need (and pay for) this new component.

In situations like this “architecturally significant” takes on new meaning as we’re now impacting the wider organisational architecture – not just the projects.  This is not a totally uncommon thing to happen – in larger organisations change affecting the wider organisation can come from within individual projects, as they are often the ones driving new needs and capabilities.

So to close

1. Constantly be on the look-out for the things that matter.
2. Focus your time and effort accordingly.
3. Keep a watching-brief on things which seem innocent now but could be significant later or if circumstances change.

 

Footnotes:

1. An SQA is a way of describing, defining and thinking about a solution.  Examples of SQA’s include performance, security, maintainability and so on (aka the “illities”).  SQA’s are not NFR’s, just as “Performance” is not a NFR on it’s own: an NFR is testable.  SQA’s are the basis for NFR’s – but they aren’t the same thing.
2. If you said ‘no’, you’re wrong, if fact if you said ‘yes’ you’re also wrong.  Based on that much information (i.e. no where near enough) the correct response is something along the lines of “it depends”.  Once you learn to prefix any response to any question with “it depends” you are half-way to being an architect (yes that’s only partially serious).  Whether the rest of your subsequent response is actually helpful or not remains to be seen.

Advertisement

The Experience that is Bonriki International Airport (Departures)

 

Another luxury travel review for the internationally renown, Paris-London-Whakatu-Wutunugurra based magazine Luxury-Leisurecation .

Yes it’s slightly satirical.

Bonriki International Airport (departures) in Tarawa is an absolute scream, and fully lives up to the high expectations set by arrivals.

First you go into the departures area, a sweeping statement of Kiribati interior decoration and architecture.  The customs and check-in facilities are both very handy – no long tortuous walks in air-conditioned banality so often encountered in the West.

The immigration portal is ergonomically blended into the check-in lounge next to the relaxing check-in space.

At first glance, it appears that travelers are free to choose which they do first – check-in or customs – as there is physically nothing to stop you choosing which to do first, however, completing check-in formalities first is recommended.  Conveniently there’s a fairly long relaxed queue, so travelers needn’t feel under pressure if they don’t arrive at the airport by the scheduled check-in time.

Once all formalities have been completed, you pass into the executive-class departure lounge.  As with check-in, conventional Western pretentiousness has been fully rejected in favor of a culturally rich fully immersive experience; here you are not only free to mingle with local plane-spotters but you have complete access to all of Kiribati, as there are none of the access restrictions so common-place in I-Matang cultures.

Local executives relaxing in the Bonriki international executive lounge.

Kiribati plane-spotting is a very well patronized pastime.  There is always a large number of enthusiastic plane-spotters of all ages, calmly passing the time until the scheduled arrival of the next plane: waiting cross-legged on traditional woven mats, enjoying conversation and children running with screaming delight along the concourse.

Early-bird plane-spotters starting to take up the prime spots.  

The arrival of the plane is nothing less than an eruption, twofold.  First the unannounced roar of the engines as the de-accelerating plane rushes past the panoramic open windows of the executive-class lounge.  This is immediately followed by the roar and agile movement of the plane-spotters, particularly the younger less experienced ones, moving swiftly to the windows to greet the plane with gentle words of welcome, uttered in measured 120 Decibel screams.

Having then passed an idyllic hour-and-a-half in the executive lounge (or nearby location of your choice) you are free to pass through security and board.   In typical Kiribati style, the original departures area is cunningly transformed into access to the security area – through a door at the rear of the departure area.   Here at least the locals have subtly blended in Western décor with the addition of the security equipment and stark walls.

You then proceed across the gently warmed tarmac to the waiting aircraft, where you can prepare for the final stages of your emotional journey before beginning the physical one.