BOS – Framework as a Service
Software Engineering is an immature discipline. Late delivery, going over budget, Product not meeting specified requirements, inadequate documentation, lack of standardization, unpredictable maintenance needs and other related problems are common to most software projects. Where other Engineering disciplines enjoy well-defined global standards that afford Engineers the ability to predictably and consistently calculate time, cost and delivery metrics, Software Engineers suffer from serious lack of such standardization. The result invariably is that the same engineer does the same thing different ways at different times making globally accepted design and project metrics a far cry.
One big reason for this is that most Software Engineering projects have too many variables/ unknowns associated with them. And the Software Engineering discipline has not been able to provide a prescriptive framework that helps architects, project managers and programmers to function per a well-defined sequence of steps containerized in a repeatable, standardized framework. This makes software engineering non-deterministic in nature. Solutions therefore can never be exact/ accurate and must be optimized. As such, this can only be done by very experienced professionals who must dig into their own experiences.
What is needed is a prescriptive framework for architecture and project management, treated as a single approach to producing usable software quickly and in a very predictable manner.
To do this, the number of unknowns must be reduced. This can be impacted by increasing the number of constants in the software system: In terms of technology challenges, architecture and design, project management and product management.
The software system’s backend typically creates the most unknowns for business stakeholders, product managers, project managers and engineers alike. There are many implicit requirements that invariably get missed and it is very difficult for any single party to assume the responsibility of owing up to defining them. UI/ Frontend and Business Requirements on the other hand are more tangible and measurable.
Employing a comprehensive Framework can introduce a huge constant, as a large portion of the Backend will be known. The specific backend requirements that such a framework may not readily provide would then be the minimal delta that can be addressed as such. The frontend and business requirements can be detailed and developed more predictably on a tried and tested framework.
This increases maturity in an otherwise immature field of Engineering.