How I became a Senior Digital Architect

A colleague at work asked me the other day:

How did you become a solution architect?

It’s a good question and one which required a bit of thought. So I figured I might as well write my answer here and share it. Of course, the usual disclaimer is relevant here: this is my story, your situation is probably different, this is not the only way, batteries not included, yadda yadda.

Technically my role is a Senior Digital Architect. So I’m not really a Solution Architect on paper, but often introduce myself that way because it’s a much more familar job title for people in the industry. Getting the title right in various HR systems is a challenge, so I’ll just stick with my official title for now.

And by “architect”, I’m meaning someone who designs solutions, technical roadmaps/strategies and patterns/models for computer systems of many descriptions… not the traditional building architecture. But in many ways, there are loads of parallels, plus I’m quite interested in building architecture, too, so there’s that.

Early Beginnings: Landscape Architect

It’s no secret in my family that from a very early age I wanted to be a landscape architect. In fact, I’m pretty sure I said I wanted to be one before I even knew a lot about what a landscape architect really does. Something about urban design something-something. I even looked up the (then) guide for what TER you needed to get into the right course at uni. Ambitious for a primary school student.

I never really had a ‘green thumb’ as such, but I did like to dabble in growing plants when I was a kid.

(Probably a good thing I never went into sign writing!)

I also enjoyed drawing diagrams of houses and gardens, so hey, why not. Here’s an oldie from when I was 10:

(In looking for this old diagram, I came across many video game level designs, something I should explore more. Mental note.)

With the help of my family I also managed to build a sign, for my non-existent business for my non-existent skills as a landscape architect.

Having proven I could fix random computer problems as a child (although we only got our first compuiter - a 486sx - in about 92) and once I had completed an IT-related university degree (mainly because most companies only seemed to employ people with the piece of paper, regardless of their skills), I managed to hook a job at Lendlease thanks to a reference from one of my uni friends. So maybe the uni degree was a good investment after all?

(Yikes, I just summarised 15 years of my life in one sentence there)

The other day I was tidying out the various boxes of things I’ve kept under the bed for many years (and haven’t touched for 7+ years). I found this little gem that I would’ve annotated during a uni lecture:

Probably not a great deal of respect to the author. Maybe I’d look at it differently these days?

The technical path: Graduate Developer

By now you’ve probably worked out I was heading down the technical path. Removing viruses from people’s computers and replacing modems after big storms was only going to entertain me for so long. You see, my first job was working in a local computer shop, which was fun but surely there was more to this “IT” thing?

My graduate developer job at Lendlease didn’t initially pay great but it definitely opened my eyes to terrible big “E” Enterprise software and complex problems that needed solving. I learnt more than I ever wanted to know about Oracle Financials, the SQR programming language and how far you can really take an Excel spreadsheet if you add 40,000 lines of VBA code to it (including a custom-from-the-ground-up XML parser). That’s probably worth a whole ’nother article by itself, but it was impressive to see Oracle Financials essentially be fronted by a series of spreadsheet ‘packs’ which were, strangely, easier to use than anything Oracle could assemble with their giant pile of cash.

I learnt a lot about what makes big software packages tick, what was really possible when you integrated two things together, and when you really need to stop writing endless lines of VBA code in spreadsheets and move onto something a little more refined.

I guess I say ’technical path’ here because the other common pathway into becoming an architect is more from the business analysis angle, which is definitely a lot more business-focused than someone churning out code for a living. It would be interesting to chat with someone who took this more businessy angle to see their perspective. Hands up anyone who’s done this, I’d be happy to hear your thoughts.

Solution Designer

Beyond fixing up lots of poorly written reports at Lendlease, I soon progressed into a Solution Designer. The title just sounded really creative and designerish whilst still remaining a technical role. Perfect balance for me.

I remember filling out immigration forms at the time, as I travelled, that my role was a “DESIGNER”. Heh. I still like the sound of that.

Naturally, this role is all about designing solutions! Ha! It is about marrying up potential options to meet certain business requirements and requires you to take into account constraints (technical, budget, legal, operational, etc.) and work out what is the most appropriate solution. This role is really project or initiative focused and yet still has a place in ‘agile’ methods because surely by now most people have realised that agile does not equal “no documentation”.

Estimation is another key aspect to being a solution designer, and it’s not necessarily always used to validate a solution, but more to refine project timelines and plans to make sure all stakeholders understand what’s involved, how much it will cost and when they’ll get something.

I think the task of scoping out a solution and thinking about all practical possibilities is a much-needed skill to this day and often can be overlooked by teams who are super excited about churning out a solution without thinking about it.

I still do this today and I also still draw diagrams (when I can find the time) to visually describe solutions - which is sometimes the best approach. Diagrams can be ambiguous in meaning but also they can respond to change very effectively, so it’s one of the core fundamentals of being a solution designer.

Working as a solution designer from one project to the next is interesting, but it did sometimes feel a bit repetitive, like you were churning through a pipeline of projects with no end in sight.

Whilst in this role at Lendlease, I was able to transition to the same role at the Australian Broadcasting Corporation. I was actually quite intrigued by the fact that the ABC had the same role in their org structure. This made the move quite an easy one, although I did get a lot of questions at the time about how I was moving into the “media” industry and that would be such a change coming from a corporate background. Looking back, it doesn’t seem all that strange to me.

Solution Architect

Taking things up one level, an architect is a much more strategic role, less concerned about every little detail, but more concerned with the overall solution and how it fits into the ’target state’ of where technology should head. Getting your head out of the ‘application’ architecture world means you can suddenly spend more time on how differing systems connect together rather than worrying how ‘modular’ a codebase is or dealing with leaky abstractions.

