Weeknote 2024/03: missing cyclocross; digitally transforming my family; installing Ethernet and much, much more

Another week has flown by – this time I kept notes to keep track of it all in the hope it would speed up the weeknote writing. It didn’t, so I need to work on the format. Anyway, this is how it looks this week.

My week at work

Understandably, I can’t write much about what I do in the day job. Suffice to say, it’s been busy, busy, busy. I’m preparing for a presentation to the Node4 Go To Market (GTM) team next week. This will be me, along with my colleague Bjoern, presenting to the entire salesforce and trying to convince them why they should be selling more of the services we’re responsible for. And, in parallel, I’m refreshing the collateral to support the sales of those same services.

I also spent some time on a call with one of our business partner this week, learning more about how they are developing their offers and how we can potentially do more work together.

My week in cycling

I know, this blog is supposed to be about tech, but I also have two very sporty teenagers that I’m very proud of. Their sports activities are a big part of my week (and my life in general).

Last weekend, I should have been in Falkirk, supporting my eldest son, Matt, at the 2024 British National Cyclocross Championships. As things transpired, that was not to be…

At 2023’s National Champs (Matt’s first senior year), Cameron Mason was so dominant in the Elite/U23 Men’s race that only 7 riders were permitted to finish the race (under the 80% rule). It’s a big investment of time and money to travel the length of the country for a short race but we would have been there, if Matt felt he was ready for it. Unfortunately, after a challenging few weeks with a return to racing after spending the autumn leading cycle tours in Greece, he decided to end his cyclocross season early. Apart from podiums in the local Central Cyclocross League (CCXL), third place in the Central Regional CX Champs was to be his only significant result this season. He’s preparing to build two new bikes for the 2024/25 cyclocross season – and he has plans for the 2024 road season too. I’m sure those plans will end up in these weeknotes in due course.

Just as a side note, after the demise of GCN Plus, it’s great to see BBC Scotland providing mainstream TV coverage of the national champs!

My week in technology

Adding AirPlay to an old Hi-Fi amplifier

With a bonus weekend at home, I got to finish up a tech project that’s been on the list for a while – adding AirPlay to my old 1990s Technics amplifier. When I moved in with my wife, my mid-range Hi-Fi stack was labelled “black loud crap”. As a result, it was banished from the house, but still lives on in the Man Cave. Adding an old Raspberry Pi 2B running as an audio gateway has provided the necessary tech to cast audio, without needing to invest in more Sonos (or IKEA Symfonisk) as I have in the rest of the house. This is the guide I followed, at PiMyLifeUp.

There’s the odd stutter, which I think may be due to a weak 2.4MHz Wi-Fi signal. It could also be down to running on a relatively old Pi 2. It certainly beats connecting Spotify via Alexa which used my account and so only worked for me and not the whole family. Plus it also works with other apps, like Pocket Casts and Audible.

Wilson family digital transformation

Late last year, I convinced Mrs W that we could use the family calendar on our iPhones to manage our busy family life. Previously, the paper calendar on the kitchen wall was the single source of the truth. That’s not too helpful when we’re not at home. This digital transformation of the Wilson family has been a huge success but it’s also shown me that people use calendars in different ways!

For example, our eldest son is currently away skiing. Is that one long appointment for 2 weeks? Or do we just need to know the dates he leaves and returns? And how do we record our youngest son’s Hockey training sessions? Is it the actual session times, or the times we leave the house and return? I’m trying not to be too “Mark” about this, but it’s an interesting insight into how other people think!

On a related note, I also learned this week that not everyone sees pictures in their mind, like I do. I don’t know what they do “see”, but it explains why not everyone can visualise what something will look like when it’s finished!

AirTag all the the things

After a trial with an Apple AirTag in my luggage (very useful when it wasn’t put on the plane at Stansted one holiday), I’ve been expanding our use of these devices. One use case that’s been particularly helpful is my youngest son’s keys… as he’s already had to replace at least one set that he lost before I tagged them. Now I regularly hear the “FindMy sound” as he searches for them before leaving the house.

On a similar note, for Christmas, my eldest son bought me an Apple FindMy-compatible tracker for my glasses. It doesn’t have the Precision Finding feature of the AirTag, but it does tell me where they were last seen, and lets me play a sound. Now, when I leave them somewhere, I can listen for the chirp of the Orbit sensor. It’s a bit strange charging my glasses though, but this is relatively infrequent.

