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.