We recently launched our new network inventory system (temporary nickname – “UNI”), which the team has been working very hard to develop over the last few months.

This document is a high-level summary of the development project, from the point where we started (ideation) to where we are today (operation).

Since we didn’t follow any official project management method, the steps described below were sometimes messy and incomplete. I hope this document will become useful the next time around, as we adopt a more traditional approach to new system and project deliveries:

• At step Zero we decided the system will be homegrown. The main reason was that due to the nature of our network, our needs were quite unique and we couldn’t identify anything ‘off the shelf’ that would not require major adaptations or modifications. We opted for PHP & MySQL for the development, because of its ease of use, web browser interface, and the pre-available knowledge within the project team.
• We started off my identifying the purpose and defining requirements: we conducted a requirements analysis by talking to people from all departments, operations, engineering, IT and Support. We listed the current pain points and specific functionalities and features that all potential users were bringing up, type of reporting they would want to see, desired integration with other systems they used, etc..
• Based on the list of requirements, we started building the database schema (this will be repeated and modified quite a lot later on, but that’s a whole article in itself). We created the tables, defining things like data types and indexing, categories, locations, transactions, users, vlans, etc., and created all the relationships between them to try and achieve effective store and retrieve.
• We then started planning the look and feel of the application, by designing the different user interface screens. What should the layout of each screen look like, what functionality should be available for the user, where may users need to add, edit, delete, search or filter records, produce reports or specific analysis. We built a complete mockup of all the applications’ screen before starting to write code, making sure that the UI is as user friendly and functional as we can get it to be.
• At that point we finally started coding. First building the core functionalities, then building separate functions and classes for different tasks (adding, updating, etc.), we built basic reports to help understand trends, however at a later stage we incorporated into our code 3^rd party reporting capabilities, which made the reports much more meaningful (and look a lot more professional). This is definitely one of the features of the system that the users (and us!) like the most.
• Now, when we had an almost fully programmed application, there came a giant scope creep – a request from the network engineering team to integrate between some of their network discovery tools and procedures with our own system, in a way which will ensure that the system is updated automatically when changes are performed on the production network. This required quite a lot of work and learning how to get (mainly) SNMP info into the system in real-time – things like device details, interface status, IP addresses, etc.).
• When development of the functional parts were nearly done, we started working on the user management system, where we made sure that every type of users gets all the information they need – and not less importantly – only the information they need. We integrated user authentication and access control functions, defined user roles, and created some security measures to prevent business critical data from reaching the wrong hands.
• Throughout the long development period we performed regular (unit) testing, and at some point, built a sample data base with dummy data (‘stubs’) to simulate real-life scenarios. Everything was tested and debugged rigorously to ensure accurate data retrieval and stability.
• When everything was ready, we built a new server in the prod network, where we host the new application and database. The reason we chose prod is that this server is now protected by the highest security means used in our production – SSL, firewalls, LB’s, and enjoys a regular assessment to ensure high availability and scalability.
• At that point we were ready to start introducing the system to users. With very short time left we created the best user documentation we could (the code is a little better documented than the user manual…), created training materials and conducted user training to the different departments. The training sessions were great, and provided a lot of feedback which is already going into our backlog to be included in the next versions.
• We are now in the early days of production. Our logs show dozens of entries to the system a day, hundreds of records were already updated, and these numbers are increasing daily. After 4 days we already released an update with a couple of bug fixes reported by users. We have tons of more functionality that we plan to develop, and about a million new ideas for future improvements. It was a long and bumpy ride, but definitely one worth taking!