Monthly Retrospective: April 2024

Another look back at some of the things I’ve been up to over the last few weeks…

At work

April marks a year since I started my transition to a new role at Node4. I didn’t move over full-time until July, but that’s when I stopped running what was formerly risual’s Architecture team and joined the Office of the CTO. This is not the forum to share the full details but suffice to say I had manouevred myself into a position where I was very unhappy – neither close to the tech nor able to best use my skills to provide value to the organisation and to our clients.

The change in role has been a breath of fresh air: the focus has changed a few times and there have been some bumps on the road; but one thing is core – I get up each morning and think about how best to add value. Whether that’s building out collateral for our public cloud portfolio, developing a new offering to guard against ransomware, helping clients with their IT Strategy or getting some structure around our “thought leadership” outputs.

The month ended with Node4’s “Go To Market” conference, in Nottingham. It’s an opportunity to set the agenda for the coming year and make sure we’re all headed in the same direction. This was the first time I’d attended and it was also a brilliant opportunity to meet some of my colleagues from across the business.

I managed to get myself into the video somehow, despite not officially being one of the presenters…

After two days of socialising, I was completely wiped out and needed some time to decompress. It’s left me thinking a lot about introversion. On the flip side, I also need to work on my FOMO… being one of the last to go to bed on the first night was not smart. At my age, I should know better.

Blogging

As usual, I didn’t find much time to blog this month, but I did write a thing about Enterprise Architecture, based on Dave Clark and Sophie Marshall’s good work…

Away from work

It’s not often that I go to the theatre but I saw the 1990s TV sitcom Drop the Dead Donkey was returning in theatre format with the original cast. I then failed to book tickets, missing it in Milton Keynes by a week. I asked myself if I could be bothered to go to Birmingham instead? Well, why not… I had a birthday so that was an opportunity to do something different!

I loved it, but it’s definitely written for an audience of a certain age (and I fit that demographic). For those less familiar with the original TV programme, it’s still amusing, but it does help to understand the characters and how they have developed over 30 years.

A matinee theatre show in a major city gave us an opportunity for a day out. So, afterwards we wandered down to The Custard Factory in Digbeth, for food and drink at Sobremesa and Rico Libre.

Oh yes, and I couldn’t help but be amused when I spotted that the image on the vinyl wrap in the train toilets contained an empty vodka bottle…

Playing with tech

If last month was about Meshtastic, this month has been Home Assistant. After initially installing on a Raspberry Pi to try it out, I quickly moved to a dedicated device and bought a Home Assistant Green. There was nothing wrong with the Pi installation, but I could use a Raspberry Pi 5 for other things. I’m still getting to grips with dashboards but Home Assistant has pulled all of my various smart devices together into one platform. This thread tells some of the story:

Annoyingly though, iCloud’s “was this you?” messages are not very helpful when you have automated services using your account:

I’ve also been upgrading the home Wi-Fi, moving from a consumer AmpliFi mesh to a solution based on UniFi equipment. That’s been an adventure in itself and will probably be a blog post in its own right.

And, I “went viral” (well, certainly had far more engagement than my normal tweets do), with a family service announcement for Wi-Fi updates…

