Edited Version February 23, 2000 Transcript
EIIP Tech Arena Online Presentation
"ETeam"
Troy Armstrong
Director of Business Development
eteam.com
Amy Sebring, Moderator
EIIP Technical Projects Coordinator
The original unedited transcript of the February 23, 2000 Tech arena presentation is available in EIIP Virtual Forum Archives <http://www.emforum.org>. The following version of the transcript has been edited for easier reading and comprehension. Typos were corrected, date/time/names attributed by the software to each input were deleted but the content of questions and responses are as stated by each participant. Answers from the participants to questions by the audience are grouped beneath the appropriate question to facilitate meaning.
[Opening]
Amy Sebring: Welcome to the EIIP Tech Arena!
For the benefit of our first-timers, when you see a blue web address, you can click on it and the referenced Web page should appear in a browser window. After the first one, the browser window may not automatically come to the top, so you may need to bring it forward by clicking on a button at the status bar at the bottom of your screen.
We will start with a presentation, and then follow with a Q&A session for your questions and comments. Right before we begin the Q&A portion we will review the procedure.
Please do NOT send direct messages to the speaker or moderator as it makes it difficult for us to follow the discussion.
Background information for today's session may be found at <http://www.emforum.org/varena/000223.htm>.
[Introduction]
Today we are pleased to welcome back Troy Armstrong to tell us about a new product, ETeam. Troy gained considerable experience in applications for emergency management when he worked for the California Office of Emergency Services, and made a presentation for us during 1998 on the RIMS system. Please see the background page for Troy's bio. Welcome Troy, and thank you for joining us today.
[Presentation]
Troy Armstrong: Thank you for having me. Good morning, or good afternoon, depending on where you are. I'm Troy Armstrong, the Director of Business Development for eteam.com. In my former career, I was the chief of operations for the Governor's office of Emergency Services (OES) in California until early 1999, when we got a new Governor, and I got a new job. While at OES I managed 5 federally declared disasters, about a dozen state declared disasters and hundreds of small incidents across the state.
Additionally, I developed and implemented the states Response Information Management System (RIMS). Before that I worked full-time for 8 years with the California Military Department running military support to civil authorities missions.
[SLIDE 1]
[SLIDE 2]
Today I'm going to be giving you an overview of the ETeam emergency and event management software system. I will discuss its major features and how it can be used by managers and staff tasked with preparing for or responding to emergencies and events. Also, I will talk about the agencies using the system and what their experiences have been to date.
[SLIDE 3]
Prior to getting into the emergency management software business, eteam.com specialized in developing command for the Department of Defense. The company still performs that mission, having contracts with DARPA (the agency that invented the Internet and stealth technology) and the Joint Special Operations Command.
In late 1998, after meeting with the City of Los Angeles Emergency Operations Office decided to develop a web-based emergency and event software system to coordinate their actions. The system in its current form, or with minor customization, to assist government agencies with the tasks you see on the slide.
[SLIDE 4]
As I stated earlier, the system is web based, so that all users have to have is access to the Internet and a Web browser (Netscape 4.5 or Internet Explorer 4.0 or better). Security is handled through username and password and secure socket layer; thus right out of the box it is as about as secure as your average online broker. However, if customers desire greater security, we can add more layers. As you can see, the system is fully Web-enabled with a built in GIS map that interfaces with the systems reports. The map that comes standard with the system is a street level map provided by GDT and one of our business partners, ESRI. While the system comes with a street level map, customers have the option of using their own maps or adding their own GIS layers to the existing map.
[SLIDE 5]
As previously stated, the eteam.com was originally a defense R&D shop, so when they decided to get in the emergency management business, they knew they needed to put together a team of experts who know the business inside and out. With this in mind, they hired myself, Bruce Ward, the former Deputy Director of California's OES, and John Bowles, the former CIO of OES and the co-creator of RIMS. Also, we added former members of the Secret Service and the Army's Delta force to help us with the development and training.
[SLIDE 6]
The design team came together in March of 1999 and on September 15, 1999, the product was released. In the development of the system, we created and strictly adhered to a philosophy we felt would ensure that we would put out a system that would prove to be an effective tool for emergency managers.
First, it had to be easy to use. Our experience in the emergency management game had taught us that most people who work in operations centers do so as an additional duty; thus they don't have a lot of time for training. Additionally, we also know that there is often a good deal of time between training and activation, so we had to make sure that the system was easy to remember how to use. We set the standard that it should not take more than an hour of training to get the basics of the system. Additionally, we made sure that it would only take a few minutes to remember how to use.
Second, we wanted to make sure that the system focused on the most important tasks performed in the management of a disaster or major event. In most systems that the design team had seen or used (RIMS included) there were tons of applications that people rarely use during an activation, or at least do infrequently. We found this distracting and kept people's attention away from what they really needed to be doing.
Next, the system had to be easy to set and implement. This came from John's and my experience in setting up and fielding RIMS. RIMS was a client/server system which meant that we had to load software on every computer that was going to connect to the system. After four years, I had over 1000 users from 130+ agencies connected to RIMS. I will never go through that again. Every agency had different computers with their own network issues that drove my tech support folks crazy. Thus, when we started building ETeam, we were determined to make it Web-based so that all you would have to do to get someone on board was issue out a URL and a username/password.
Also, we were determined to keep the system inexpensive. Even though California was a big state with a large OES and a lot of disasters, we never seemed to have any money. We felt that was a pretty consistent problem with most emergency management agencies; as well as the other departments they interact with. So, with this in mind, we structured our pricing so that even small jurisdictions could afford to use the system.
Finally, we designed the system so that we could continuously add new features and improve existing ones. From our experience, we know important lessons are learned from every activation. We wanted our system to be ready to quickly incorporate those lessons.
[SLIDE 7]
As I stated earlier, we wanted to make sure the system was easy to use. We determined that to do that, we needed to develop a very intuitive interface that only required a couple of clicks of the mouse to perform most major tasks. Additionally, we wanted to make sure that the general interface never changed so users would not feel like they were lost within the system.
The simple interface we developed made the system easy to learn how to use. In the agencies that are currently using the system, we have found that they were in fact able to not touch the system for several weeks after training and be able to figure out how to use it again in less than five minutes.
We were greatly assisted in the simple interface by the expansion of the web in daily life in America. Since our system takes advantage of many normal web browser features, users felt very comfortable using the system. To many of them, it was just another thing to do on the web, and they were already doing lots of things on the web.
Finally, we have made it simple by making the reports and maps easy to use. We laid out the forms so that they get the general information up front and put the detailed information at the bottom. We did this because often-detailed information isn't available, and we didn't want users to have to hunt around the form for places to enter the general information they did have. Also, we made the map interface incredible simple. If you want to post a report to the map, then all you have to do is type in a street address, or the name of the cross streets or just go into the map itself and click on the place you want the icon to appear on the map.
[SLIDE 8]
To make the system easy to use, we gave it a simple "create and view" interface. If you want to create a new report, just click on the appropriate create button on the top of the screen. If you want to read and/or update a report, just click on the view buttons on the left-hand part of the screen. We have found this interface very popular with our customers. They like the fact that they don't to hunt for information and go through a dozen screen changes to perform the tasks they need to.
[SLIDE 9]
To make the system viable to our customers, we made sure that it focused on those tasks that normally determine success or failure in the management of multi-agency, multi-hazard events.
[SLIDE 10]
The next series of slides show how the system is initially set up and which users are connected. While we would like to sell a lot of licenses to a customer right up front, we feel it is better that they start out slow and get their main EOC up on the system first. This helps them better plan out how they will take full advantage of the system when they start connecting other agencies.
The example I am using is for a state, but it applies just as well to Federal and Local Agencies. We recommend that users begin by getting the major staff sections and agency representatives within an EOC up on the system first.
[SLIDE 11]
After the EOC gets up and running, then we recommend that the EOC start giving access to the major state agencies and counties they normally interact with during disasters. It is important to keep in mind that with our Web-based system, getting an agency connected means giving them a username and password. Thus, it takes only a couple of minutes to get someone on board.
[SLIDE 12]
The major agencies, particularly those that provide a lot of resources, can then start fielding the system within their own organization. The example I use here is the National Guard. Once they get their main EOC up and running on the system, they can then start adding their subordinate units to the system by merely issuing out usernames and passwords. This will greatly assist them in tasking and tracking the deployment of resources.
[SLIDE 13]
At the county level, they too can start to expand the system out to their cities and major departments. At this point, the system can be modified so that the State only sees the information and requests that the County wants them to see. This is a helpful modification of the system to ensure that the state does not get overwhelmed with information that they really don't need. Also, it gives a measure of control over the information the county makes available to the state.
[SLIDE 14]
[SLIDE 15]
This slide demonstrates the use of the resource request application. In our scenario here, following a disaster, a resource request is made to the county. The county, after determining that they can't fill it, forwards it to the state, which then assigns it to the appropriate state agency. The state agency then deploys the resource to the requested location. The important thing to note here is that everyone is in the loop on this request, thus the request never disappears in some "black hole" at some EOC. At anytime, anyone in this chain can go in and see what the status of the resource is and who has the action on it.
[SLIDE 16]
As I mentioned earlier, we have kept the price within the budgets of most local governments. We offer the system in two basic formats. The first, we Web host the system at our secure server sites. This is the preferred method for most of our customers since it is the easiest and cheapest (when you factor in the costs of buying your own server and the time of a good system administrator). All customers have to do is give us a list of their agencies and list of the types of resources they normally use (we offer a generic list that is pretty comprehensive), we set up the servers and give them the usernames and passwords. The lists can be modified at anytime and customers can add more users at will.
The cost is $1,000 for the initial set-up for local governments, a little more for State and Federal Agencies depending on how big their maps are. And then $395 (per year) per user. We define a user as a username and password.
The servers we use are in secure locations out off any major flood plains, earthquakes zones etc. They also have multiple back-ups of power, access to the Internet and automated load balancers that switch customers from one server to another should one server crash or become overloaded. The servers are mirrored so that should be switched, you will not loose any information. In fact, you won't even know it happened.
With this package, we offer a discounted price on our server software if you want to setup a backup server at your own EOC. A lot of customers take this option as well, since they are afraid their EOC may become isolated from the phone system during a disaster.
The other option is to setup and host the system yourself. Our costs for this option are as you see on the slide, with a 2/3 annual renewal fee. So for example, the initial cost for a user would be $300, with an annual renewal fee of $200.
With either option, customers get technical support and free upgrades to the system. As I mentioned earlier, we intend to add a new feature to the system about once a quarter.
[SLIDE 17]
As you can see, the system is very easy to setup and implement, particularly if you use our Web-hosting service. There is no software to load on the end user’s computer. All they need is a Web browser and a username and password.
[SLIDE 18]
Here we see the customers that have started using ETeam. It is important to note that the system has only been available since September 1999. Also of interest is the fact that Disney and Warner Brothers are actually members of Burbank’s system. The City and these two major studies have a strong mutual aid arrangement and liked the idea of using the system to coordinate with one another. The studios like it because it gives them an idea of what's going on around them, and the City likes it to make sure that two of the larger employers in the area are being taken care of during a disaster.
[SLIDE 19]
Many of our customers were using the system during Y2K and even though nothing much happened, they were none the less pleased with the system. In fact, many of them have come back and ordered additional licenses to start expanding the system within their jurisdictions.
[SLIDE 20]
At eteam.com, we believe that we can always improve our product, and that it is important constantly add new features. Some of the features we intend to add over the next 18 months are as follows: Map Drawing Tools that will allow users to draw boundaries, routes and other symbols on the maps. We will be integrating the CATS modeling system into the application so that you can overlay plumes, storm surges etc on the maps. This summer we will be offering user customization tools so customers can make changes to the picklists and issue out their own usernames and passwords.
And finally, we will constantly be updating and improving all of our applications. We make it a policy to get as much customer feed back as we can so that we can make sure that our product is really serving the needs of the emergency management community.
[SLIDE 21]
[SLIDE 22]
I am afraid that I can't do a demonstration from where I am, but you can get more information and sign up for one of our demo sites by going to <http:// www.eteam.com> or emailing me at <[email protected]>. I would be happy to take any of your questions at this time.
Amy Sebring: Thank you very much Troy for preparing this presentation. We have run over our time but if you would like to stay a little longer we will go ahead and take questions for about 15 minutes.
Troy Armstrong: I can stay, and I apologize for going over.
Amy Sebring: Audience, please enter a question mark (?) to indicate you wish to be recognized, go ahead and compose your comment or question, but wait for recognition before hitting the Enter key or clicking on Send.
[Audience Questions]
Question:
David Crews: Have you had any response on this from FEMA? And will this work at the Catastrophic end (e.g. WMD)?
Troy Armstrong: We have met with FEMA a couple of times; they like it and have asked us to talk more to them. And yes , it is multi hazard, so it will work well for WMD.
Question:
Peter Picanso: On the CATS system, will the overlays be real-time so that the maps can be updated to indicate the movement of a plume or the redeployment of resources?
Troy Armstrong: Close to real time. The refresh is about every minute. We are working with SAIC and ESRI on this application for the Winter Olympics.
Comment:
Libbi Rucker Reed: I requested and used the demo Troy mentioned. I was very impressed with the ease of use for this system particularly by the web-based format. In addition, being able to check resource requests and requirements from multiple areas within this system was valuable. Moving around in the program was easy and I never got lost in what I was doing. Good product.
Troy Armstrong: Thank you. We will continue to try and improve it.
Question:
Elizabeth Hicks: What are the chances that a hacker can get in and screw up the system during an emergency?
Troy Armstrong: Limited, but still possible. They really have to try and find it first. It is about as secure as a Web brokerage but we can add more security as needed.
Question:
David Crews: Planning: Have you looked at the new FEMA ESF-5 Ops guide? This would work well in the Region Operations Centers.
Troy Armstrong: I haven't yet. But I think this system is perfect for State EOC and FEMA ROC/DFO interface and coordination.
Question:
John Kihl: What DBS is used on the server side in the background to support the Web Server?
Troy Armstrong: John, Domino and ARCIMS are the engines that drive ETeam. And a little of our own software we developed in house.
Question:
Matt Gneuhs: Troy, I am going to be setting up a map for Red Cross Chicago. How current are the demographics and information and data?
Troy Armstrong: Email me on that Matt, please. The standard map we use, Dynamap 2000 is ‘as off’ 1999. We get annual updates and pass them on to the customer.
Question:
Ben Johnson: I can see where you can make the e-team cost effective to smaller jurisdictions if you host their data. How do you address the problem of loosing your Internet connection during a disaster?
Troy Armstrong: Ben, with back-up servers in the EOCs that use the system. Once the EOC gets back on the phone system, their servers replicate with our servers. Also, we have found that slow satellite connections to the Internet work for everything except the map. The maps really need a 56k connection.
Question:
Peter Picanso: When the system is operated offline, how easy is it to put it back online once the phone system come back up?
Troy Armstrong: Very easy. When you run a back-up server in your EOC, it keeps looking for our servers. Once you restore a connection, the servers replicate. We have practiced this and it is fairly simple, but it does take some work.
Question:
Peter Picanso: So it should operate seamlessly?
Troy Armstrong: In our testing it has. The trick is making sure that the backup EOC server knows what connection you are using. If you change the connection, then you have to tell the server.
Question:
John Kihl: How do local and state EOC add their data to your servers?
Troy Armstrong: John, we have a form you fill out. It gives us all the information we need to build the picklists. The picklists can be modified on the fly, if you have changes.
Question:
David Crews: Do you use ERSI software (Map Info) for mapping as well? Can you interface with FEMA Q3 and Corps of Engineers mapping?
Troy Armstrong: We can use any map in .shp file format. We do develop maps using ESRI products. I have not seen the FEMA or USACE maps you mentioned.
Amy Sebring: ESRI is ArcView, ArcInfo.
David Crews: Thanks, Amy!
Amy Sebring: Troy, ESRI has the FEMA Q3 data.
Troy Armstrong: Thanks Amy, I will call them; they are a business partner with us.
Question:
Matt Gneuhs: Do you include the most recent flood plain maps, census data, will that be included in upgrades? Also about how many layers can it handle?
Troy Armstrong: I don't know the limit of layers, we haven't reached it, yet. However, the more layers, the slower the map. As for flood maps, we can add them for an additional fee (a small one) if they are in .shp format and are geocoded.
Final Question:
Ben Johnson: What is involved in setting up the server for the EOC? What software and hardware does the EMA have to purchase? What investment is usually required to set up a network server from scratch (hardware, off-the-shelf software, etc.) to run your software?
Troy Armstrong: We have found the average cost for a server and firewall is about $10,000 to 15,000. You also need Windows NT and Domino. They run about $1500 a piece the last time I looked. But the hard part is maintaining a server. That is why most people have us host the server. We take care of the 24/7 care and feeding of the server. That seems to make the local IT folks happy. Since they already have enough servers to maintain.
[Closing]
Amy Sebring: Thank you very much for being with us today, Troy. Good luck with this. Please stand by for a moment while we take care of some business.
Thank you audience for persevering today! Avagene, can you tell us what's on for next week, please?
Avagene Moore: Thank you, Amy. Thanks, Troy. On Wednesday March 1: Virtual Library - "A Disaster Planning Toolkit for the Small Business Owner," with Herbert Mitchell, Small Business Administration (SBA); and Diana McClure, Institute for Business and Home Safety (IBHS). A timely topic -- as we all know, if a community's businesses don't recover from disaster, neither does the community. That's it, Amy.
Amy Sebring: Thank you, Ava. Thanks again, Troy and thank you, audience. We will adjourn the session for now, but you are invited to remain for open discussion. You no longer need to use question marks.