by Tony Myers-Burton, Executive Vice President for Customer Solutions 

Consider the following scenario. A new home builder completes the construction on a house and then invites a single inspector to approve all the work including the foundation, plumbing, wiring, etc. The obvious difficulties associated with this approach is the inability to view the framing, plumbing or wiring through the drywall and verify that components were properly assembled and installed. Furthermore, it presupposes that one inspector, not necessarily an expert in plumbing or electrical wiring, will assess the quality of all the work done.

In opting to inspect at the end of the process, the evaluation effort becomes far more arduous and time-consuming – and less reliable and more expensive. As the above example illustrates, it simply makes more sense to inspect at the conclusion of each construction phase and identify and correct any issues before moving on to the next step.   

MOVING TO A NEW APPROACH TO FEDERAL SOFTWARE DEVELOPMENT

This analogy can readily be applied to software development related to federal information systems. Each system contains multiple components that are built and assembled, much like the construction of a house.  The questions arise: Why increase evaluation complexity – and opportunities for mistakes — by evaluating the software only once it is complete? Further, since design and development of each component demand different subject matter expertise, why have a generalist evaluate every component? Yet, this is precisely the process the government has used for years – and continues to employ – in order to attain approval to operate (ATO) for new systems.

In this scenario, the Information System Security Officer (ISSO) is essentially the building inspector. The ISSO’s role is to serve as the government “cop” and review the software upon completion to assure it “works.” ISSO review timing at this juncture can delay program efforts by months and even years while the assessment is scheduled and performed.

Today, there simply is no reason to employ this antiquated approach when a convenient, time-tested methodology – the Agile method – exists. At the heart of Agile program management and development is the objective of continuous improvement. Agile does this by separating a major project into smaller development efforts called “sprints.” Sprints allow developers to focus on one component part and see, on an ongoing basis, what works and what doesn’t – and what could be done better. Each sprint can last six to 12 weeks from initial requirements definition through design and implementation.

The Agile methodology, while more efficient and effective, does introduce an element of risk into the development cycle. As an incremental approach, uncertainty exists as to whether all the pieces will ultimately fit together and function in the desired way. However, the uncertainty Agile introduces is inconsequential in comparison to the delays comprehensive ISSO testing create. In fact, the associated costs are too expensive to ignore any longer.

Industry has already moved to an agile approach and positioned the ISSO not as a cop but as a vital member of the Integrated Product Team (IPT). It is time for government to adopt the same approach and accelerate the assessment cycle.

A NEW TYPE OF ISSO

In the agile approach, the ISSO functions as an essential part of the sprint team and works alongside the assigned subject matter experts. In fact, the ISSO is a subject matter expert, too, who is knowledgeable about the component being addressed by the sprint project. Thus, the ISSO is part of — and can contribute to — the requirements definition, planning and other processes as they occur. The ISSO can provide ongoing feedback on software security concerns as they arise and have them corrected as they are identified. Not only is the ISSO vested in the project but also able to look at the completed effort with the certitude that each component has been subjected to ongoing evaluation and optimization.

So now that we’ve defined the optimal software development approach, the question becomes: What characteristics or traits suit this modern vision of an ISSO? Well, the new ISSO must be a team player and function as an integrated part of the team, not as an add-on. The new ISSO must want to bring his/her expertise to the table during the process, not at the end. And, the new ISSO must possess an agile mentality, that is, believe in the incremental approach and be focused on identifying ways to continuously improve the item under development.

Depending on the nature of the project, different ISSOs with different areas of expertise will need to function on different sprints. This will be a huge change in the world of ISSOs. Historically, one ISSO would support an organization regardless of whether the effort involved infrastructure, cloud, software development, mobility or more.

·  ·  ·

Change is never easy and frequently hard to institute. However, the time has come for the government to follow industry’s lead and eliminate a key obstacle to effective and efficient software development. The agile method offers tangible benefits – greater mission alignment and faster speed to market (or ATO) – that far outweigh a vision of the ISSO role that has outlived its usefulness and time. Here at Electrosoft we strongly support the agile methodology and the expanded ISSO role it encourages.

Tony also published this blog on LinkedIn. It can be found at https://bit.ly/2Lbio5q.