This was an elaborate project for UPCnet, the IT services department for the Universitat Politècnica de Catalunya. It was complicated not only because of the size of the project, but because Agilogy was asked to help design an architecture under which all current and future IT developments could be structured.
The University wanted to modernize the tools and technologies it offered its developers. No easy task considering the system was to be used by professors and the scientific staff of the UPC with a very wide range of necessities and features in which precision (these were professors doing scientific research) was crucial. There were also various limitations regarding programming language and platform; it had to be done in Java, Tomcat & Oracle because that was what their sysadmins were trained in.
They also wanted to take advantage of the definition of this new architecture to incorporate new technological possibilities like POJO based programming models, but they lacked experience in this area.
As part of the consulting job it was decided to first do a pilot project with the proposed architecture. Considering the scale and complexity, we suggested implementing various agile development methods.
On the basis of this primary pilot it was decided that Agilogy would lead the DRAC project based on the experience gained. Agilogy was hired for our broad experience with the different technological solutions (EJB2, EJB3, Spring Framework, Hibernate, SpringMVC, Struts, Tomcat,…) to help the client reduce technological risk and to make the most of the development team training so they could focus on the end-product.
Apart from the varied and complex technicalities on the intranet, this project carried with it a lot of external exposure because it was used by all the scientists and their staff at the University. There was no room for errors.
The increased user-friendliness and agility of the new system was appreciated by the users. The system allowed for new features such as incorporating pre-populated fields, which was a big advantage when sometimes to generate a single document, more than 20 forms needed to be filled out. Or the automatic re-directing or duplicating of fields to other documents that would also need to be changed if something changed in a certain document. For instance being able to upload a scientific article for a congress or meeting could now be done simultaneously and with the same form as uploading an article for a scientific journal, increasing efficiency.
Apart from these new technical features a framework was designed, called SK4PE, consolidating a shared architecture between all the separate development projects. This allowed in-house developers with working knowledge of the DRAC project to easily enter into other projects and applications. Changes and new software could thus easily be added if needed, because the basis was the same. Also, a big advantage of this was that the University would be less dependent on Agilogy once the project ended and they would be able to manage and update their own architecture.
In summary Agilogy succeeded to:
Build a comprehensive back-office tool that established a new standard in usability greatly improving what had been used until then, incorporating new features and technologies.
Design a technology stack built for the future needs of the University. (Years later the client was surprised to see that what we had advised in 2006 was still current and had become the standard stack that many companies are using now.)
Allow for an accelerated adoption of the technology stack thanks to us developing the functionalities in the initiating phase but getting the University’s developers involved at an early stage and allowing them to take over the project gradually.
Design and build a solid architecture and framework that could be used as a basis for the development of future projects, making it easier for developers to add or change projects as the architecture and platform they all used was identical. Using the same architecture facilitated the transition of developers between projects, while reducing the cost and technological risk by re-using components between projects.
In this project we also showed that ‘co-sourcing’ is not only possible but can be very beneficial for the outcome of the project if you get mixed teams of developers (both back-end and frond-end) right.