As always, here’s the standard disclaimer. This article, as with all in this series, is based upon personal experiences and from experiences of others I have spoken to. What I write here is my opinion and my personal thoughts regarding how to get the best out of each of the project phases – none of it is reflective of the views of my employer.
I should also make very clear that any people I write about here are not real but are fictitious composites made up of conversations that we’ve all had, with characters we can all relate to.
Hello? Is there anybody there? I can’t actually tell as the mountain of paperwork that has landed on my desk is blocking my view of everything (not that there is much to see) and has caused the simple act of retrieving my coffee to become an exercise in contortionism.
Yes, I have now received not only the “Final” version of the ProSpecT (Project Specification Talk) document (which will of course be completely different by the time we conclude this project) but I have also received the output from all the WORKSHOP (Working Out Required Knowledge Solutions, Holistically Observing Possibilities) sessions.
Hmmm, three sets of brackets in one sentence – I think I may be entering some form of combination of The Matrix and Inception.
Needless to say, the WORKSHOP output is full of very pretty diagrams in lots of bright colours, but with very little in the way of actual substance. I always find it interesting that those with little to say can produce the largest documents.
Along with the joys of trying to find the useful information in the mounds of paperwork, I have also had the joy of spending time with Sven the Swedish Systems Structural Specialist.
Sven is your very typical pastiche of an architect (which is what he is, it’s just the powers that be liked the alliteration of 5 S’s) – he wears black turtlenecks, thin-rimmed glasses, looks just like Steve Jobs, and drives a very nice SAAB 93 drop top. He also has the tendency of assuming that he knows all and therefore what he speaks must come into being.
The meetings with Sven, in a stylish and minimalist office, of course, were to formalise the overall structural specifications for the system and subsequent supporting structures and supplementary storage silos.
OK, now I know I’m in the IncepMatrix – there were far too many S’s in that last sentence!
Talking to Sven is an odd exercise. He is very much a man of the same era as his car, loves Visual Basic 6 and Microsoft Access and believes that there is no need for anything beyond Windows 95. He even runs a Novell network at home!! (Remember them???)
This means that his perspective on the “Methods Exercised Applying Technology to the Business Application Logistical LayerS” (MEATBALLS) tends to be challenging when you are trying to introduce a platform that changes more frequently than the presenters on Top Gear!
After trying to explain to him “The Cloud” and then “Continuous Updates”, I think his poor mind was frozen to the point of being positively glacial (except they move faster!)
Of course, designing the core platform wasn’t enough as we just have to integrate with every system that we have here, including the canteen vending machine because “it’s vital data about the employees” – they even want us to integrate with the 50-year-old mainframe that gets powered up once in a decade just so that the legacy IT staffers can get all misty-eyed and retrospective.
Cue lots of talk about protocols, handshakes, security layers, frequencies, priorities and more. By the end of it, I really wasn’t sure which one of us was the most confused.
Eventually, we got to a point where his nice diagrams were sufficiently detailed, and yet also adequately vague, enough for us to be able to build a new platform if we took a very… erm…. loose interpretation of what was produced.
Now if you’ll excuse me I think I need to go somewhere with no IKEA furniture and where I can enjoy a beverage or two in the vain hopes that I might regain my sanity before I face the wonderful world of Licensing with Limahl (not that one!)
A personal disclaimer here – I’m only representing my experience, understanding and thinking when it comes to the architecture design phase. It’s highly probable that your company does things differently, but hopefully there is still some use in what’s written here!
Ah, Architecture. No longer confined to the wonders of Skyscrapers, Bridges and the latest trends in Grand Designs.
For a developer, this can feel a bit of a frustrating phase as the desire to simply “get on with it” when you get the green light for a project is almost primal.
It can also feel somewhat redundant when you are simply deploying a platform to the cloud, there’s a box for user and box for the cloud… job done. Except it’s not just about that.
Although it can feel like a challenge to go through this phase, it is vital that a decent a proper architecture design is complete and that it incorporates all the details relevant to user access and any data integrations.
Much as developers, and most in IT circles, hate documentation this is an area that can come back to haunt you if you don’t get this right – and even more so if you are dealing with disparate teams who you are depending on such as the Networks Teams (Firewalls etc), Systems Administrators (Group Policies and the like), Information Security, Support teams and so on.
The key is ensuring that the documentation is COMPLETE. Any vague grey areas when the document is produced can easily come back and bite you later on in the project, and cause long delays if you’re not careful!
It may be that as a developer you’re not involved in the Architecture phase at all, but I would recommend being involved if you can and paying close attention to the detail.
It’s also crucial that the resultant design is flexible enough to allow for improvements in technology, such as security protocols or access methods, and doesn’t limit the scope for innovation and future development. Some of this will inevitably require revisions to the design that is drawn up, but the original document should ideally be done in a way that still allows for rapid change and improvement.
At the end of the day, the Microsoft Cloud is exactly that – it’s MICROSOFT’s cloud, not yours. It will, and does, change on a very regular basis and this change is not always documented or communicated.
This is all going to happen whether your architecture document allows for it or not, so it’s better to ensure that this evolutionary nature is part of the design right at the beginning that to try and shoehorn it into your design later on down the road.