You can never connect the dots unless you know what the dots are
I’ve worked in the IT industry for 30 years. Sounds like a long time now that I say it, just about half the time in NZ and half the time in the UK, including 8 years with IBM. I’ve always worked through a supplier or as a contractor to customers so I’ve never actually worked directly for a company that did anything apart from supply IT solutions (other than a bar job I once had.) That probably makes me a geek or a nerd to non-technical people. I’ve just looked up both and I prefer geek as historically a geek was a circus person in the sideshow who performed some bizarre feat. That’s what I hope to do with Hubscope. If it fails feel free to call me a nerd, which generally seems to mean a technically bright but socially inept person … I take either as a compliment.
So, over the years I’ve been involved with many projects across many industries, starting initially with small companies using simple packaged solutions but soon finding myself working on large projects for customers needing complex engagement, build and delivery approaches. Working for IBM really helped me gain experience in structured methodologies. But as projects got more complex my personal way of dealing with this complexity was universal; Sketch out and share a series of diagrams so that everyone knew what was required and how we were going to build it. Less words, more visuals. I became a PowerPoint nerd and Visio geek.
Shift the focus
Those of you who are the first to stand up in meetings to grab the whiteboard markers will relate to the joy that creating a simple diagram brings. A shift quickly happens as the focus moves to the board rather than discussions and disagreements between individuals. I’m always surprised how few people want to step forward to doodle things out, or how relieved people are when someone stands up. There was still a problem though, as no matter how good these initial diagrams were (and the subsequent refined versions in visio/powerpoint), they quickly lost their currency. The game became one of keeping them up to date, this is really quite a thankless task and to be honest not really where the fun is. Plus the longer a diagram remains unchanged the larger the reality gap becomes. Our ever increasing rate of change only exaggerates this.
I have dabbled with highly structured modelling tools but they tend to polarize the audience into people who get the notation and people who don’t. For those who get the notation there seems to be a further split between those who want to invest the time in learning the modelling tool and those who don’t. The value of a white board diagram is that there is no mandated notation so everyone can join in and draw anything, although I was once told off for mixing a physical architecture diagram with a logical one – shame on me but we live in a world of imperfections.
Everything relates to everything else
One day it struck me, everything on the project relates in some small or large way to everything else: stakeholders, requirements, technology. My diagrams were simply representing things and relationships in a way people can recognise and value them in a way words alone cannot, unless you have a photographic memory. It’s really not the notation in which the diagram is drawn that matters the most but the connections. If you pull one thing then the unseen threads between it and other things will cause a reaction. Direct relationships cause the most affect but indirectly effects are also important. If you change one and can’t see the threads that effect other the impact will still occur but may not be associated with the cause. The seed was planted. As my frustration with existing tools continued over the years so the idea of having an interactive, dynamic and searchable diagramming tool began to grow. With this new insight it was clearer to seek out and understand how the project’s pieces relate to each other, and that you can’t change one thing without affecting another.
Relationships exist between just about everything and they change all the time, which is why a static diagram is pretty much out of date as soon as it’s drawn because the underlying ‘data’ changes. Turning the requirement to extract data from a diagram on its head a little, why not create a diagram from trusted data? This opened up a whole new way of thinking about things.
The main problems with diagramming tools are in the absence of any automated layout handling and their tendency to over emphasize the use of a specific and often over complex notation. All the tools I’ve seen which do auto-layout never quite draw the diagram as I would have done myself. They all allow manual placement but this then gets incredibly time consuming as you fiddle with lining up boxes, moving things around and generally making the thing look presentable. This is especially hard when a change is needed. Ask yourself how much wasted time in your life have you spent lining up boxes and moving lines so they don’t cross over each other. Life is too short, so unless you have a compulsion disorder my suggestion is to let the technology do this part for us.
I’d like to come back to structure and the idea that there needs to be just enough but not too much. For the first iteration of Hubscope, I suggest the types below. For some of you this may be too few but my goal is to have a simple model that everyone can understand, so let’s start here:
- Who? Stakeholders (People and Units)
- Why? Requirements
- How? Services
- What? Technology (Software, Data and Hardware)
As well as the above node types, there are also relationship types. Relationships are the key here as they highlight those all-important inter-dependencies. Logically, almost any relationship is possible between these different kinds of nodes but here are the relationships that are typically important:
- Unit <> People <> Requirement
- Requirement <> Service
- Service <> Data
- Service <> Software
- Data <> Software
- Data <> Hardware
- Software <> Hardware
Hubscope allows you to draw any kind of relationship but note that we don’t need to capture all nodes and relationships, only the really important ones. Of course, the trick becomes how to decide what’s important and what’s not and we’ll revisit this in another blog post.
The header image, connect the dots, was created by amanda kelso and is licensed under a Creative Commons Attribution-ShareAlike 2.0 International License.
And if you liked this post, please share it with your pals using the buttons on the left …