Internal Corporate applications serve to enable their workforce and provide critical operations and automation for their lines of business. The SPARTA Tools application for Bank of America was no different – and being part of a newly developed platform, which offered numerous advancements to its predecessor, the scope of functions that it is set to support is enormous.
Next-Generation Web Platform
At the time I arrived on the project, the SPARTA Platform was still in a very early stage, having rolled out a few of the Bank’s customer-facing sites successfully using that platform. The next step was to begin building a very critical tool for the use of the developers – Build and Deploy – aimed at improving the internal continuous integration process and replacing third-party CI systems in use. The application would need to support the internal CI process, integrate with the bank’s system, and also be scalable so that more tools could be added down the road.
Today, you can see the results of the SPARTA platform as the vast majority of all customer-facing websites use it, including the bank’s main eCommerce website: http://www.bankofamerica.com
Tools for Developers
One of the factors that made the application’s design complex was the fact that the primary user group, the developers, would still require multiple access levels to various groupings of functions. We knew early on the application would need a robust system that provided adjustable permission levels. Additionally, approval workflows and reporting would be developed to allow monitoring, tracking, and management of the deployment process flow and site and artifact management.
However, this wasn’t the focus of the initial state, the MVP, but rather the business Target State – an elusive term, borrowed from business process operations management, used to describe the vision of what the completed application should look like and how much it should function.
But the requirements for the MVPoC were much less – only focusing on the build and deploy for web developers in each business line.
The operational requirements of the business determine the requirements for an MVP; thus the requirements for every MVP, short of its minimal function needed, is different.
A Simplified Build System
There are many build systems out there allowing a magnificent orchestra of functions to deploy the most complex of environments. Here, the build and deployment process was simplified so that the developer could take the minimum amount of steps needed to initiate, monitor, and manage the build and deploy process for their sites and widgets. This did provide a number of design challenges when applying this concept to building the minimized, consolidated components and patterns.
