Information Technology Services (ITS)
Diagrams and Models
Published on: March 28, 2017
By: Frank Boshoff
I sometimes get the impression (quite often really) that too many people consider IT architecture to be the production of pretty diagrams. And since most architects do pretty diagrams really well, if a diagram is deemed necessary or useful to help visualize a problem, get an architect and tell him/her what he/she should draw…and tell him/her to make it pretty.
These people miss the point entirely. Everyone involved in figuring out an IT solution should try doing a diagram – not just one, but several. Each diagram should have different levels of detail. Some of the diagrams should represent different views of the same solution – these diagrams may highlight a particular aspect of a solution, while omitting details of other aspects – all the better for people to focus on particular concerns they have.
As an IT team member, the very act of doing the diagrams helps you to understand the solution better – the diagrams identify what questions you need to ask to understand exactly what the requirements are. You do the diagrams for yourself first, then use the diagrams to explain the solution to others, which elicits feedback, which improves the diagrams, the solution, and user satisfaction.
Diagramming, or modelling, is a prevalent activity in most engineering disciplines but seems to be optional in too many IT projects. This could partly be because the non-IT people who require the IT solution simply trust the IT people to deliver the right solution, but this is actually an abdication of responsibility from the business people to the IT people. We are all becoming increasingly dependent on IT and it is increasingly becoming everybody’s responsibility.
If you were contracting a team of builders to build you a house, you’d want to see the plans and some artistic renderings of the finished product to help you determine that you’re getting what you expect, and what you’re paying for. Even if you’re not a contractor, engineer, or an architect, the diagrams and models presented to you – before you pay for the building – should be self explanatory to a certain extent, and any questions you have should be competently (and courteously) answered. The diagrams help you formulate questions and the answers usually improve the final result.
If you’re a business user of IT, and especially if you’re accountable for business results or compliance processes (e.g. finances or FIPPA) supported by IT systems, ask to see the diagrams and have them explained to you. I suspect you’ll be surprised at the outcome.