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