The Need to Push Down Silos
A few years ago, a friend of mine, trying to generate additional students for the classes I teach, asked his cousin who works for a very large architecture and engineering firm in the new World Trade Center in New York City, if they would be interested in attending training on integrating security technologies into building design. His cousin answered something to the effect, “No, we leave that up to the client after we turn the building over to them”. While his cousin’s answer is not surprising it is disappointing and confusing to me.
Not surprising because I’ve heard that so many times before. In essence, everyone stays in their silo and the connection between the disciplines usually only involves answering questions about the project and clarifying requirements; architects architect – engineers engineer – and security securities, if you will.
It’s confusing on two levels. First, at the beginning of every project the architect gets the client’s desires list; i.e., the building should be blah, blah, blah. Right from the start the architects develop a mental picture of what the building should look like. Next he or she begins to include all of the regulatory requirements or “best practices” for design. Best practices are nothing more than this is how it’s normally done. In New York City, for multi-story buildings in Manhattan the façade default material is glass in the Mid-West it is reinforced concrete or masonry units. Meeting regulatory requirements deal with disability act, fire and safety codes, such as, hallway width, stairs, doors and windows, and elevator placement, etc. and depending on the region some weather related events. And second, very seldom are man-made threats considered. This contributes to the fact that man-made threats continue to occur despite large amounts of money being spent on security measures. I guess the argument could be made, that “well, we’re not required to consider them like we are for natural threats so we don’t need to; besides it will drive up costs”. On the surface this makes sense but if you dig just under the surface your next thought should be, why don’t “best practices” apply?
The Department of Defense, and some other federal government agencies to a limited degree, requires that integration mitigation strategies be included in their building design review process regardless of where or what type of threat is involved. In fact, it’s mandated that all threats, including man-made threats be addressed by a group of stakeholders at the onset of any new building construction project and for renovation projects that meet certain thresholds or “triggers”. The stakeholder group determines the “design basis threat” to the building and its occupants and the level of protection required based on the number of people occupying the space. These two factors ensure that the appropriate amount of money is spent on protection options and in the unlikely event a catastrophe does occur; injury and death will be kept to a minimum.
By bringing all stakeholders together from a variety of disciplines, everyone 1) has a chance to air their requirements and needs, 2) buys-in to the group’s decision on which threats will be addressed and support the “DBT” and the level of protection required, and costs are kept down. Adding electronics in the form of surveillance or other technologies lies with the owner after the project is completed. So in the short term, the cost of this equipment and its installation is currently absorbed by the owner/client and is not part of the building costs. This “trick” helps keep the building design costs down but doesn’t adequately protect people or the facilities they use. But more importantly, the real costs to the client come after the installation from the long term requirement for equipment maintenance and manpower.
Since buildings are currently designed with everyone, remaining in their silos, with limited exception, the process is treated as if it were a vertical process, when in reality it’s a horizontal one. The “silo effect” and the isolation it causes make security an “add-on” and limits its efficiency and effectiveness.