Other bits and pieces of tech

  • After seeing a thread about date formats, ISO standards and RFCs, I thought about my frustrations with people who write dates “the wrong way”. By the wrong way, I mean not putting the most significant portion first. The US convention of mm/dd/yyyy is nonsensical. UK dd/mm/yyyy is better, but I generally name files using yyyymmdd etc. because they appear in order. On that basis, I realised that my naming for these weeknotes should be year/week number (inspired by Sharon O’Dea). Previously I had erroneously named them week number/year. From this week forwards, that is corrected.
  • After watching a YouTube video, I successfully resuscitated an apparently-dead Li-ion battery pack (the on-board circuitry needed its capacity recharging before it would accept a charge). This is potentially dangerous – I’m not responsible for anything that happens if you try it, but it worked for me, and saved me quite a few quid. Some say to use a resistor for safety. Others stress to only “jump start” momentarily (as I did).
  • I was looking at some communications from Vodafone about the 3G switch off… and wondered if that is the same part of the spectrum as 4G… i.e. more channels freed up for 4G/5G or will 4G/5G have access to extra spectrum now? Twitter helped me out with that…
  • Hopefully that section between the hall (OpenReach ONT) and the garage “datacentre” (ISP router) is all the Ethernet I need to run, but I have plenty of spare cable if I need to pull any more for a potential CCTV project… (I’ve been watching lots of videos about Reolink cameras).
  • Oh yes, one more thing. I finally changed my LinkedIn profile picture… my previous professional headshot was taken when I was in my late 30s, I think. I’m nearly 52 and afraid it’s time to look my age. This may not sound like news but it took me ages to find something suitably professional that I liked!

My week in TV

I’ll spare you all my YouTube highlights this week but, over in streaming TV land, Mrs W and I wrapped up three excellent series:

  • Mr Bates vs the Post Office (ITV);
  • Slow Horses (Apple TV); and
  • The Crown (Netflix).

This last season of The Crown has been criticised for being too dramatic but I thought it was well done. There will be no season 7 and it feels like it was left at just the right point, at the marriage of Charles and Camilla (then Prince and Princess of Wales) and the early days of William and Katherine’s relationship (the current Prince and Princess of Wales). It even contained a nod to Queen Elizabeth II’s funeral, with her involvement in the plans but also some scenes that linked to the actual events last year.

And in case we hadn’t had enough Toby Jones, we’ve started watching season 2 of Detectorists, for some light hearted relief from the more serious stuff.

Other things that should probably be a blog post on their own

I was going to write some more, but I’m getting bored of writing this now – goodness knows how you feel, dear reader. So there may need to be an overflow post or two about these topics, or maybe the tweets will say enough:

  • Well-paid IT folks moaning about the inconvenience that strikes have on their lives… playing to the “them and us” narrative.
  • Rebooting the car to get Apple CarPlay to work again!
  • CTOs with 30 years of industry experience being approached about a job that claims to need a technical degree.
  • Storytelling. And how pictures can convey messages that words alone cannot. Or bring meaning to words when they are in another language that you only have a passing knowledge of.
  • Rail fare “simplification” and the very different approaches taken by LNER (UK Government-owned) and ScotRail (Scottish Government-owned).
  • Public sector IT contracts, and the need to be a good client – it’s not all about the supplier.
  • The increasingly anti-social nature of social media.

My week in pictures

Featured image: author’s own

Another approach to technology roadmaps

This content is 1 year old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Over the years, I’ve looked at a variety of approaches to mapping technology development, often aligned to strategy.

I’m a visual person – definitely working with maps, not lists. This means I am attracted to models that help to visualise the direction in which things are headed.

Many people will be familiar with models like Gartner’s Magic Quadrants, or Forrester Waves. I was intrigued today when I joined a webcast about the Thoughtworks Technology Radar. Unlike the models I mentioned from the big analyst firms, the Thoughtworks model is not “pay to play”. It’s purely based on the experiences of the people working at Thoughtworks (“the Thoughtworkers”). There are no partnerships to influence – just product/service experience.

How is does this model work?

Thoughtworkers propose “blips”, and these are assessed by a Technical Advisory Board before being placed (or not) on the Radar.

The Radar itself is split into quadrants. These relate to techniques, platforms, tools, and languages and frameworks. There are also four concentric rings for hold, assess, trial and adopt.

Each blip is assigned to a quadrant. It will then move through the rings as Thoughtworkers gain experience and form a view on the application of the technology or service.

Only around a third of proposed blips make it to the published volume (currently volume 27).

The diagram that accompanies this post shows the Radar, but with detailed information removed. To discover what the numbers represent, check out the current volume on the Thoughtworks website.

I asked about technologies that are reaching the end of their life and need to be sunsetted or retired. That’s not something Thoughtworks currently has the resources to manage. Blips are not maintained – they are a point in time view (like a blog post!). If a technology becomes harmful or problematic it may move back to the assess ring or be called out in hold.

Bring your own radar

So, why am I so excited? Well, I think this is something worthy of investigation as a wider tool. Almost ten years ago, I wrote about my experiences of technology standardisation at Fujitsu. More recently, I’ve adopted a model for roadmapping technologies that I have used with clients. I also had a failed attempt at technology standardisation (it lacked the resources or corporate buy-in to maintain and, to be fair, was probably superseded by vendor-supplied frameworks).

But what if I could come up with something like the Technology Radar for the technologies that we my employer uses in solutions? Maybe with Principal Consultants and Architects as gatekeepers? I initially thought that the Radar is Thoughtworks’ intellectual property, used as a marketing tool. Then I discovered it’s also available on an open-source basis to “Bring Your Own Radar” to allow Thoughtworks clients to visualise their technologies.