The difference is really subtle, but I think the role of an architect is to plan out that strategic future and provide steps on how to get there. A Solution Design could simply be a part or component that ladders up to the bigger picture. I don’t think there’s a real science here, it’s about judging what’s required at the time and I think architecture often dips down into solution design and vice versa.

Engineering Manager (acting)

About 18 months ago I was encouraged into a new role of looking after a group of roughly a dozen engineers across 4 shared digital platforms. At this point I had never managed anyone before and I would say it was a great experience, in the end, because I learnt many things. But really, although I love leading people in a technical capacity, I don’t enjoy developing teams nearly as much. Sure, I like to support people in improving their careers and getting the most out of people, but it’s not nearly as much fun as analysing complex problems and ensuring everyone is on my side. Trying to do both at once is a real challenge in a massive technical environment!

You can read more about this in my companion blog (which was written just over 12 months ago): On being an Engineering Manager.

Some key takeaways from managing people are:

Managing people is difficult. I’m sure many people will tell you this, but gosh. They’re right. Telling people when they need to pull their head at the right time with the right approach in is hard, but something everyone should have experience on how to do it well. Dealing with issues around your staff suffering anxiety, making sure people have a clear pipeline of work and even just all of the paperwork is all part of the job. Systems don’t have any of this!

Developing highly performing teams takes a lot of work and leads to a great level of satisfaction and achievement for a leader. So I can totally understand and respect those who wish to provide the focus and attention that a true people management role really requires.

If this sounds like your bag, go for it! However, it’s not quite what I was after, so I moved what I would consider diagonally to…

Senior Digital Architect

This is my current role as I write this and It was one which I had the opportunity to craft myself, partly because the organisation really needed better technical strategy and partly because I was dead set keen on unlocking my time which was increasingly being consumed by people issues and recruitment! I was just dying to get back into drawing more diagrams, as well!

I see this role as a pivotal function of any great digital product organisation, which I believe the ABC is transforming into as you read this. It’s a long journey, naturally.

This role allows me to:

• Work across multiple projects, products, initiatives all at once. Both a blessing and a curse!
• Analyse solution options, prepare, document, present, standardise, workshop and build into roadmaps
• Have empathy with people at all levels
• Spend time taking people through the thought process and workings so they gain confidence in the solution and strategy
• Get people on board with my ideas, however crazy the ideas might appear at first
• Be a technical leader

One challenge is how to stay fresh and abreast of new technologies and opportunities. One activity I try to lean on is my side hustle, which is a small business that you can read about on my article Thoughts on working the side hustle.

Where to from here?

Well… keep making new strategies. There’s always room for another one! There’s always changes to make. There’s always an improvement that you could make to an existing artefact. The job is never done. And never stop learning. Right now I feel like I need a visual communication refresher, because I rely so much on it but I haven’t really had any formal training in it outside of a fantastic Stephen Few course. I’m sure I’m missing many things here.

Right now, some key challenges which need wrangling include:

• Product strategy
• Reliability engineering
• Data as a culture
• Privacy
• Finding time for data modelling, information architecture and what to do with metadata
• Effective support models out of hours
• Talent acquisition through the use of blogs and meet ups

Now that I look back over this list, it’s not ’traditionally’ architecture, but no good digital organisation should be without all of these things.

Final Thoughts

I’ll share a phrase which guides me each day, which is:

It’s not about the best solution, it’s about the least-worst solution

It’s amusing, but true in many ways as all solutions are about trade-offs.

This section ended up being longer than I expected but it’s probably the most important.

What I like about it

It’s what I would call a creative pursuit. I need to use many styles of communication skills (with visual being the most entertaining to me) to influence and encourage others towards a theoretical technical promised land. It’s creative because there are always new and innovative ways to solve problems. Sometimes you get stuck and need inspiration. A walk usually clears the mind. Then it’s back to the canvas again.

I like how whilst it’s super creative, it’s also super detailed. Flying in and out of the detail is part of the fun of it.

I find I end up working with practically everyone, in some capacity, across the division. This is fantastic for getting to know everyone, knowing who to ask specific questions and generally knowing what’s going on. This makes making decisions much easier because you already have a solid context. The flip side is that you can then get stuck on a certain line of thinking, which is why sometimes you need to ‘chew the fat’ with other teams.

Building up deep knowledge about the organisation over time is an interesting outcome. Sure, you can’t go to university and learn about how a specific company works, which is why the only place you can learn about the company is really at the company, but without this perpetual growth of knowledge, you’ll need have enough context. For fly-in fly-out architecture consultants, I really don’t know how they survive, given they don’t have that depth of knowledge about an organisation.

At the end of the day, I’m getting paid to draw diagrams! Here’s one for good measure for my serverless CMS:

What I don’t like about it (so much)

There is literally constant context switching as I jump from one team to another, many times throughout the day. There’s a lot of meetings, lots of catching up with various stakeholders, showcases to attend, presentations to make, business cases… you name it.

There’s the challenge of needing to know the technology without actively being “hands-on” everyday. Think about how you might need to know how to build the latest web project using AWS technologies you haven’t ever even written a line of code for. Do you just accept they work as per the sales documentation? How can you weed out the half-truths from the actual product?

From here, the future prospects are probably a more people-manager-route and less about playing with tech, if I never get bored of drawing diagrams (which I would have to admit will probably be never, because I love a good diagram). I’ve got no dramas what-so-ever of managing a team of avid architects and solution designers of course. All in aid of the cause, at the end of the day.

So

…there you have it. Leave a comment below and let me know your thoughts or experiences. I’d be interested to hear what you have to say.

Comments (0)