Can you post-moderate architechure?

This is a bit of a thought experiment. Recently I wondered about how much rigour and big G ‘governance’ is helpful in architecture. Specifcally, the digital architecture kind I’m involved with in a daily basis. I want to see the role of governance accelerating teams to make great architectural decisions, not to hinder them. In some ways, this is similar to prescriptive procurement processes passed down from generation to generation: if they’re preventing teams from making great decisions, maybe the process isn’t so good after all?

⚠️ Warning: This idea hasn’t had enough time to prove itself, but like a lot of ideas, it’s still worth exploring!

(me speaking as a Creator Innovator…)

Moderation in Online Communities

So take typical moderation approaches for forum threads, comments, social media and user generated content within an online community. Typically, there’s a few different ways to do this, with varying degrees of success and effort for each..

You could pre-moderate all content before it gets published. This is super safe and what I do on my site. I don’t get a huge volume of genuine comments and so I can manage this myself. When articles on certain large media organisations get thousands of comments an hour (or more!), this becomes impractical very quickly, especially since you’re interested in keeping up with the latest conversation. Often, organisations will simply turn off comments because the firehose of vitriol is just too hard to deal with and the risk of defamation or landing in court is too high. Damn those cowardly keyboard warriors!

Machine learning could help a whole lot here. Train a model based on years of good vs abusive comments, flag things for mods to check by exception by scoring against a threshold. This technique is improving all the time. Machine learning to create or review architectures… well now there’s an idea. But that’s a thought experiment for another post.

That leaves post-moderation, which is the topic of today’s blog. It’s where you go along and review everything after the fact: it’s already live and published to the world, but you can clean up things which aren’t in the spirit of the community that you’re trying to encourage. This definitely has more risk than pre-moderation, but it’s also a lot less effort. You can rely on people to ‘report’ posts or flag inappropriate content, which means you can scale the moderation out to (most) members of said community. You can of course lean on people flagging content with both pre-moderation and machine-learning based techniques as well (the feedback loop is super valuable to improve the moderation model) but it’s most useful in a post-moderation approach.

What about architecture?

If you think about it, architecture is traditionally pre-moderated. All those sign-offs, gates, review boards, governance councills, sub-committees and steer co endorsements to proceed… nothing gets done until reams of documentation is produced, multiple presentations are made and everyone says OK.

This is for good reason. Projects are expensive, they take a lot of time and are inherantly risky. We don’t want people building the wrong thing or selecting the wrong solution! People make mistakes and dodgy architectures can cost organisations millions and years of lost time. So you want to get it right (or as I like to say, go with the least bad solution).

For projects, often teams are built up and then packed away again once the project is over. The lifecycle can depend on what’s being delivered, but is essentially short-lived by comparison. Consultants are sometimes involved, bring in much-needed firepower to plug those capability gaps in an organisation. Get the right people to do the job. Few, if any, staff are around to see the system through years of potential turmoil (operations) after the project team moves on to the next big thing.

This is contrasted with posting a comment online. It’s quick and low cost. Someone spent all of 2 minutes writing their seriously snarky post and generally, it’s easy to remove or ‘fix’ if it’s not in accordance to the Terms of Use, or similar policy. Not a huge deal compared to a misfiring project, that’s for sure!

Moving to ‘products’ instead of ‘projects’

The latest thing is to run more products rather than projects. Products have a defined lifecycle - just like projects - but instead of only being short-lived, they tend to last multiple years. Teams who work on products are often more stable, with consistent skills and knowledge being kept within the product team over the course of its life. New people might come and go as change is always constant, but you only really bring in the big guns when you might need to stratch for a new deliverable. But again, short-term boost.

Architecture is still very important when building products. One of the key benefits of having ’long lived product teams’ is you would hope that teams are more interested in sustainability of their products (so they can continue to roll out cool things without it blowing up in the middle of the night or costing a bomb to maintain) than a quick project splash to add some feature to a system that few staff look after. It feels good to have teams ‘dog fooding’ and having to wear both sides of the equation without the proverbial “throwing over the fence” on go-live day.

This is the dream of course and some teams do struggle to keep a good balance of “features” and “essential maintenance”. Some might call it ’tech debt’ but really, there are always unsexy things that need to be maintained in software, just like how a building needs quite a lot of maintenance long after it was built.

What if we don’t have very many architects nor budget to hire more? It would be lovely to assign even a part-time architect to all of these product teams, so that they can bust out their crayons and do architecture. All that kind of future technology strategic planning stuff. And lots of boxes and lines. Perhaps product teams manage their own architecture backlog within their product today without even realising it.

So in this product delivery mode, with limited ‘architectural’ resources, what if we were to post moderate architecture?

