Architectural Profiling is borrowed from Holistic Software Engineering
When it might be appropriate
- In situations where a lightweight approach to intentional architecture is required
- In situations where high design formality isn’t required
- When a simple approach to architecture analysis is required at a team of teams level before more analysis in contributing teams
- Where a team wants to cut wasteful requirements and architectural “analysis paralysis” without throwing out ignoring technical risks
- System of systems development
What is it?
When I look at a potential (or existing) system I think of it in terms of it’s complexity in terms of a few dimensions, they’re not set in stone and I might add or remove dimensions as the mood, and context, takes me. Doing this early on gives me a feel for the shape of a project’s requirements, architecture and solution. In fact it also means I can short cut writing a whole bunch of requirements, acceptance tests, designs and even code and tests.
Here’s an example of thinking about a simple-ish app that does some fairly hefty data processing, needs to do it reasonably quickly but not excessively and has got to do some pretty visualisation stuff. Other than that it’s reasonably straight forward.
You might notice that the x-axis is pretty much FURPS with a couple of extras bolted on (I’ll come back to the carefully avoided first dimension in a minute).
The y-axis ranges from no complexity to lots of complexity but is deliberately not labelled (normally one of my pet hates) so we can focus on the relative complexity of these dimensions of the requirements, quality, architecture and therefore solution.
The height of one of these bars helps me shape the architectural approach I’ll take to the project, and which bits and bobs I can reuse from my super bag of reuse.
For example, let’s take the security dimension. If it’s empty I know I don’t need users, audit logs etc. but if it’s medium, like it is in this example, I know that I’m probably going to need Use Cases and/or User Stories around things like:
- logging in
- changing password
- managing users
- managing permissions
- checking permissions
These are things I’ve done loads of times before so why bother writing lots of requirements for them? Why bother doing detailed design? Why bother writing the code and testing, instead let’s reuse some requirements, components and tests and let the reuse do it for us. We’ll still to end to end testing across our set of requirements, I’m not advocating ignoring all of the quality risks simply avoiding them in low complexity situations.
If the bar is higher up I might need things like LDAP integration, OAuth integration, encryption, auditing, digital signing, federated user data stores, legal compliance and other security related shenanigans.
The other dimensions I tend to look at other than the standard URPS are “Data Processing” by which I mean the number of entities I’ve got to deal with and the complexity of their relationships, finally this dimension is pushed up if I’ve got to do algorithmic stuff across that data, and it’s maxed out if I’ve got big data and massively parallelized processing. However for the lower levels of complexity I’d never write a CRUD use case or a bunch of storied that batch up to mean the same thing. Or write endless design diagrams covering the CRUD of each entity. A simple persistency mechanism (if anything other than obvious) and a good data model are all I need here.
Reporting and Visualisation means mucking around with complicated and often interactive displays of the aforementioned data.
The dimension I’ve ignored so far is “Differentiating Functionality” as this is the set of functional requirements that make your project unique. If this is empty you should probably be just buying something or slotting together some off the shelf components. Of course there are types of projects which might be low in functionality but high on performance and scale… that might be it’s differentiator.
This dimension is the stuff that adds business value and is often the most important stuff that the (maybe unenlightened) customer might prioritise above everything else. So if you backlog is only stuff related to this category then it’s probably not a very good reflection of reality. I make it a different colour to make all of these points and to help balance it’s content with the other important dimensions.
Technical risks, and likely quality risks, will be hiding in any dimension with high complexity, in testing terms high complexity areas are fertile ground when hunting for fringe cases.
This is how I’ve been doing architecture for over 10 years but I’ve never written it down before! I’m writing it down now so that collectively “architectural profiling”,”architectural overview sketching” and “lightweight mechanisms” can join up with the Project Forum practice for “just-enough” architectural approach to agile at scale.