Final report for "Redevelop School Inventory System" - Project 269

Aim of project

The aim of this project was to replace the inventory system introduced in 2008. This inventory system not only recorded information on the School's equipment assets, such as allocation, location, description, serial number, but also information on the related purchase orders.

The 2008 system was a hybrid of the old DAI and DCS systems. Whilst it introduced some good features, eg location discovery from switch reports, it did not cater well for the growing estate of self-managed devices. It was not bug free, with the implementation of the "business logic" in the client and the lack of transactional support being particular weaknesses.

Review of alternatives

A brief review of alternative inventory systems (also known as asset management systems) was carried out early in this project. At the time, the only commonly deployed open source system was OCS Inventory. An instance of OCS was stood up and experimented with. However OCS, at that time, had no support for order information nor support for non systems (eg monitors, disk drives etc). It primarily focused on inventorising running systems via reports from client based agents. Whilst OCS could possibly have been modified to suit our requirements, doing so was considered more a risk than developing our on in-house system.

What was delivered

The replacement inventory system, Tartarus, went live in May 2018. Tartarus, as did the previous system, records both information on assets and purchase orders. The majority of the "business logic" is implemented in a REST API (GSSAPI authenticated) which improves integrity and permits computing staff to write their own tools to query, or update, the inventory. The primitive 'clientreport' mechanism of the previous system has been replaced by an easily extensible modular JSON report (again GSSAPI authenticated) - this has proven to be particularly useful and is used as the basis for many monitoring reports.

Whilst the schema for the 2008 inventory system had support for "associated parts", this support did not extend to the toolset. Tartarus has the concept of systems (eg servers, desktops, printers etc) and non-systems (everything else). Multiple non-systems can be associated with a system - for example, you can associate a GPU card with a desktop. KVM guests can also be associated with a system, making it easy to see which guests are hosted on a KVM host - the 'kvmtool' automatically registers KVM guests with Tartarus (and detects migrations from one KVM host to another).

Development

Development, particularly design, was discussed on a weekly basis at MPU meetings. These discussions were very useful for bouncing ideas off colleagues, receiving even better ideas from colleagues(!) and clarifying one's thoughts. There was some limited code review, particularly of the API and web configuration, leading to some minor code improvement.

Follow on

Possibilities for follow-on work are :-

  • Skinning the web interface
  • Producing additional clientreport modules - but anybody can produce these.
  • Integration with any University asset management system introduced as part of the Service Excellence Programme.

Effort

Period Hours
2015 T1 67
2015 T2 138
2015 T3 109
2016 T1 84
2016 T2 187
2016 T3 102
2017 T1 126
2017 T2 177
2017 T3 90
2018 T1 61
2018 T2 67
2018 T3 31
2019 T1 74
2019 T2 25
2019 T3 26
Total 1364

A total of 39 weeks!

Lessons Learnt

This project consumed an inordinate amount of effort (39 weeks) over a long time period (close to 5 years). Whilst the reasons for this are probably many, it is likely that the primary reason was the bursty nature of the available effort of the developer (the Head of Computing). Much time was wasted on "getting back up to speed". Arguably, if it had not been for the Bayes build project (which had to take priority over this project), the project would have been delivered and completed in 2017.

In future, it may be wise to only allocate, to the Head of Computing, those development projects which have a well defined (preferably externally driven) deadline.

-- AlastairScobie - 25 Sep 2019

Topic revision: r10 - 05 Feb 2020 - 15:22:11 - AlastairScobie
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies