Date: 2012/08/31
by Shan Swanlow
In the technology industry, innovation happens at a rapid pace, and due to increasing customer expectations, software providers are pressured to continuously deliver cutting-edge functionality in their products. While the integration of innovative technologies enhances market reach for providers, it also introduces additional risk into the development process, which, if not managed properly, can introduce undesirable consequences such as scope creep and project delays. In our experience at Omnipresent Global, upgrading our products to make use of new, cutting-edge open source software has been a cornerstone of our development process, and is something that we have been able to do efficiently while minimizing risk. In this article, we outline some of the guidelines we’ve implemented to guarantee this outcome.
It is of paramount importance to making this process work and the usage of an agile development strategy in conjunction with a flexible solution architecture. Traditional development processes, such as waterfall development, do not allow for incremental upgrades or incremental improvements, and instead focus on producing deliverables previously agreed upon, to exact specification with no time allocated to improvement until development is complete. In the context of a forward-thinking development plan, solutions need to be made as flexible as possible, as fast as possible, in order to minimize the time required for an upgrade. Agile development allows architectural improvements to be made at a consistent rate, and therefore reduces the development time of an upgrade by a non-trivial amount. Furthermore, it is often the case that a developer on a team will only encounter opportunities for improvement during development, and not during planning, making it necessary to allocate time for improvement during development.
To expand on the necessity of a flexible architecture, software from code to solution architecture, ultimately has limitations that need to be considered. The limitation most relevant to innovation is architecture, and coincidentally, is the main factor that influences whether a delay will happen during an upgrade or not. Architectures that are not flexible (such as monolithic applications), naturally take longer to upgrade compared to modular architectures such as the microservice model. As a point of reference, through continuous improvement of solutions via agile development and a focus on modularity, we were able to seamlessly transition between different computer vision technologies with no delay and minimal development work, by requiring a change in only one service.
An additional, critical factor is scoping correctly. As agile is a more flexible process than conventional development approaches, it is pertinent to manage scope and differentiate needs of the business and needs of the client. In reality, improvement of a product is a never ending research question, and if the correct areas of focus are not identified, improvement can often distract teams and hinder the growth of a product instead of boosting it, hence the importance of separating the aforementioned needs. As an example, business needs may be the usage of high quality software stacks to improve scalability and maintainability for teams, while a client requirement may be certain functionalities or compatibilities with their existing software.
Although both areas are of relatively equal importance, the necessity of business needs must be assessed on a case-by-case basis. This is due to the fact that advantages placed on the side of the business may not be directly translatable into a benefit for the client, and thus, the impact of using experimental technologies may not be fully realized. Rather, cutting edge open-source software best finds use for client needs, as the upgrade can introduce more rapid, seamless expansion of the project and allow clients to be more forward-thinking when evaluating their areas of concern- a rare benefit within the solutions space.
Finally, software selection is the final remaining element of the process. This requires careful planning and consideration of various options, though there are a few key traits for selection that should be kept in mind. Software selected should be actively maintained, have some kind of automated testing, be fully open source, and have some professional coding standards and documentation. The presence of these attributes guarantees that developers can focus directly on solution architecture and deployment for the client’s needs, without having to worry about testing, patching, and general maintenance of the software.
Although making use of new technologies is a mostly beneficial process, there is, however, a downside or potential risk that needs to be minimized. In complex or niche fields, making use of experimental software comes at a cost of treating it as a “black-box”- in other words, it can be used to perform a task, but it may not be easy to understand how it performs the task. A developer may struggle to begin to make sense of the project’s internals or familiarize themselves with its architecture, creating a risk of project delays if the business needs to make modifications to suit client requirements. For this reason, it is preferable for teams to build domain knowledge, ensuring that alternatives can be discussed, found, and if necessary, built from scratch.
In conclusion, the current rise in advanced, open-source technologies presents a unique opportunity for development houses to become more client-centric. Despite the risk involved in changing projects during development, with application of a flexible development strategy, a modular architecture, and selection of technologies according to the aforementioned criteria, this risk can be mitigated.