If online communities have Terms of Use, then with architecture we have standards, patterns, guidelines, frameworks and templates to guide our merry product teams in the right direction. These are guides of course and not everyone is great at following (or even reading) them. There’s another blog topic.

But architects are so expensive!

(No, this is not a bid for a payrise!)

We may not have an architect in every team (we’re an expensive bunch) and so there must be other ways to try and curtail resource-sapping architectures from pollinating in the organisation than to force all teams to product large presentations to deliver to a range of stakeholders for their “sign-off”.

Post moderation would mean letting teams run their merry course, within light guidelines, to have a certain level of technical freedom without having to gain autographs from authority for new ideas.

Over time, a lot of things would be built. Some of them would be good, some would be not-so-good. Teams would run fast which is a useful attribute given that everyone is resource-constrained and any hindrance is going to double down on grinding teams to inefficiency. They’d probably run really fast until they had to re-platform due to… an early architecture mistake. Or maybe they’re just lucky.

When mistakes are made, these may be able to be corrected afterwards. This is the pivotal moment because significantly bad architectures can’t be unpicked easily because of how it underpins the entire product and affects each new part the team adds to their precariously stacked card house.

Architecture is so fundamental to planning for the future. However, I do feel like solid teams who have been in the game for a few years don’t need to be told how to do their job from an ivory tower architect.

I’ve also seen things where teams go off to build their own thing - quite against the architecture direction at the time - and after a year or two, it turns out it was actually quite a good idea. In fact, this kind of approach could benefit “vendor lock-in” and flexibility. So it’s important to be aware that what might first seem to be a ‘poor’ architecture, could actually result in a really good outcome given time. So easy to forget there is also no perfect option!

The hope is that given product teams need to look after their own creations, that they would be more incentivised to create something that they can easily maintain and extend. Potentially reaching for “build” over “buy” is something that would happen a whole lot more if teams were left to their own devices. I do like the idea that the team makes their own things better because they know where the pains are and want to make their lives easier.

But I’m thinking, just like an online community, couldn’t you review things - post mortem style - and then adjust as you go?

This would make teams feel a lot more freedom in being creative with their solutions, provided the solution was within some sort of boundary. You don’t want teams going crazy, so some parameters would be handy just to make sure things don’t go too wild. Maybe there’s a really basic set of non-negotiable things that everyone needs to do: think about security, privacy and costs. There’s likely to be a bit more detail here, however don’t reach for a 50 page standards document that nobody is going to read.

Beyond this, keep it open to creativity. I’m a big fan of review-by-exception. If you’re running within all the normal agreed parameters, hey, go for it!

… But that shifts the conversation to innovation, which is a great place to be and could bring in some ’natural’ tensions around trying new things outside of known/agreed parameters in order to discover new ways of doing things. How to do this without stifling creativity? Maybe it’s a case of being open to break the rules … sometimes. If you don’t break the rules every now and then, how do you know if the rules are appropriate?

I think I could write another blog on the topic of encouraging innovation, so I’ll park that one for next time.

What’s the role of a lead or domain architect?

This comes back to the architecture standards, patterns, guidelines, frameworks and templates. When do these get established and who does it? Well, that’s where a lead architect or domain architect comes in, who’s main job could be to make sure these things exist - not necessarily to write them - and to encourage others to contribute and use them. It feels more like a influencing & ‘caretaking’ role and less about doing all the documentation within the architecture function. Changes to these documents could be subject to a pull request process - much like code - rather than having to raise modifications to documents which then have to wait for the higher powers to meet, review and endorse any changes.

Key undercurrents at play are speed with sustainability. Why can’t we have both? There is a balance there which needs attention and having long drawn-out processes can be a huge distraction. Teams will naturally gravitate to what’s easy, not necessarily what’s governed as “right”.

I think of traditional architecture to be quite slow. But surely architecture can be fast, if we want it to be?

Adding in ‘architecture health checks’

One other concept I’ve been toying with lately which could be a direct way to post-moderate is a more regular ‘architecture health check’ which would consisent of a small number of criteria and wouldn’t take a huge amount of time to complete. It would avoid being a project post-implementation review style affair because that level of ‘deep dive’ activity would take a lot of time and time is scarce. The point would be to simply come up with an architectural rating so that over time, you could see if a product was improving and in what categories. Or perhaps if there was a more consistent theme, that the checklist and guidelines might have to change because they are no longer appropriate.

The bottom line

Worst case scenario for online communities is simply the comments feature is completely shutdown as the moderation effort becomes too much to manage. Let’s hope architecture never gets to that point, but I reckon post moderation is worth a try if it can deliver speed and sustainability without complicating matters by introducing irreversible solutions.

Well that’s about where I’m at now. Thoughts?

Comments (0)