I probably need to think this through a little more and clarify the value I’m looking to gain. Right now, it’s just a collection of thoughts bouncing around my head but I’m sure it will form some order soon!

Architecture for the Microsoft platform: defining standards, principles, reference architecture and patterns

This content is 7 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

BlueprintIT architecture is a funny old game… you see, no-one does it the same way. Sure, we have frameworks and there’s a lot of discussion about “how” to “architect” (is that even a verb?) but there is no defined process that I’m aware of and that’s broadly adopted.

A few years ago, whilst working for a large systems integrator, I was responsible for parts of a technology standardisation programme that was intended to use architecture to drive consistency in the definition, design and delivery of solutions. We had a complicated system of offerings, a technology strategy, policies, architectural principles, a taxonomy, patterns, architecture advice notes, “best practice”, and a governance process with committees. It will probably come as no surprise that there was a fair amount of politics involved – some “not invented here” and some skunkworks projects with divisions defining their own approach because the one from our CTO Office “ivory tower” didn’t fit well.

I’m not writing this to bad-mouth a previous employer – that would be terribly bad form – but I honestly don’t believe that the scenario I’ve described would be significantly different in any large organisation. Politics is a fact of life when working in a large enterprise (and some smaller ones too!). And what we created was, at its heart, sound. I might have preferred a different technical solution to manage it (rather than a clunky portfolio application based on SharePoint lists and workflow) but I still think the principles were solid.

Fast-forward to 2016 and I’m working in a much smaller but rapidly-growing company and I’m, once again, trying to drive standardisation in our solutions (working with my peers in the Architecture Practice). This time I’m taking a much more lightweight approach and, I hope, bringing key stakeholders in our business on the journey too.

We have:

  • Standards: levels of quality or attainment used as a measure or model. These are what we consider as “normal”.
  • Principles: fundamental truths or propositions that serve as a foundation for a system or behaviour. These are the rules when designing or architecting a system – our commandments.

We’ve kept these simple – there are a handful of standards and around a dozen principles – but they seem to be serving us well so far.

Then, there’s our reference architecture. The team has defined three levels:

  • An overall reference model that provides a high level structure with domains around which we can build a set of architecture patterns.
  • The technical architecture – with an “architecture pattern” per domain. At this point, the patterns are still technology-agnostic – for example a domain called “Datacentre Services” might include “Compute”, “Storage”, “Location”, “Scalability” and so on. Although our business is purely built around the Microsoft platform, any number of products could theoretically be aligned to what is really a taxonomy of solution components – the core building blocks for our solutions.
  • “Design patterns” – this is where products come into play, describing the approach we take to implementing each component, with details of what it is, why it would be used, some examples, one or more diagrams with a pattern for implementing the solution component and some descriptive text including details such as dependencies, options and lifecycle considerations. These patterns adhere to our architectural standards and principles, bringing the whole thing full-circle.

It’s fair to say that what we’ve done so far is about technology solutions – there’s still more to be done to include business processes and on towards Enterprise Architecture but we’re heading in the right direction.

I can’t blog the details here – this is my personal blog and our reference architecture is confidential – but I’m pleased with what we’ve created. Defining all of the design patterns is laborious but will be worthwhile. The next stage is to make sure that all of the consulting teams are on board and aligned (during which I’m sure there will be some changes made to reflect the views of the guys who live and breathe technology every day – rather than just “arm waving” and “colouring in” as I do!) – but I’m determined to make this work in a collaborative manner.

Our work will never be complete – there’s a balance to strike between “standardisation” and “innovation” (an often mis-used word, hence the quotation marks). Patterns don’t have to be static – and we have to drive forward and adopt new technologies as they come on stream – not allowing ourselves to stagnate in the comfort of “but that’s how we’ve always done it”. Nevertheless, I’m sure that this approach has merit – if only through reduced risk and improved consistency of delivery.

Image credit: Blueprint, by Will Scullin on Flickr (used under a Creative Commons Attribution 2.0 Generic licence).

Technology standardisation – creating consistency in solution architecture

This content is 11 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

One of the things about my current role is that I can’t really blog much about what I do at work – it’s mostly not suitable for sharing outside the company.  That’s why I was pleased when my manager suggested I create a white paper outlining the technology standardisation approach that Fujitsu takes in the UK and Ireland. That is, in a nutshell, what I’ve been working to establish for the last year.

The problem is that, without careful control, the inherent complexity of integrating products and services from a variety of sources can be challenging and costly. Solution architects and designers are trained to create innovative solutions to problems but, all too often, those solutions involve bespoke elements or unproven technologies that increase risk and drive up the cost of delivery. At the same time, there are pressures to reduce costs whilst maintaining business benefit – pressures that run completely contrary to the idea of bespoke systems designed to meet each and every customer’s needs. Part of the answer lies in standardisation – or, as I like to think of it, creating consistency in solution architecture.

My technology standardisation paper was published last month and can be found on the Fujitsu UK website.

I’ll be moving on to something new in a short while (watch this space and I’m sure I’ll be able to talk about it soon), so it’s great to look back and say “that’s what I’ve been doing”.