Systems architecture 101 and what you can’t ignore when developing a new business application
Having completed my induction at Saffron as the IT Technician/Developer intern, I had a feeling of accomplishment. It can be overwhelming when multiple systems are thrown at you. However, the implementation model we’ve got in place makes new starters feel at ease. Shortly after completing my induction, I was thrust into developing an internal ERP system that the company will use on a day to day basis.
This complex platform will be a way of streamlining processes that are currently in place at Saffron. It will make completing admin tasks easier and less time consuming for people at Saffron. This ERP will act as a platform to integrate our external suppliers seamlessly, allowing us to monitor the business and circumvent some business procedures that were set in place before this system. It will streamline different admin and project tracking systems and unify the processes that these systems perform into a single ERP platform. The basic principles of what I’ve learnt at University with regard to design processes were being fused together as I was ‘cutting the ribbon’ to embark on my internship at Saffron. The design process is composed of the following sequential phases that I followed during the implementation of this new system:
Gather the requirements, ALL the requirements
I began laying out the requirements of the client, (in this case, Saffron). Along with my mentor in the IT team, we arranged a set of questions for the staff that predominantly use and administrate the system we’re replacing. We asked the following questions to gain a greater understanding of the specification:
- Where will this system be used?
- Who will use this system?
- What features are essential?
- What features will need to be replicated from the existing system?
Answering these questions enabled developers to see whether requirements could be met. We then got back to the client to let them know whether we could meet these requirements, and outlined how to implement those features.
User experience design: Make sure it looks like something YOU would want to use
This is the stage where a designer and developer can demonstrate their creativity to the client and the client can give feedback accordingly. During the design stage, we delved into the client’s requirements and determined how they would be implemented in the new system. It’s essential to interact with them whenever there is an ambiguity in a requirement at this stage of the model. As the new ERP system combines a legacy system for managing invoices with the currently separate resourcing and time management processes, there is much about what it does which is new for end users. This makes intuitive UX design all the more important and leads to our next point…
Implementation: Innovate but don’t alienate
Once the design is verified and approved by the client, implementation begins. Each requirement is analysed by the developers and these are then added into a Process Document Report and then assessed by each person working on the project. It’s essential that even though the design has been completed, the client’s needs are looked at with an even broader perspective than before. This is especially the case when you are replacing an internal system for the workplace that is going to be used by the organisation on a day to day basis. For example, when implementing an integral feature from the old system, it is essential that the newer iteration performs its duties with the promised improvements over the original, but doesn’t feel too alien to the user. The system needs to be accessible, familiar and preferably more intuitive than the old one. A user of the old system should not be burdened with a tumultuous task of transitioning into the newer environment.
Verification: Release your system into the wild, wait and see
Upon reaching the verification process, the system has been fully implemented and QA has been completed. Here, the client will assess the system to monitor whether it meets all the agreed requirements. We are currently implementing the ERP system, and the efficacy of how the system is devised and implemented will play a big impact in minimising the changes required. With regard to the ‘Agile Project Management’ concept, we have to be in direct co-ordination with the client, remaining in close contact means that much verification will not be needed. This way, if the client notices something that isn’t quite right, the issue can be rectified before reaching this stage.
Maintenance: They think it’s all over…
As we are implementing the system, we haven’t yet reached this stage of the model. However, due to the solid infrastructure we’ve built in the previous levels of this model, software bugs will be ironed out as effectively as possible. Despite this, development will never truly end. Systems will always need maintenance (server or client side) and work will be needed if any bugs arise. In the case of this particular system, maintenance will be handled by the internal development team at Saffron. We know that effective documentation during the design and implementation stages can make maintenance more straightforward. We’ve been keeping a log for each aspect of the system we conduct. Communication and information-sharing is key to ensure a smooth transition.
Training: “Share your knowledge. It is a way to achieve immortality” – Dalai Lama XIV
Do you, as a developer, want to achieve immortality? Then train! Jokes apart, after having dug into the numerous systems that Saffron uses during my induction period, I came out of the four weeks with a working understand of all of them. This is only because Saffron provides a training scheme for each system, these comprise of:
- An introduction to each system given by an experienced person
- Comprehensive, detailed training for each system
- Documentation that can be accessed easily
It is imperative that the above is provided before the system is unleashed into the workplace. One of Saffron’s strengths is systems training and when the ERP package is rolled into the Saffron workplace, it will be essential that everyone knows what to do and the benefits of doing so. I’ll be involved with training staff and how the system will be beneficial to them and the business. These design processes are the very top levels of the design methodology for a software engineer. So, whichever system model you choose, it will most probably always include some, if not all of the procedures in the waterfall model described above. For some further reading about how Saffron creates great systems training. You can also find out how so many organisations get it wrong by taking a look at our blog post on the ‘Seven deadly sins of systems training’.