I first got involved in emergency response in high school as a search and rescue volunteer. Over the course of 10 years I trained for and participated in a number of missions, often serving as part of the management team. During some of those same years I was able to also lend my technical expertise as a Whatcom Count IT employee to regional emergencies such as the 2009 flooding.
In the 2010 H1N1 response I served in the logistics section. This was a unique incident in that we essentially operated a virtual EOC. With the incident spread out over weeks and being responded to between our day jobs, Unified Command turned to technology. The Communications Unit had to adapt. We experimented with email distribution lists, SharePoint sites, call distribution services and even created custom software.
As both an ICS 400 trained emergency responder and a IT manager for a local government agency, I have continued to be intrigued by the intersection of technology and emergency management. With the Skagit River bridge collapse and the the much more tragic Oso mud slide it is obvious that we all need to work together.
As all emergencies are local, it often falls to the local city or county emergency management departments to host command posts and/or EOCs. This subsequently means that it is city and county IT departments that are often tasked with technology support.
Providing technology support to an incident management team is a very different challenge from traditional IT support.
Traditional IT deals with employees who typically come and go in an orderly fashion. Accounts are setup for individuals. Standards for equipment (for the most part) are set. Help Desks have business hours.
In an emergency, IT will be tasked to provide communication and collaboration tools to a diverse, frequently changing, roughly self-organizing, and mostly self-equipped workforce at a moment's notice with little staff involvement for less than the cost of a MacBook Pro. All while respecting the principles of emergency management and ICS such as record retention, span of control and authority. On top of that, IT will be expected to meet the technological expectations of the modern workforce.
I recently attended a local debrief of responders who worked at a large EOC at a recent large event. It was clear both how much they could benefit from proper technology and how challenging it was for the needs to be met.
It was after this that Whatcom Unified, our local, joint, emergency preparedness agency recently asked me for ideas on how to equip their new facility to address these challenges. It was through this thought exercise that I first documented the challenges stated above and came to the idea of a template.
Currently each agency must attempt to solve these problems on their own, often after the emergency has occurred.
What if instead, we worked together ahead of time to create one or more templates that could work for any jurisdiction, at any site or across multiple sites.
Such templates would suggest common tools, configurations, procedures and preparations. Multiple templates could be developed to align with different jurisdictional needs but they would all be shared, even build off of each other.
Such a collection would have many benefits. For example it would allow responders from outside the jurisdiction to come prepared for the technology configuration or allow neighbor IT departments to send assistance.
In my next post I will introduce you to what I have started and review some more of the requirements.
Sunday, July 27, 2014
Responding to IT Needs in an EOC Part 1
Tuesday, November 1, 2011
VPNs, Macs and the Misunderstanding of IT in 2011
I have been reading Ars Technica since it was all black and done from a dorm room in Boston. Lately with the consumerization of IT, especially hardware (think Macs, tablets, and smartphones), Ars has been posting a number of articles (one, two, three) critizing corporate IT departments for not better supporting the consumerization trend.
Well, I am here to tell you that they have it wrong. It is not the IT department that is resisting, it is the commercial off the shelf (COTS) software vendor for line of business applications that are the problem and our customers who are the cause. These vendors, and to a lesser extend internal application developers, have not adopted coding practices that allow for us to break free of the Windows/LAN environment and for the most part our customers don't care, at least not until they get a new iPad for Christmas.
Yes, anyone can do email in the browser. However, most organizations (except maybe writers for Ars Technica) depend on more then just email. Many have line of business applications such as Financial systems, HRIS, and asset management that will not run in the browser or across take advantage of non-LAN based communications practices. Think about of your line of business applications. Which ones require Windows to run. Which ones, even if not requiring Windows, run directly connected to the database. How many are still in FoxPro or MS Access (this is not a dig against Access, which I like :-)?
I can not put application X, which requires direct/high speed access to the sql database, file based access to a Windows server and direct connectivity to the printer, on your tablet, Mac or smartphone. Even to get it to work on your Windows laptop I must spend lots of time and money getting and maintaining a VPN solution. I have VPN as much as the user does. It extends a foriegn system into our network. VPNs are not a good security solution but they are better then opening ports to SQL servers and exposing our file servers on the Internet.
For the vendor, their profits lie in extending their old code base and adding business features and not in re-writing their code base to work across platforms and networks.
Now you might be wondering why the customers are the cause. Well, it is they, the finance department, human resources department or the operational department that ask for features from the vendors. They demand more business functionality and not technical functionality. And they should. But the IT departments NEED their help to also ask for technical functionality that advances the code base (often a significant investment for the vendor) to one which supports the consumerization of IT. The vendors only listen to the customers, not IT as it is often the customer that is footing the bill.
So next time you complain about not being able to use your Mac, iPad or Android smartphone to do your work, next time you complain about your VPN not working, tell your boss, NOT IT. We tried but your boss wanted a new widget instead.
Note, this is not a reflection of my current employer, but a rant on behalf of IT managers everywhere.
Friday, June 24, 2011
Thoughts on Government Records Retention in SharePoint, Part 1
The other morning I was asked for my thoughts on applying records retention concepts to SharePoint. First, I believe that given recent legislative changes and interpretations by both the State Attorney General and Secretary of State's office, every application has a role in records retention. With the born digital concept firmly established, once the information is created in a system, this new "record" must be retained according to record retention guidelines. SharePoint is no exception and provides a good exploration of the intersection of business needs and records management needs.
For those not stuck looking at records retention issues on a daily basis, lets setup our example. From the Local Government Common Records Retention Schedule (CORE) v2.1:
So what must a system do in support of records management. It must be able to do three things. First is classification. This means identifying the record series that the records belong to and the relevant date.
Sometimes this can be implicit. We simply make notice that all records in system X are of this record series. The actual classification is not tracked with the record, however, we have documented that records matching a certain criteria are in a specific series. This is possible for those systems that have strong metadata support or where the actual content of the record clearly defines the series. For example, a Contracts management system would implicitly match the contract documents with Item 1.4.3 Contracts and Agreements (DAN GS50-01-11 r1). The termination or expiration date is the relevant date and the record is to be retained for 6 years. This is made easier when the metadata or record construct is the same throughout the system.
Classification can also be explicit. In this case metadata used specifically for the record series identifier and the relevant date are created and managed. This is often needed when the metadata or the record constructs are not consistent throughout the system, such as SharePoint. In the State of Washington the record series is identified by a Disposition Authority Number (DAN). Both the DAN and the relevant date should be noted on each record.
Lets take a moment and explain the relevant date. This is the date when the retention clock starts. Primary records must be maintained for y years from x date. In a number of cases, they do not have to be retained once they are obsolete or superseded ("destroy when obsolete or superseded"). In this case y=0 and x=the date record is obsolete or superseded. This might mean that when a new version of the form is published, the old form get a relative date of the publish date of the new form. In other cases, like the example above, the relevant date is dependent upon user action (y=3, x=date broken link fixed). Very rarely is the relevant date the same as the creation date. To further complicate things, in some cases the relevant date can change. For example, a court case could be appealed or a new report come in and the retention clock would get reset. Finally, the relevant date is often not known at the time the record is first created.
The second records management component that systems must support is retention. Retention is simply the act of keeping the record intact from the moment it is no longer needed for business purposes to the point in time where the retention period has expired. The retention period is measured from the relevant date. The retention period and business need period may occur in sequence or run concurrently. The business need may last longer then the retention need. In any case, the document must be retained intact for which ever is longest. Additionally, holds for non business needs should be allowed, such as for legal actions or public record requests and may super cede the retention schedule.
The system should make it very difficult to delete, destroy or change the record during the retention period. The record must be kept intact, complete with metadata. However, it is important to note that because the relevant date is often not set until later in the business process, it may be possible or even desirable to have the system allow deletion prior to establishing the relevant date. Examples include draft documents which are never finalized or data entry errors. It is also likely that during the business need period, the record could be altered or further added to. However, once the record series and relevant date are set, care must be taken to be able to discern how the record has changed since that point.
Third, the system must support disposition of the record. Disposition is the formal act of dealing with the record post retention. There are essentially two options.
One is to transfer the record to the State archives. Some records, as established in the retention schedules, have archival value and must be assessed for transfer to the State Archives. With digital information, this is much more difficult then with paper originating records. To date, only scanned documents and email are regularly handled by the digital archives. Because of these limitations, SharePoint must be VERY carefully considered for any use and storage of primary records that have an archival value.
Lastly, a very important component of disposition is documentation. A log must be kept identifying the record, record series, relevant date, disposition, disposition date, who approved disposition and who carried out the disposition. A good system will support easily finding records ready for disposition and logging of the disposition act. Remember, it may be necessary to document two disposition dates, one when it was removed from the system and one when it was removed from backups.
So, I have just spent a very long post laying the groundwork for records management in a generic application or system. What you really wanted to know is how do we get SharePoint in on the game. I believe that by tracking DAN, relevant date, using custom Content Types, workflows, SharePoint's built in records management functionality and reporting services, it will be possible to bake records management, with explicit classification, directly into SharePoint. In the next weeks (until my Office365 demo runs out) I will be experimenting and documenting my experiences implementing records management in SharePoint 2010. Stay tuned.
For those not stuck looking at records retention issues on a daily basis, lets setup our example. From the Local Government Common Records Retention Schedule (CORE) v2.1:
Item 1.3.2: CITIZEN'S COMPLAINTS/REQUESTS Communications from citizens making a complaint or request, as well as the associated agency response. Retain until: Matter closed plus 3 years. DAN: GS50-01-09 Rev. 0.This record series covers correspondence with citizens, specifically complaints or requests. Many public emails to agency/department accounts would be covered. For example, if I were to complain about a broken link to webmaster@agency.org, that would need to be retained in digital form, complete with metadata, until 3 years after I fixed the broken link.
So what must a system do in support of records management. It must be able to do three things. First is classification. This means identifying the record series that the records belong to and the relevant date.
Sometimes this can be implicit. We simply make notice that all records in system X are of this record series. The actual classification is not tracked with the record, however, we have documented that records matching a certain criteria are in a specific series. This is possible for those systems that have strong metadata support or where the actual content of the record clearly defines the series. For example, a Contracts management system would implicitly match the contract documents with Item 1.4.3 Contracts and Agreements (DAN GS50-01-11 r1). The termination or expiration date is the relevant date and the record is to be retained for 6 years. This is made easier when the metadata or record construct is the same throughout the system.
Classification can also be explicit. In this case metadata used specifically for the record series identifier and the relevant date are created and managed. This is often needed when the metadata or the record constructs are not consistent throughout the system, such as SharePoint. In the State of Washington the record series is identified by a Disposition Authority Number (DAN). Both the DAN and the relevant date should be noted on each record.
Lets take a moment and explain the relevant date. This is the date when the retention clock starts. Primary records must be maintained for y years from x date. In a number of cases, they do not have to be retained once they are obsolete or superseded ("destroy when obsolete or superseded"). In this case y=0 and x=the date record is obsolete or superseded. This might mean that when a new version of the form is published, the old form get a relative date of the publish date of the new form. In other cases, like the example above, the relevant date is dependent upon user action (y=3, x=date broken link fixed). Very rarely is the relevant date the same as the creation date. To further complicate things, in some cases the relevant date can change. For example, a court case could be appealed or a new report come in and the retention clock would get reset. Finally, the relevant date is often not known at the time the record is first created.
The second records management component that systems must support is retention. Retention is simply the act of keeping the record intact from the moment it is no longer needed for business purposes to the point in time where the retention period has expired. The retention period is measured from the relevant date. The retention period and business need period may occur in sequence or run concurrently. The business need may last longer then the retention need. In any case, the document must be retained intact for which ever is longest. Additionally, holds for non business needs should be allowed, such as for legal actions or public record requests and may super cede the retention schedule.
The system should make it very difficult to delete, destroy or change the record during the retention period. The record must be kept intact, complete with metadata. However, it is important to note that because the relevant date is often not set until later in the business process, it may be possible or even desirable to have the system allow deletion prior to establishing the relevant date. Examples include draft documents which are never finalized or data entry errors. It is also likely that during the business need period, the record could be altered or further added to. However, once the record series and relevant date are set, care must be taken to be able to discern how the record has changed since that point.
Third, the system must support disposition of the record. Disposition is the formal act of dealing with the record post retention. There are essentially two options.
One is to transfer the record to the State archives. Some records, as established in the retention schedules, have archival value and must be assessed for transfer to the State Archives. With digital information, this is much more difficult then with paper originating records. To date, only scanned documents and email are regularly handled by the digital archives. Because of these limitations, SharePoint must be VERY carefully considered for any use and storage of primary records that have an archival value.
Lastly, a very important component of disposition is documentation. A log must be kept identifying the record, record series, relevant date, disposition, disposition date, who approved disposition and who carried out the disposition. A good system will support easily finding records ready for disposition and logging of the disposition act. Remember, it may be necessary to document two disposition dates, one when it was removed from the system and one when it was removed from backups.
So, I have just spent a very long post laying the groundwork for records management in a generic application or system. What you really wanted to know is how do we get SharePoint in on the game. I believe that by tracking DAN, relevant date, using custom Content Types, workflows, SharePoint's built in records management functionality and reporting services, it will be possible to bake records management, with explicit classification, directly into SharePoint. In the next weeks (until my Office365 demo runs out) I will be experimenting and documenting my experiences implementing records management in SharePoint 2010. Stay tuned.
Monday, June 13, 2011
Checklists are not just for Adults
Whether in Emergency communications (#SMEM) or Information Technology management, I am a big advocate of clear communications via policy, procedure, tasks and checklists (The Checklist Manifesto: How to Get Things Right
). The other morning I was watching the Disney channel with my kids. They were watching a show called Special Agent Oso. It is about a special agent teddy bear who helps kids learn how to accomplish every day tasks with a checklist. They have "three simple steps", checked-off one at a time, complete with boxes and check marks). This show is teaching a new generation the usefulness of checklists.
). The other morning I was watching the Disney channel with my kids. They were watching a show called Special Agent Oso. It is about a special agent teddy bear who helps kids learn how to accomplish every day tasks with a checklist. They have "three simple steps", checked-off one at a time, complete with boxes and check marks). This show is teaching a new generation the usefulness of checklists.
Tuesday, January 25, 2011
Tuesday, August 31, 2010
Scribd
I found Scribd the other day. They currently are using flash but are moving to HTML5. I am intrigued by the idea of inline PDF viewing on PDF heavy sites. Need to explore this more.
Wednesday, August 18, 2010
Gozaic - Historic Travel Site
Ok, so I clicked on an advertisement the other day. I normally don't but I am glad I did. I found Gozaic (http://www.gozaic.com/). If is created and maintained by "Heritage Travel, Inc. a for-profit subsidiary of the National Trust for Historic Preservation is the company behind Gozaic, the dynamic online travel community where people find and share heritage- and culture-rich experiences. The mission of Heritage Travel, Inc. is to present travelers with a broad range of heritage destinations, sites and events that define our collective past and enrich our lives – and help them connect through places that matter." I have just begun exploring it but if you are into traveling to historic places, this is a must visit.
Subscribe to:
Posts (Atom)