Many security technology convergence collaborations come about as a specific need or specific project. For example, there is a need to share video with stakeholders across the network, and consequently, discussions are begun between security operations and IT about how to accomplish that.
This is one of the more simple examples, although even seemingly simple situations can turn out to be complicated based on the bigger picture, as the question below illustrates. Roadmap planning can provide a larger context for the additional complexities, and turn a "problem-solving" situation into a successful planning initiative.
Q: I need to provide access to live and recorded video to some of our real estate people. I approached IT, explaining that we wanted to implement Quality of Service (QoS) protocols (I understand this could be important on a high-traffic network) to ensure that the video on the viewing end would be smooth and not jumpy or jittery, or not have empty squares in parts of the image (this happened with one webcam we put up quickly to watch some emergency construction work). IT said no, because QoS was further down their roadmap. Should I think about trying to convince them to change their roadmap, or do I try instead to get funding for a separate network run? - Security Operations Manager
A: There is more than one way to address network traffic integrity, and an IT-savvy technician from your integrator or an independent technology consultant can explain the options based on the current state of your corporate network. However, this situation highlights the need for high-level collaboration. Unless Security's technology roadmap and IT's technology roadmap are in alignment, solving this issue and subsequent attempts at collaboration could be challenging.
IT shouldn't change its long-term roadmap based on a single need or one-off solution request. However, it is the role of IT to anticipate and serve the organization's long-term network needs, and if these can be presented by any functional area or business unit, that may provide IT with sufficient reason to expand or adjust the roadmap. Alternatively, IT's plan may be an excellent one, and if already funded, it may be appropriate for security to schedule its technology improvements in a way that matches up with the network infrastructure work being done by IT.
Technology roadmap development should start with identifying the business needs and functions to be supported. For example, when one company wanted to implement flex-time for its employees, arriving early during some times of the year meant arriving before sunrise.
Additional security lighting was needed along some paths in the facility complex. Some buildings that did not have video cameras and intercoms at their main doors would now need them to enable employees to contact security if they had forgotten their access card or if a security concern arose.
Because Security participated in the organization's change management process, these needs were identified ahead of time. IP intercoms were seen as cost-effective. It was important to establish QoS on the network paths for the intercoms, to ensure voice-quality sound. IT already had a QoS rollout planned as part of its larger VoIP telephone project, and so the QoS implementation for intercoms (being done first) would need to meet the standards set for the VoIP initiative. All of the other business changes needed were identified, planned and budgeted, and rolled out according to an overall schedule. During discussions, Security mentioned its intention to add a few outdoor network cameras, which opened more general discussions about networked video and its QoS and bandwidth requirements.
Security and IT worked together to update their technology roadmaps to be consistent with each other's plans. In this particular case, Security had to create a roadmap with some guidance from IT, because Security had not been using technology roadmaps as a planning tool in the past. It was easier than usual to get funding for the security technology upgrades, because the security planning was tied in with business needs, and the timing of the funding was linked to the timing of the IT roadmap.