Elsewhere on the Internet

  • On the need for critical thinking:
  • On outdated anti-WFH rhetoric:
  • On brilliant advertising:
  • On the decline of reporting:
  • On the value (or otherwise) of a degree:
  • On blogging:
  • On whether or not it’s useful to refer to “cyber”:
  • On the reasons that things sometimes cost more than you think they should:

    Travel

    As is usual, supporting Matt with his cycling races has meant a fair amount of travel and this month’s Premier Inn destinations have been… Tiverton and Stockton-on-Tees. Stockton was the overnight stay for the East Cleveland Classic, where I was in the team car all afternoon – and what an experience that was!

    There was also a race in Leicestershire where Matt was in the break for 2 hours before getting caught and then boxed in on the final sprint.

    But the big one was supposed to have been the CiCLE Classic in Rutland, until it was unfortunately cancelled on the day due to biblical rain. I do feel for the organisers in these scenarios, but even more so for the teams that had travelled from overseas.

    Away from cycling, but very exciting, is starting to plan an Interrail trip with Ben this summer. I only have two weeks’ leave available, but i’m pretty sure we’re going to have a brilliant time. It’s not the first time for me – I went solo in the early 1990s – but things have changed a lot since then.

    This month in photos

    Wrap-up

    That’s all for this month… May’s nearly over now but I have some notes ready for a review – hopefully not too long after the end of the month!

    Featured image taken from Node4’s Go To Market video, on LinkedIn

    The Enterprise Architecture Stack

    Over the years, I’ve written several posts about IT architecture. Whilst it seems that there is an increasing trend to call experienced IT folks “architects”, one of my core beliefs is that Enterprise Architecture is not the same as “architecting” IT at enterprise scale. Yes, creating an IT architecture that will scale to support a global organisation with thousands of users is “enterprise scale” – but it’s not Enterprise Architecture.

    So what is Enterprise Architecture?

    Like so many things in life, an illustration can really help describe a point. And, a few years ago, I came across an excellent Enterprise Architecture diagram from Dave Clark and Sophie Marshall. You can see it as the featured image at the top of this post and one of the reasons I like it so much is that it’s clear that the technology is only one of several factors in a whole stack of considerations.

    I adapted it (under Creative Commons) but the basic premise of the diagram remained the same – step back from the problem and understand the organisation to consider its needs and requirements. We need to know what is needed before we can can consider solutions! Then, we should ask what good looks like. Don’t just dive in with technology.

    Let’s take each layer in turn… and you’ll see that, right away, I added another layer at the top.

    Purpose

    The purpose is about why an organisation exists. It should be straightforward to answer but is hopefully more than “to deliver value to our shareholders”. A Council may exist to provide services (statutory and otherwise) to citizens. A retailer may exist to (make money and) provide the best selection of fashionable clothing at affordable prices. It’s entirely logical that the organisation’s culture will be strongly linked to its business motivations.

    Many organisations will give an indication of their purpose on their website, or in their company report. For example, the IKEA vision, values and business idea sets out the organisation’s purpose in the form of:

    • A vision: “To create a better everyday life for the many people”; and
    • A business idea: “to offer a wide range of well-designed, functional home furnishing products at prices so low that as many people as possible will be able to afford them.”

    Strategy

    Strategy supports purpose by providing business ambition and goals – a direction in which to head. Storytelling and visualisation are techniques that can be used to communicate the strategy so that it’s well understood by everyone in the organisation. They can also help others who need to work with them (for example business partners). A useful tool for defining business strategy is the Business Model Canvas, based on the book by Alexander Osterwalder and Yves Pigneur.

    Looking briefly at visualisation, Scott Berinato (@ScottBerinato)’s 2016 article for Harvard Business Review on Visualizations [sic] That Really Work stresses the need to understand the message you want to convey before you get down into the weeds. This blog post is a case in point – I want to show that Enterprise Architecture is much more than just technology. And I found a good visualisation to illustrate my point.

    As for storytelling, I’ve seen some fascinating presentations over the years on how to tell a good story to bring a presentation to life. One of the most memorable was at a Microsoft MVP Event in 2017. Tony Wells used this example of how we tell stories to children – and how we (too) often communicate at work:

    (I’m still practicing my storytelling technique, but Hubspot also has what it calls The Ultimate Guide to Storytelling.)

    What, Who and How

    What we do is a description of the products and services that the organisation offers – the business’ capabilities. These may be the value propositions in the Business Model Canvas but I would suggest they are a little more detailed. Strength/Weakness/Opportunity/Threat (SWOT) analysis can be a useful tool here too for identifying what could be done, though the emphasis is probably more on what is currently done, for now.

    Who we do it for is about the consumers of the organisation’s products and services – understanding who the “users” are. Tools might include stakeholder maps and matrices, empathy maps, personas.

    How it’s done is about understanding the methods and processes that deliver “the what” to “the who”. Journey maps, process flow diagrams, storyboards and SWOT analysis can all help.

    Who does it is about the people, where they are located, and how the organisation is structured. In a world of remote and hybrid working it’s even more relevant to understand the (human) network and how it works.

    Software, data and technology

    Only after we’ve understood “the Business layers” (purpose, strategy and the what, who and how) can we move onto the IT. And that IT is more than just infrastructure:

    • The data models that support this. (There may a discussion to be had there about data, information, knowledge and wisdom but that’s a topic in itself.)
    • The software applications that are used to access that data.
    • And the underlying technology infrastructure.

    Why is this important?

    For many years, I was part of and then managed a team of people who were labelled “Enterprise Architects”. During that time, I argued that the term was aspirational and that most of the work we did was Solution Architecture. Maybe that was splitting hairs but we rarely got the chance to drive strategy, or to get involved in designing the organisational structure. Whilst we were experienced at IT, we still operated at the lower levels in the stack: business requirements driving software, data and technology decisions. We wanted to become trusted advisors, but for the most part, the work we performed for our clients was transactional.

    My colleague Ben Curtis (/in/BenCurti5) has an excellent analogy built around perception and perspective. I hope he won’t mind me borrowing it:

    • Perception is about what meets the eye. Imagine you’re walking through a forest and come across a single tree. Your first impression of that tree – its size, shape, colour, and surroundings – is your perception.
    • Perspective is seeing the Forest and the Trees. Now, let’s say you climb to the top of a hill and look down at the entire forest. Suddenly, you see how all the trees are connected, how the sunlight filters through the leaves, and how animals move through the undergrowth. This bigger view – the perspective – gives you a deeper understanding of the forest as a whole.

    Whilst this can be used to show the difference between an individual system and the complete view of an IT environment, I’d suggest that its also about how the IT environment is part of something much larger – an organisation of people and processes, supported by technology, that exists with a purpose and a strategy to make it happen. And that, is the Enterprise Architecture.

    Related posts

    Here are some posts I’ve written previously on IT architecture. I think this is the first time I’ve properly outlined what Enterprise Architecture means though:

    Featured image: The Enterprise Architecture Stack, by Dave Clark and Sophie Marshall [source: Dave Clark on LinkedIn]

    The symbiotic relationship between engineering and architecture

    This content is 2 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.

    I’m entering a new phase of life as my children are growing up. My eldest son has passed his driving test, and now we’re touring university open days. He’s looking to become an engineer (as was I, before I failed my A levels and fell into computing, but that’s another story).

    Last weekend, we visited the University of Bath, to learn about their Structural and Architectural Engineering course. In his introductory presentation, Senior Lecturer Dr Chris Blenkinsopp was talking about the relationship between engineers and architects, and it really struck a chord with me.

    Dr Blenkinsopp was speaking about engineers as “born problem solvers”. Engineers focus on design – following guidelines and using their problem-solving skills. The architect does the big picture “drawing”, the engineer makes it work. Whilst a computer might be able to solve the maths, the engineer needs an ability to use a range of skills in an imaginative way.

    Successful projects need collaboration between engineers and a variety of stakeholders. Critically, it’s vital that architects and engineers work together closely. And, for that reason, the University of Bath’s Design Projects involve both engineers and architects – collaborating at university as they will in their professional careers.

    Whilst Dr Blenkinsopp was talking about civil/structural engineers and architects who work in the built environment, there are strong parallels with my world of information technology (IT).

    Architects and IT architects

    I have to be careful here, because I’ve been called out previously for calling myself an architect, which is a protected title:

    “The title ‘architect’ is protected by law in the UK, under Section 20 of the Architects Act 1997. It can only be used in business or practice by someone who has had the education, training and experience needed to join the Architects Register and become an architect.”

    [Architects Registration Board]

    But all of that relates to architects who work in the built environment. In IT, architect is a broadly used term – and is recognised in the Skills Framework for the Information Age (SFIA). It’s also part of the job title in my employment contract!

    The relationship between IT engineers and IT architects

    Unfortunately, in IT, the term “architect” is also abused. It’s become common as a term to imply some seniority in the technical space. As a result, it’s lost some of its meaning. Even so, my role as an architect is less and less about technology and more and more about solving business challenges. In the course of that work, I work with lots of subject matter experts – the engineers of the IT world – who solve the problems that I give to them. My role is to draw the big pictures and join everything together. [Often, my tools are some whiteboard pens…]

    Where I work, at risual, we run Consulting Skills Workshops, to help our subject matter experts develop the soft skills that are required to be a successful consultant. In reality, our consultants are on the first step towards IT architecture (whether they know it or not). Consulting is an engagement model and a set of soft skills. In terms of career progression, our consultants are no longer engineers – they are often required to work as technical architects.

    But there is absolutely nothing wrong with being an IT engineer. We need those problem solvers – the people who know how to bring technology together and use it in imaginative ways. Just as much as we need the people who can take those technology building blocks and use them to solve business challenges.

    Conclusion

    As a result of taking my son to Bath and sitting in Dr Blenkinsopp’s presentation, my mission has changed. The work I’m doing at risual to develop and grow our Architecture practice needs to be tweaked. I need a slightly different focus. I still need to create great architects. But I also need to up the emphasis on constant collaboration with great engineers.

    Because, to take a quote from Dr Blenkinsopp’s talk:

    “The best […] engineering solutions require engineers and architects to work together from the outset.”

    Professor Ted Happold

    Additional Reading

    What is IT Architecture? (part 1 of a series I wrote last year)

    Developing IT Architecture Skills (part 2)

    So, you want to be an Infrastructure Architect? (very old, but contains some useful diagrams)

    Featured image: author’s own.

    Weeknote 16/2021: Look after yourself – and watch out for friends and family too…

    This content is 3 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.

    Most importantly, this week:

    • I was reminded not to take family members’ health for granted. Also, that the NHS has many problems but a) is staffed by some truly wonderful people and b) I’m really, really glad it’s there when we need it.
    • I was also reminded that I have some really supportive friends and colleagues. You know who you are. Thank you.

    Lower down the hierarchy of needs:

    • I finally got the (Enterprise) Architecture as a Service service that I’ve wanted to launch off the ground. After years of thinking that it might be useful for clients to have access to someone for a day or two a month, it seems that a couple of days a week is more useful – it’s actually time to do something meaningful. Anyway, it’s given Thom McKiernan (@ThomMcK) an opportunity to go back on site.
    • Related to above, I found I’m a little jealous of colleagues who get to visit clients and interact with humans again. I don’t want it every day – just one or twice a week would be nice.
    • I was frustrated to find that the General Data Protection Regulation (GDPR) is very misunderstood – and all too often given as a reason for not doing something, with no apparent knowledge of what the regulation covers.
    • A client project underlined that, even when using SaaS, you still have to plan for and take action around upcoming changes… such as the upcoming retirement of Microsoft Skype for Business Online.
    • I sold a bike. It felt odd:
    • Related to above, I found that Facebook Marketplace is a strange mixture of nice, normal people, and some very odd individuals who didn’t seem to understand why I wouldn’t accept their low offer when I had plenty of interest at the asking price.
    • My weekend activities were mostly cycling-related: riding in the sunshine; transporting my son to/from an XC MTB race; youth coaching, and marshalling at a road race (where my son was also racing).

    This week in photos

    Weeknote 13/2021: Project progress and procrastination

    This content is 3 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.

    This has been a short week (with only 3 days at work) but I’m pretty pleased with what I achieved in that time:

    • Publishing the Architecture Toolbox I’ve been working on for a few months. That sounds a bit grand for what’s really just a library of re-usable artefacts but, hey! I finally realised that I can’t do everything (perfection is the enemy of good) so it’s time to let it fly and let others contribute…
    • Starting to get under the covers of a new engagement with a local authority client where we’re carrying out some digital service design. It’s fascinating for me to learn from my colleague Richard Quayle (@RichardSQuayle) around concepts like the locus of control, the negatives of a command and control structure (cf. Edward Deming’s approach), failure demand – and much more as we jointly deliver this Business Consulting engagement.
    • A very insightful chat with a client where we’re looking to engage around an Architecture service. It was refreshing to hear that they find TOGAF too conceptual and want to take a more pragmatic approach around EA on a Page (which I referenced in my post on developing IT architecture skills).

    I’ve struggled with procrastination/distraction this week too. The challenges of back to back online meetings are obvious but it seems meetings spaced out through the day can be equally problematic. The challenge is that they leave no time to really get into flow before the next meeting is due.

    Anyway, both of these cartoons resonated with me…

    (in the week that a the MV Ever Given got stuck and closed the Suez Canal, for 6 days.)

    Back in the world of work, Alex (@LyleD4D)’s lateral thinking let me embed an msteams:// link in a SharePoint page, by changing the protocol section of the URI to https://.

    Meanwhile, my colleague Richard Kleiser (@ThatRichK) introduced me to this diagram from Dave Clarke, which attempts to visualise the concept of Enterprise Architecture:

    And that reminds me of something I meant to mention in last week’s weeknote – Rich Goidel (@RichGoidel)’s Strategy vs. Tactics cartoon, which featured in my Microsoft Catalyst pre-sales training:

    I also started to see the direction that motoring is heading in. As electrification reduces revenues from servicing, software will become the next subscription opportunity.

    Although it was probably intended as an April Fool, What Two Figures (WTF) pretty much sums up my feelings about What Three Words.

    Outside work, the UK’s easing of “lockdown” restrictions saw the return to Caveman Conditioning – training outdoors again instead of over Zoom!

    I also completed some online learning around First Aid Essentials in Sport. This is a requirement for my certification as a British Cycling coach but I’ve struggled to complete an approved course during “lockdown”.

    A look ahead to the weekend

    This weekend will see me:

    • Meeting up with another family for a country walk (something we’ve not been able to do for a while!).
    • Returning to Youth Training at my local cycle club (the first time we’ve been able to run a session since I became a coach).
    • Resuming Cyclist’s Dad/Directeur Sportif duties as my eldest son returns to racing.

    It will probably also involve consumption of Easter Eggs (I did buy rather a lot of Creme Eggs this week).

    Talking of Creme Eggs, Natalie Jackson (@NatalieDellar) alerted me to this post with “groovy things to do with Crème Eggs“.

    And next week…

    In addition to celebrating the 49th anniversary of my arrival on this planet, next week will be mostly spent at home including some time doing geeky hobby stuff in the Man Cave. There will also be the final assessment for my First Aid Essentials in Sport certification (which will be interesting over a Zoom call, to which I’ve been asked to bring a pillow and a bandage!).

    This week in photos

    Weeknote 12/2021: IT architecture, design thinking and hybrid work

    This content is 3 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.

    I’ve tried writing weeknotes a few time over the years and they have been pretty sporadic. So, let’s give it another go… this should probably be weeknote 28 (or something like that) but it seems last year I named them after the week number in the year… so let’s try that again.

    Because I haven’t done this for a while, let’s add some bonus notes for last week too…

    Last week:

    This week:

    • I published my long-form blog post on developing IT architecture skills, spun out from conversations with Matt Ballantine (@ballantine70) but also part of the work I’m doing to develop my team at risual.
    • My technical training was interrupted to complete the Microsoft Catalyst pre-sales training. It started off as what I may have described as a “buzzword-filled gamified virtual learning experience”. Then, I started to learn some consulting skills as Rudy Dillenseger brought Design-Led Thinking (aka Design Thinking) to life.
    • It was interesting to see Microsoft recommending the use of Klaxoon with Teams when facilitating remote workshops, which made me speculate about the future of Microsoft Whiteboard.
    • Was a week of virtual calls – even in the evenings. I had Zoom calls with British Cycling and for some financial advice but also a really pleasurable couple of hours on Signal chatting with an old mate I haven’t seen or spoken to in a while, who now lives overseas. It was definitely one of those moments when I appreciated a good friendship and it made me think “we should do this more often”.
    • Just when I thought I’d handed off some project management duties to a real PM, they bounced back at me like a boomerang…
    • The UK Government’s comments on returning to work (ahem, we have been working, just not in the office) reminded me of a post I wrote at the start of the year. Hybrid working is the future folks – we ain’t going back to 2019

    The last couple of weeks’ photos

    Developing IT architecture skills

    This content is 3 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.

    In a recent post, I looked at the topic of IT architecture from the perspective of what it is and why it’s not all about technology. For brevity, I decided to hold off on the next logical step, which developing the associated skills. So now it’s time to revisit the topic.

    What skills does an Architect need?

    In my first post, I made the distinction between Technical, Solution and Enterprise Architects and it’s clear that the skills, experience and knowledge will vary as across roles. There are some common things we can look at though, including:

    • Industry skills frameworks.
    • Formal certifications.
    • Other skills and knowledge.

    It’s quite common to talk about T-shaped individuals, as they grow out of their domain expertise and gain some breadth. An Architect really does need to be more than T-shaped. They need to know a little bit about a lot of things – to be comb-shaped. If it’s not immediately clear what I mean, imagine a comb, with each tooth representing some knowledge on a different topic.

    Skills Framework for the Information Age (SFIA)

    Skills Framework for the Information Age (SFIA) claims to be “the global skills and competency framework for a digital world”. I’m not a fan. In my opinion, it’s overly wordy and feels like it was designed by committee. It’s also true that part of the reason I chose to leave a previous employer was a decision about SFIA grading, so I may be bitter.

    My current employer also uses SFIA, and I can see the advantages when selling into the UK public sector. And I do have to concede that the SFIA skills definitions are actually useful when defining Solution Architect and Enterprise Architect roles:

    It’s interesting that Enterprise and Business Architecture is labelled STPL. Perhaps it was called something like Strategic Planning in the past? That would be very appropriate (although Strategic Planning is labelled ITSP… so who knows).

    There are other skills that may be useful for an architect. Candidates include:

    And, depending on the organisation (e.g. working for a service provider, rather than in-house), maybe Consultancy (CNSL) too.

    But this is where SFIA falls down. It’s so broad and encompassing that we don’t know where to stop: IT Management (ITMG)? Innovation (INOV)? Information Security (SCTY)? We could spend forever assessing people against many skills, but does it really move us forwards?

    What SFIA does though, is provide a reference for what these terms mean and some pointers of what to expect at different levels.

    Digital, Data and Technology (DDaT) Professional Capability Framework

    Because we can never have too many standards, the UK Government came up with another framework for defining roles and the skills that are needed to perform them. That framework is known as DDaT – the Digital, Data and Technology Professional Capability Framework. Unlike, SFIA, DDaT is quite light, but possibly more relevant to the “digital” world.

    DDaT doesn’t define a Solution Architect or an Enterprise Architect. Instead, it further muddies the water by defining various levels of Technical Architect, as well as Data Architect, Network Architect, and Security Architect. It also has a role of Technical Specialist Architect which seems to be some kind of ill-defined catch-all. I would suggest that the DDaT Technical Specialist Architect is some sort of specialist and probably not an Architect!

    The “value” of certifications

    Certifications are not everything, but they can help demonstrate having achieved a certain level of knowledge/experience. It’s worth noting that certifications are important to managed service partners as they are a factor in the partner competencies that a company holds. For some roles, they may also be important at an individual level, but they become less so as we tread the Architect development path.

    Any technical certifications required for an architecture role will depend on context. The team I lead works predominantly with clients who have significant investments in Microsoft technology. For this reason, I ask every Architect (at all levels) to study for and pass all of the Microsoft Fundamentals series of exams.

    At the time of writing there are six exams:

    A seventh exam is in beta:

    Some team members may have other certifications, but this is the base level. If I led an architecture practice working with clients who had a different focus, the list might have been focused on Amazon Web Services (AWS) or another technology stack entirely.

    It’s also helpful to have awareness of competing technologies. In my case, I want the Microsoft-focused Architects to also have a foundational knowledge of AWS. That’s why I became an AWS Certified Cloud Practitioner (CCP).

    But this is where the technical list ends. There is a Microsoft certification named Microsoft Azure Solutions Architect Expert but I consider it to be an oxymoron. It is my experience that the exams that lead to the award of this certification focus too much on detailed knowledge of Azure (the expert part) and have very little to do with architecture. They have breadth and depth within a single domain and in order to maintain the knowledge, it would be necessary to spend a lot of time working with the technology. That is certainly valuable in a technical role but it is not solution architecture (as discussed in my previous post).

    Whilst the BCS has some examples of solution architecture certifications, they require attendance of formal training, which drives up the cost considerably. In fairness, there is a self-study option but it has no published learning path – just a reading list. Aside from these, I’ve struggled to identify good solution architecture certifications (I’m open to suggestions) but there is lots of reading that can be done.

    One such area is around enterprise integration patterns but it’s worth absorbing the contents of the major cloud providers’ Architecture Centers too:

    It’s also worth gaining some experience in other domains – for example, IT Service Management. This is why I have included ITIL Foundation certification on the development path for my team. I’m also considering whether a Business Analysis certification might be worthwhile, as well as knowledge of something like Lean Six Sigma.

    And then there’s knowledge of Enterprise Architecture frameworks. It’s now 9 years since I took my TOGAF exam and I’ve not really had much opportunity to deploy that knowledge. Far more useful has been building out a set of artefacts around Svyatoslav Kotusev (@Kotusev)’s Enterprise Architecture on a Page.

    I was also a Chartered IT Professional (CITP) for a while. Unfortunately, I found that it was not recognised or required by clients and it offered few, if any, benefits. It cost me quite a lot (both to become certified and for the ongoing fees). I couldn’t justify it to myself, so why expect my employer to pay? For that reason, I let it lapse.

    It’s probably clear by now that I have mixed feelings about the value of certification for Architects. It can certainly help in some areas and it can demonstrate some knowledge (literally, getting the badge). But, for a Solution or Enterprise Architect, I’d be more interested to hear about their methods and approaches than the certifications they hold.

    Other skills and knowledge

    Soft skills are critical to success as an Architect and these are wide-ranging. First on the list is excellent written and verbal communication skills. The Architect needs to be able to present confidently, to a wide audience – both technical and non-technical. They need to forge relationships, manage stakeholders and exercise powers of persuasion and influence. They also need to be commercially aware. There’s a really good list of soft skills for architects in this post by Arnon Rotem-gal-oz (@arnonrgo). Arnon’s post is thirteen years old now but seems to have stood the test of time. In it, he outlines six key areas:

    • Leadership: acting as a technical manager for a project, influencing, guiding and directing others (who are often not direct reports) towards the same shared vision.
    • Systems thinking: understanding the “big picture” as well as the interdependence and interactions between components – how they operate independently and as a whole.
    • Strategic thinking: understanding the context that the solution sits within – how it supports the organisation’s goals and meets different stakeholders’ needs – balancing these needs to create a robust solution.
    • Organisational politics: Architects are logical thinkers – their decision making is based on analysing a set of options and picking the best one – except that in any organisation there will be other factors that apply non-rational influences to the decision making processes.
    • Communications: I’ve mentioned this already, but I cannot understate its importance. It’s not just about writing and presenting too – storytelling and negotiation are also key.
    • Human relations: covering team dynamics (how the team behaves at different stages of development), personal dynamics (motivations and personality types) and pragmatism (recognising when to let others have their way).

    When I was writing this, I asked Matt Ballantine @Ballantine70 for his input. Matt reminded me of a post he wrote about CIO traits you won’t see on a job spec: curiosity; humility; and empathy. These are just as relevant to an Architect.

    We need the curiosity to explore new things – not just new technologies but also new ways of doing business. Question why things are done as they are. What if we changed this? Could a new process help there? Could technology replace this manual process? What about our business partners and the way we integrate with them? Do the services we provide meet the needs of our end customers?

    Humility is important too. The point is that the Architect is not an expert. They know a lot and they know how to put the pieces together – or if not, they can work out an approach. But it’s fine to say “I don’t know” sometimes. Actually, say “I don’t know but I have an idea how to find out” – and don’t do it too often. A little humility is good, but not so much that it calls your ability into doubt.

    Empathy is essential. Understand the impact that what you’re doing has on others. Maybe the reason they are resistant to the change you want to implement is that they are concerned about the impact. Try to see things from other perspectives: is there another way to do it? Can we change something to make it more acceptable?

    Back in 2017, I wrote about people change management and the ADKAR model. We need to understand people’s motivations in order to drive successful changes. Take them on a journey and help them to adapt. As Matt says in his post:

    “If you are going to be successful in delivering new things, you have to be able to manage the balance of changing technologies and changing people’s behaviours.”

    Ideal CIO Personality Traits, Matt Ballantine

    Creating a development path

    So I’ve come up with a huge shopping list of skills for our “comb-shaped” Architect and, clearly, they won’t all appear overnight. It may be useful to think about architecture skills in the form of a development path.

    The first thing to understand is where we’re coming from. What skills does the person who wants to be an Architect already possess? Have they got experience in another role that could be relevant – perhaps they’ve already worked in IT Service, or Project Management, or as a Business Analyst?

    Once you know the starting point, look at the target. Define the skills and experience that are needed, identify the gaps, and plan to fill them.

    There’s a common misconception that Architects need to be über-technical but I would say not. At this point I should say this is not my first rodeo. (I have been burned by this point on Twitter in the past). Some people will argue that domain knowledge is needed – and that is true, but not at a deep level. And technology can be learned.

    In my experience, some Architects can find it difficult to extract themselves from technology. Whereas taking someone from a different discipline (such as Business Analysis or Technical Project Management) and training them to understand how the parts fit together can work well.

    What should the development path include? I’d suggest that there should be a mixture of things, but it could be something like this:

    Technical Architect

    A Technical Architect has broad domain knowledge. For example a Software Architect should look to develop an understanding of software development tools, methods and approaches.

    Their experience may expand across multiple industries/market sectors.

    They may have expertise in one technology stack (e.g. Microsoft .NET or Java) but they should be actively looking to increase their breadth and this will necessarily impact their depth of knowledge.

    They should be able to communicate concepts and ideas to technical and non-technical stakeholders in a manner that’s easily understood, and they should understand the impact of their part of the solution on others.

    Solution Architect

    Able to guide the design and development of solutions that meet current and future business needs, eliciting requirements and determining the necessary logical components to create a solution.

    A Solution Architect will take account of relevant architectures, strategies, policies, standards and practices. They will also ensure that existing and planned solution components remain compatible.

    They will have experience across multiple domains and, normally, experience across multiple industries/sectors.

    They will have excellent written and verbal communications skills. They will be able to present complex information, clearly, to both technical and non-technical audiences. They should demonstrate many of the soft skills discussed above.

    They may also have experience of IT Service Management, Business Analysis or another discipline.

    Enterprise Architect

    Able to create and maintain business and enterprise architectures including the key principles, methods and models that describe the organisation’s future state, and that enable its evolution. These architectures support the formation of the constraints, standards and guiding principles necessary to define, assure and govern the evolution, and so facilitate change in the organisation’s structure, business processes, systems and infrastructure in order to achieve a predictable transition to the intended state.

    An Enterprise Architect will interpret business goals and drivers; and translate business strategy and objectives into an “operating model”. This may include: the strategic assessment of current capabilities; the identification of required changes in capabilities; and the description of relationships between people, organisation, service, process, data, information, technology and the external environment.

    An EA will have experience with one or more EA frameworks and will regularly make use of associated artefacts.

    They should have excellent leadership skills, and should be able to inspire people in transforming the organisation to move to the target operating model. They must be comfortable in discussions with the C-Suite. To do this, they will need a complete toolkit of soft skills and the ability to deploy them appropriately.

    In conclusion…

    I hope this (rather long) post has given some insight into some of the skills that may be useful for a career in (IT) architecture and how to develop them.

    Please let me know your thoughts – especially if you know of resources that can be useful to others who are developing skills as an architect.

    Thanks to Matt Ballantine for his help in collecting my thoughts and ideas into something that almost flows (even if it is a bit long for a blog post).

    Featured image by Crisco 1492 from Wikimedia Commons, licenced under a Creative Commons Attribution-Share Alike 4.0 International licence (CC BY-SA 4.0).

    What is IT architecture?

    This content is 3 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.

    I’ve been having a few conversations recently about what IT architecture is – both from the perspective of developing the practice that I run at risual and from conversations with others who are looking to develop an IT architecture capability in their organisations. It’s become abundantly clear to me that the term means different things to different people and is often abused. And that’s without considering that leading figures in construction would argue that IT folks shouldn’t be using the name “Architect” at all!

    To be fair, it seems that even (construction) Architects are arguing over whether someone is an Architect or not. Which is somewhat amusing to me as the collective noun for an architect is… an “argument of Architects”. I kid you not!

    In IT, for some organisations, becoming an Architect has become the term for a senior technical person who understands large chunks of the organisation’s IT. But that’s not what it should be. Architecture is not design. But design is part of architecture. Confused? Bear with me, please.

    Etymology

    Let’s look at the definition of the word “architecture”:

    architecture /???k?t?kt??/ noun

    1. the art or practice of designing and constructing buildings.”schools of architecture and design”

    [e.g.] the style in which a building is designed and constructed, especially with regard to a specific period, place, or culture. “Georgian architecture”.

    2. the complex or carefully designed structure of something. “the chemical architecture of the human brain.

    [e.g.] the conceptual structure and logical organization of a computer or computer-based system.

    Origin: mid 16th century: from Latin architectura, from architectus.

    Oxford Languages

    So there we have it, architecture is about conceptual structures and logical organisation. It is not about detailed design. Ergo, an IT Architect, is not just an experienced technician.

    Unfortunately though, if we look at the definition of an “architect” it all starts to fall apart. The noun for the computing sense of the word is defined as “a person who designs hardware, software, or networking applications and services of a specified type for a business or other organization” and the verb (if you can consider that architecting is really a thing – I don’t!) is “design and configure (a program or system)”. Basically, in computing, we seem to be using architect as a synonym for designer!

    Different types of architect

    Maybe looking at definitions of words was not as helpful as it should have been. So let’s consider the types of Architect we have in the IT world:

    Technical Architect

    Sometimes referred to as a Domain Architect (reflecting that their knowledge relates to a particular area, or domain), the Technical Architect is probably the most common use of the architecture term in IT.

    There may be variations reflecting a given domain – for example Software Architect, Data Architect, Infrastructure Architect, Security Architect.

    Each of these will be able to take a logical building block (see Solution Architect) and define how this part of the solution should be achieved.

    There will be elements of design – but that design should be broader than just technology and will often rely on specialists for expert knowledge.

    Solution Architect

    Solution Architects are concerned with solutions. By that, I mean that they view a problem as a set of requirements that need to be solved by a combination of people, business processes or technology and come up with a solution.

    The solution will be constructed of logical building blocks. For example, a requirement to create a website may include components such as:

    • Identity and access
    • Mobile application/browser
    • Web server
    • Database server
    • Operating system
    • Hardware
    • Network

    Note that none of these are technologies. It doesn’t say Active Directory, Chrome, Apache and MySQL, running on Linux on VMware and with TCP/IP over Ethernet using Cisco switches and routers. Those technical decisions may be taken as to how to address the requirements and fill the building blocks, but the logical blocks themselves are conceptual – not detail!

    The Solution Architect will lead experts and combine their recommendations/experience into a coherent solution to a business problem. They should also consider the whole lifecycle of the solution, from development, into service (operation) and. eventually, retirement.

    This post from CIO Magazine is one view of a Solution Architect, although it could be considered to be describing a little bit of a unicorn…

    Enterprise Architect

    Often, architecture at enterprise scale is mistakenly referred to as Enterprise Architecture (EA) but Enterprise Architecture is a discipline in its own right. A enterprise-scale solution still requires a Solution Architect.

    The Enterprise Architect is (or should be) interested in:

    • Business
    • Data
    • Application systems
    • Technology

    Note that technology is just a small part of that (and last to be listed), although technology is probably pervasive in the others too.

    I’ve read some great posts recently on what an Enterprise Architect is – so instead of re-defining it here, I’ll signpost to these:

    There are recognised EA frameworks, such as TOGAF and the Zacmann Framework but one of the easiest ways to understand the work of an EA is to look at Svyatoslav Kotusev (@Kotusev)’s Enterprise Architecture on a Page.

    Often, the Enterprise Architects are not part of the IT function (but the Technical and Solution Architects are). Instead, the EAs are part of the organisation’s strategic planning function.

    In reality, many people will move up and down this spectrum. Sometimes, a Solution Architect will have to “roll up their sleeves” and help out with a technical situation. Or maybe they will elevate themselves into the some of the Enterprise Architecture role – particularly if there is no formal Enterprise Architecture function within an organisation. But two things are clear in my mind:

    • Architecture is far more than just design.
    • Enterprise Architecture is not the same as architecture-at-enterprise-scale.

    Sitting in ivory towers?

    I’ve seen technical people with disdain for Architects because they consider them to have little practical understanding of their world. Similarly, I’ve seen “Architects” struggle to extract themselves from the mire of technical detail – particularly if that’s what they love to work with.

    It’s important to be mindful of the relevance of the architecture work that’s taking place. Principles are all well and good if they make sense and are followed – but, if the Architects sit in an ivory tower generating paperwork that is of no relevance to the rest of the organisation, they will be doomed to failure. Similarly, we talk a lot about technical debt – sometimes that debt needs to be paid off, and sometimes it’s there for a good reason.

    Perhaps a better way to look at it is this view, from the Enterprise Architecture Professional Journal, in which the author cautions against the argument of Architects becoming an arrogance of Architects.

    Like so many things in the world of work, communication is key. And developing good architecture skills requires good written and verbal communication skills. Then there’s stakeholder management, building relationships, commercial awareness and much more.

    Next time…

    This post is long enough already and the topic of developing skills is pretty involved. So, in my next post, I’ll look at some ways we can develop (IT) architecture skills – and at why there seems to be so little value in (IT) architecture certifications.

    Featured image by Donna Kirby from Pixabay.

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

    This content is 8 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).

    [Amazon’s] Reference architecture for utility computing

    This content is 12 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.

    Earlier this week, I attended an Amazon Web Services (AWS) 101 briefing, delivered by Amazon UK’s Ryan Shuttleworth (@RyanAWS).  Although I’ve been watching the “Journey into the AWS cloud” series of webcasts too, it was a really worthwhile session and, when the videos are released to the web, well worth watching for an introduction to the AWS cloud.

    One thing I particularly appreciate about Ryan’s presentations is that he approaches things from an architectural view. It’s a refreshing change from the evangelists I’ve met at other companies who generally market software by talking about features (maybe even with some design considerations/best practice or coding snippets) but rarely seem to mention reference architectures or architectural patterns.

    During his presentation, Ryan presented a reference architecture for utility computing and, even though this version relates to AWS services, it’s a pretty good model for re-use (in fact, the beauty of such a  reference architecture is that the contents of each box could be swapped out for other components, without affecting the overall approach – maybe I should revisit this post and slot in the Windows Azure components!).

    So, what’s in each of these boxes?

    • AWS global infrastructure: consists of regions to collate facilities, with availability zones that are physically separated, and edge locations (e.g. for content distribution).
    • Networking: Amazon provides Direct Connect (dedicated connection to AWS cloud) to integrate with existing assets over VPN Connections and Virtual Private Clouds (your own slice of networking inside EC2), together with Route 53 (a highly available and scalable global DNS service).
    • Compute: Amazon’s Elastic Compute Cloud (EC2) allows for the creation of instances (Linux or Windows) to use as you like, based on a range of instance types, with different pricing – to scale up and down, even auto-scalingElastic Load Balancing  allows the distribution of EC2 workloads across instances in multiple availability zones.
    • Storage: Simple Storage Service (S3) is the main storage service (Dropbox, Spotify and others runs in this) – designed for write once read many applications.  Elastic Block Store (EBS) can be used to provide persistent storage behind an EC2 instance (e.g. boot volume) and supports snapshotting, replicated within an availability zone (so no need to RAID). There’s also Glacier for long term archival of data, AWS Import/Export for bulk uploads/downloads to/from AWS and the AWS Storage Gateway to connect on-premises and cloud-based storage.
    • Databases: Amazon’s Relational Database Service (RDS) provides database as a service capabilities (MySQL, Oracle, or Microsoft SQL Server). There’s also DynamoDB – a provisioned throughput NoSQL database for fast, predictable performance (fully distributed and fault tolerant) and SimpleDB for smaller NoSQL datasets.
    • Application services: Simple Queue Service (SQS) for reliable, scalable, messages queuing for application decoupling); Simple Workflow Service (SWF) to coordinate processing steps across applications and to integrate AWS and non-AWS resources, to manage distributed states in complex systems; CloudSearch – an elastic search engine based on Amazon’s A9 technology to provide auto-scaling and a sophisticated feature set (equivalent to SOLR); CloudFront for a worldwide content delivery network (CDN), to easily distribute content to end users with a single DNS CNAME.
    • Deployment and admin: Elastic Beanstalk allows one click deployment from Eclipse, Visual Studio and Git  for rapid deployment of applications with all AWS resources auto-created; CloudFormation is a scripting framework for AWS resource creation that automates stack creation in a repeatable way. There’s also Identity and Access Management (IAM), software development kits, Simple Email Service (SES), Simple Notification Service (SNS), ElastiCache, Elastic MapReduce, and  the CloudWatch monitoring framework.

    I suppose if I were to re-draw Ryan’s reference architecture, I’d include support (AWS Support) as well some payment/billing services (after all, this doesn’t come for free) and the AWS Marketplace to find and start using software applications on the AWS cloud.

    One more point: security and compliance (security and service management are not shown as they are effectively layers that run through all of the components in the architecture) – if you implement this model in the cloud, who is responsible? Well, if you contract with Amazon, they are responsible for the AWS global infrastructure and foundation services (compute, storage, database, networking). Everything on top of that (the customisable parts) are up to the customer to secure.  Other providers may take a different approach.