Alt+Ctrl+Start

Google ‘IT architecture diagram’ and click images. There’s alot of images with boxes, lines, diagrams, devices etc? You see something like this below

There’s alot to unpack here. You may have studied some project management course or subject that shows you how to draw these diagrams, but we’re you taught how to interpret and question how these diagrams flow? Imagine you we’re given a picture of the car and asked to describe the engine, transmission, brake system and electrical wiring of the car. Unless you saw a cross section of the car it would be pretty difficult. Right?

Being presented with an IT architectural diagram like the one’s above is exactly the same scenario as the describing the car’s inner systems.

When being presented the following diagrams these are the immediate questions I have. I have structured the questions to make sense and keep it presentable.

• 5W’s and How
  • What do these systems do?
    • What are the specific functions and features
  • Who looks after these systems?
    • Is there a global operations team that can log tickets to the various L1, L2, L3 teams?
    • Do the L1-L3 teams know how to look after these systems
  • Why are these systems needed?
  • Where are these systems located?
    • Based on the diagrams above, various systems will be hosted differently. E.g. On Premises, Cloud, Hybrid etc
  • When are these systems available and not available?
    • These systems will need to be taken offline time to time for patching, upgrading, releasing new apps and features
    • Is there a schedule for the availability for these systems
      • Does everyone know about this schedule?
        • Historically in my time in the workforce, communication to all stakeholders on taking systems offline, some people and teams get missed
  • How are these systems supported?
    • How are issues escalated to the teams that look after these systems
      • Do we log tickets to report issues, is a communication line to follow etc
    • Is there a checklist of things to check when these systems are offline, having issues, not working

• Connectivity, networks, resilience
  • This section here is probably one of the most important in my blog
    • Your work will require to support apps and systems that connect to other external apps and systems. But these external apps and systems are not your my domain.
    • It’s important to at least know if your app/system is connecting to an external app/system, to understand a little bit of that other external app/system.
      • Later I will cover in another blog post my 10% rule.
  • When supporting a single system the team might be small, but when you’re supporting multiple systems, teams are bigger and there are multiple responsibilities
    • Do you know who these users are that will be supporting you and these systems.
      • I would ask these people their skills are, and what they are comfortable supporting.
      • Some of these people will have gaps in their skills and maybe not be in a position or comfortable performing tasks. This includes you.
        • You might need to ask the manager to find users to support you and the system
        • You’re not expected to handle all the support work
      • Are there procedures and documentation on supporting these systems (if so where are they and how does one access them)?… Probably not 🙂
  • If/when there is a failure between systems do you know what to look out for?
    • Do you know how your traffic reaches end to end?
    • If your traffic passes another system, do you know what to ask the other team to look for in that other system?
    • Do you have troubleshooting techniques
      • E.g. Perform basic networking commands like nslookup, traceroute/tracert, ping etc to validate
    • Do you have the proof where the failure is occurring?

Summary:

• I covered a bit above regarding interpreting ‘IT architecture diagram’
  • Trust me when I tell you this, you’re not expected by anyone (even snr leaders) to learn complex diagrams like the one mentioned above.
    • However as a learning upskilling piece, you should try to endeavour to be the best ‘Subject Matter Expert’ (SME)
      • This is not mandatory, but demonstrating being an effective SME will be rewarding, not just in your career, but financially as well.
• The above only covers a small part of ‘IT architecture diagrams’. There is probably more topics to cover. Later I may revisit and evaluate further on more topics on supporting and understanding complex IT architecture.
• The main take away from this post, is to make sure you have some idea who supports each system, get to know their names, teams and the skill set they have to support these systems.