Friday, October 12, 2018

Proper Documentation REQUIRED!

IT is my life.  I have been in the field of IT since 1989, some 29 years (25 of which have been paid engagements/jobs).  My first computer was a Macintosh SE with dual floppy drives - no hard drive and 1MB of RAM.

Recently, I took over the entire IT organization at my company (Virtual Instruments) and while my IT strengths lie within Infrastructure (the servers, routers, switches, laptops, etc.), I am rapidly adapting my expertise towards managing the Application side of our business.  Here is a bit about that journey.

From Nothing, Order, Chaos and then Order again

I have been employed by Virtual Instruments since 2009.  While on paper, I am employee 76 - I am of but one of a handful that has been around since the beginning of the company to now.  All of my time was devoted to the Infrastructure side of the organization.  While our applications division work was acceptable in the past, it was not exceptional.   There was a period of time when we had a Director of Apps (Anne Riotoc) and she was awesome!  She had the requisite skills to manage the department and projects.  You knew where you stood with Anne and I cannot speak enough good words about her performance and professionalism.  Unfortunately, she left in 2015 and the lack of back-filling this position created a vacuum that created chaos and the 'wild west' attitude within our APPS division.   Our Apps department managed as best as they could, but with little oversight and too many tasks and not enough time.  From late 2015 to early 2018, they existed in mostly a fire-fighting mode.  The dark ages.  Lots of changes where made to systems, but almost zero documentation.  I took over in 2018 and my goal was to bring stability and industry best practices to help bring light to a department that was covered in shadows.  This also meant a fair amount of reverse engineering had to be done. 

We use an ERP system that has no direct integration with our CRM or warehouse system.  To get around this, we have to use middle-ware like BOOMI from Dell to offload the heaving lifting of orders from our CRM to our ERP and warehouse systems.  The issue I have run into multiple times is trying to understand what exactly the programmer was attempting to accomplish by his Boomi workflows (processes).  Some are straight forward and make perfect sense.  Some have multiple forked workflows that seem to be a meandering mess and at times, party incoherent.

There is nothing like staring at code and asking yourself, "What was this person trying to do here?".

How can we fix this?  I decided to employ what I knew from years of my IT experience to my Apps department.

An ITIL junkie!

Did I mention... I like ITIL?

What I have to say that I live and die by is this:  "There is no reason why a person in IT should forego the proper documentation".  Especially when excercising within the correct industry standard framework like ITIL or COBIT.  What is ITIL?  What are the stages:
  1. ITIL SERVICE STRATEGY - or, How to align IT DEPT activities with that of the core business
  2. ITIL SERVICE DESIGN - design & adapt services that support the business
  3. ITIL SERVICE TRANSITION - transition of service/system  through change management, testing and knowledge training on new system
  4. ITIL SERVICE OPERATION - Event and Incident Management in a nutshell
  5. ITIL CONTINUAL SERVICE IMPROVEMENT - identify and implement strategies to improve or provide better service in the future
Employing something like ITIL/COBIT towards a set of system/services won't allow for you to work without documenting things. 

The fluidity of my predecessors project skills, sans any IT framework, allowed critical details to be lost once the project was completed.  There was no documentation and almost no notes.  Forget understanding what logic went behind decision making.  Anyway - my point is that while our systems are stable and working, there has been a general lack of documentation as to the intent of the originating programmer(s) who have been developing things over the past.  Couple this poor documentation with poor architectural design and this brings about a system of operations that are more difficult to manage than they should be.

Following the framework while working on a new system, will assist in bringing clarity to the project.  While this article cannot dive into the specifics of ITIL, step-by-step, just know that using an industry standard framework like ITIL or COBIT will benefit your organization - greatly.  No IT team is too small to start adhering to the practices - a team as little as 2-5 people... can see benefits. There is a method in the madness of ITIL.  There is a reason it works. 

You can find general details about ITIL here:

While ITIL offered the framework to implement a system/service, it wasn't the only thing we required.  We needed a way to bring together our thoughts and ideas and document all that we were accomplishing through our processes.  This brings me to our tools...

New Tools

In order to give more clarity to our application systems/services, we started employing several new tools to assist:
  • Atlassian Confluence - cannot say enough about Atlassian. They have some remarkable tools and of all the WIKI like systems, I found that Atlassian is phenomenal.  Love the interface and ease of use - my users cannot be hampered by a tool when I am asking them to be agile in their thinking and analysis - the tool cannot get in the way
  • Jira or other HelpDesk - while we were already using a helpdesk system, I wanted to mention that you need to track issues/problems - No reason why there shouldn't be an incident or request tracking system.  Every IT team should have one - it is necessary for day-to-day operations and metrics
  • Github- storing source code or items within a repository is another way of not only documenting, but capturing versioning details - Github is an industry standard that is also a very wise tool to implement - while my infrastructure team doesn't use github, this is invaluable for an application team.
  • Monday.COM - while not really a tool for documentation, it is a good way to give clarity to multi-faceted projects.  My infrastructure team uses this for large scale moves of data center racks with a lot of moving parts and communication
  • SLACK - great tool for communication and collaboration

Rebuilding and Scaling

Today, given our new tools and mission statement, we are more visible and accessible to the organization.  We are doing more with a skilled and agile team and using contractors when required to fill technical gaps we might have.  More importantly, we are peeling back the onion layers on our systems and services that previously were black holes of data consumption.  

I am the virtual TOTO exposing the wizard behind the curtain.  

No comments:

Post a Comment