On Forrester Blogs, John Rymer writes about multitenancy:
Despite resource sharing, multitenancy will often improve security. Most current enterprise security models are perimeter-based, making you vulnerable to inside attacks. Multitenant services secure all assets at all times, since those within the main perimeter are all different clients. Leveraging a mix of dedicated resources and metadata map architectures, these services can deliver stronger security.
From IBM’s Center for the Business of Government. InterAct and I are mentioned on pages 21 and 34.
RATHER THAN BEING A HAZY CONCEPT, THE CLOUD CAN BE AXIOMATICALLY DEFINED AND RIGOROUSLY ANALYZED THROUGH A NEW APPROACH CALLED CLOUDONOMICS
via Cloud Computing – Cloudonomics: A Rigorous Approach to Cloud Benefit Quantification.
Conversions are a costly and error-prone aspect of acquiring new CAD and RMS systems. Both CAD and RMS databases are often very complex and data elements don’t match perfectly. Standards and practices are often changed when new systems are implemented, often in ways that are incompatible with historical data. Nonetheless, most projects include a set of conversion tasks that are expected to overcome all such obstacles so that new systems contain all of the old data perfectly translated.
An alternative approach is possible and has some significant advantages. First, rather that converting all of the historical content of the retiring systems, a retrievable archive is created in a form (HTML or PDF) that can easily be retrieved based on a unique identifier and displayed. Since most systems already produce such documents, the effort involved is essentially one of automating the process. Even if a new formatting tool has to be introduced to create the archive, the technicians who do the work are freed from the problematic mapping of every data element.
The second stage of the process is driven by the functional requirements for retrieving historical data.
In CAD, when a call for service is processed, incident history is searched for relevant prior incidents associated with a location, proximity, person, telephone number, or vehicle. Either the archive may be indexed by these elements and searched when new calls are received, or “skeleton” incident records may be created in the new system that contain only the search criteria and the unique identifiers of archived incidents.
Records systems link persons, places, vehicles, property, and organizations via various forms of involvement in incidents. The master data and involvements must be recreated in the new RMS, but the incident records themselves need only sufficient data to support locating the archived details, and perhaps few additional data elements that are common search criteria.
A small number of incidents may be active at the time the new system cutover takes place. Since these may still be updated, they are not candidates for historical archiving. For most agencies, the effort to recreate these manually in the new system as necessary is far less than trying to automate the process. This also applies to the rare case in which an incident that is effectively closed must be reopened and modified.
Full conversions are sometimes the best approach. When the retiring system is well documented and data mappings are clear, conversion is preferred. However, it is often impossible to determine the challenges that will be encountered until the conversion effort is well under way. Incorporating the use of a searchable archive as an alternative approach in the project requirements, statement of work, and project planning reduces the risk that conversion will become a major stumbling block.
|
|
The 2012 NASCIO Survey includes the table shown here (I added the bar chart for clarity). Those describing themselves as “highly invested” only grew by 1%, but 65% more reported having some applications in the cloud and considering others. Furthermore, those still investigating dropped by almost 68%. In other words, 2012 has been a huge year for cloud adoption by state governments. The chasm has been crossed and the crowd is following the early adopters at an increasing rate.
 |
 |
“We don’t care what smart people think. there aren’t that many of them.”
Dilbert comic strip for 10/21/2012 from the official Dilbert comic strips archive..
Everyone in the public safety software business knows The Tiers. Agencies are ranked by population served. Vendors are classified according to their customers’ tiers. Exact definitions of the tiers vary but the concept is the consistent. Big cities are usually Tier 1. Some distinguish the largest cities as Tier 0, others include them in Tier 1. Small towns and rural counties are Tier 3, and Tier 2 is everyone else. Gartner group counts five tiers numbered 1 through 5. Dispatch Magazine simplifies, listing fourteen vendors in the top of only two tiers. Robertson and Associates also identifies fourteen vendors in the top two (of four) tiers, but only six are on both lists. Gartner lists fifteen “vendors to watch” most of which are on at least one of the other two lists. Most sources agree there are somewhere around 130 additional vendors in the lower tiers.
The conventional wisdom is that, near the top of the pyramid, massive projects must be undertaken at great expense and risk to deliver scalable high availability systems that meet unique and complex requirements. Even the best off-the-shelf products must be customized and tailored until every one of thousands of individual detailed requirements is met and verified. At the opposite extreme, small agencies have little choice but to get by with either low cost turnkey products or none at all. Those in between, unable to afford top tier solutions, choose from an abundance of second and third tier options in accordance with their budgets and their aspirations.
Like all conventional thinking, this sounds perfectly reasonable. But, conventions are essentially shortcuts based on repeating what worked in the past. In the midst of the seismic shift underway today in the foundations on which public safety system are built, doing what worked in the past is downright wrong. It is time to rethink our assumptions including the tiers themselves.
Public safety is highly decentralized in the U.S. Nearly every political subdivision has one or more agencies under its jurisdiction. Early computer applications were affordable only to only the largest agencies, and they mirrored the commercial data processing sensibilities of the period: custom systems built by large internal IT departments and large system integrators. As the cost of computing fell over the years, smaller agencies were able to acquire scaled down systems. Agencies and vendors entered the marketplace side by side in size order. To this day, the top vendors are the oldest and largest, mid-tier suppliers are mid-sized and middle-aged, and the lowest tiers are served by the youngest, smallest most geographically rangebound providers.
One of the results of the industry’s evolution was the stratification of solutions. The largest vendors structured their businesses around doing a small number of large projects, and were weren’t quick to adopt the less costly technologies that were affordable to newly arriving agencies. Likewise, vendors who entered the market with mid-tier solutions didn’t have the right skills or business practices necessary to capitalize on the market for very low cost PC-based products for the smallest agencies. Over the years, only a few vendors have moved up or down the tiers.
Imagine if we started over from scratch tomorrow, with scalable cloud computing and modern multi-tenant applications shared by hundreds of agencies and hundreds of thousands of users. Scalable fault-tolerant applications would be available to agencies of all sizes, and there would be no reason to build different products for agencies in different tiers. Of course the largest agencies would still have some requirements that the smallest would not, but these would simply be optional modules. The aggregate cost savings would approach ninety percent as the massive redundancy of on-premise hardware was eliminated, and sharing information would be as simple and natural as it is on Facebook.
Of course, no matter how appealing the vision might be, it can’t be achieved in a single giant leap. But we can begin the work of considering potential obstacles and the roadmap needed to get past them.
The idea that all extant business processes are essential and that the goal of information systems is to support them without modification flies in the face of reason, yet most large public safety software projects are conducted with this premise. In 1990, Michael Hammer of MIT wrote a now famous article on Business Process Reengineering in which he claimed that information technology has been overused for automating existing processes rather than using it to make work that is of no value obsolete. The private sector embraced the concept of during the nineties, achieved some great successes, and also learned some lessons, among the best of which was the idea of best practices. A best practice is a method or technique that has consistently shown results superior to those achieved with other means. One of the greatest benefits of large-scale shared information systems is that they encourage users to adopt best practices rather than solidifying ineffective processes by building systems around them.
Note: Needs that arise from truly unique circumstances sometimes don’t have applicable best practices. However, the discipline of always assessing best practices first is the user side of the technology dictum, “Never build what you can buy.” And for the most part, best practices are free.
Having over a hundred CAD companies in the public safety industry is just as redundant and inefficient has having a hundred CAD systems in a single state. The reason there are so many is that those that serve the smallest agencies have maintained their cost advantage over larger competitors by being able to provide on-site service for their customers. As public safety applications are migrated to the cloud, the smallest agencies will have access to high-end applications at less cost than the on-premise systems they have today. The advantage of being the local supplier will vanish.
But that doesn’t mean all the small companies will disappear If we imagine once again starting over with today’s technologies, the diminished importance of physical location would lead small businesses entering the market to become functional specialists rather than regional service companies. At the same time, the cloud offers larger vendors the opportunity to create not just products but platforms. One of the best examples of the power of platforms is from the mobile phone industry. When traditional phone manufacturers dominated the smart-phone business, devices came with half a dozen manufacturer-supplied applications. Apple changed the industry by making the iPhone a platform on which independent developers were encouraged to build thousands of applications.
We have seen these transformations in other industries, from banking to bookstores. Amazon become the leader in online retail not by creating a store that stocks every item in the world, but by creating a retail platform and opening it up to anyone, from individuals to large specialty shops to competitors in the media business.
It is inevitable that the public safety industry will reshape itself to reap the benefits of the new interconnected world of the cloud. The tides are too strong to resist and the benefits are too massive to be ignored. The new shape will be a cloud and at long last the pyramid and the tyranny of the tiers will take their place in history.
Cloud Bene fits for Public Safety Ironically, cloud adoption by public safety has lagged many industries for which the benefit are not nearly as great. The nature of public safety applications is such that the advantages of shared systems are greater in both cost and utility.
Public safety applications are increasingly interconnected to inter-agency, regional, state, and national systems and databases. Each premise-based system must be individually connected to each external system. Every pointto- point connection takes network engineering, interfacing, monitoring, maintenance, support, and may require time-consuming certi cations and audits. Shared systems come with shared external connections, live and pre-certifi ed.
Figure 3 shows a nearly 60% reduction in the number of interfaces required for 5 agencies to share information and to acquire data from 2 external sources. For 20 agencies, the improvement approaches 90%.
Figure 3 – Greater Connectivity with Fewer Connections
As new data sources and applications become available, the cloud model makes it possible to amortize the investment required (to make third-party plug-in services available to users) over the entire user population. With lower integration costs come greater incentives for the creation of new, innovative technologies. As the cost-benefi t of supporting third party services is enhanced by lower up-front costs, support for the add-on marketplace becomes a competitive advantage.
The cloud eliminates field service, enables vendors to do the work once for the immediate benefi t of all customers, and the subscription model gives them a powerful incentive do so. In theory, Service Oriented Architectures make plug-compatible open interfaces possible in premise-based client/server environments, but in practice, the need to support multiple installed versions of each such interface with a fi eld service workforce makes most cross-vendor integrations fi nancially unattractive, so they are only done when necessary to acquire new business. The investment must be repeated for each new version of each interface for each customer, and when customers aren’t up on the newest version of primary product, they can’t take advantage of the newest plug-ins.
In the same sense that state or national CJIS databases are resources, so are citizens who adopt public-facing collaborative apps, and the complexity and cost of connecting agencies and responders to such applications is orders of magnitude less when agencies use shared multi-tenant online systems.
What is the Cost of a Wrong Idea?
In a panel discussion at the 2012 International Association of Chiefs of Police conference, former San Jose Chief Rob Porter talked about a project:
The idea that a software application should let users do what they’re currently doing only in an automated fashion is fundamentally wrong and fantastically expensive. It’s an anachronism left over from the seventies, when corporate data processing departments cranked out COBOL code as fast as the finance department could come up with new variations of inventory reports.
In the same panel discussion, Keith Tribble, Executive Director of Enterprise Systems Development, U.S. Dept of Homeland Security asked, “Are you willing to go with an 80% solution and change your business processes to save ten, twenty, thirty percent a year?”
Henry Ford famously said, “If I asked customers what they wanted, they’d say faster horses.” This is not to say that customers’ desires aren’t important, but it was the standardization of the Model T that made modern transportation affordable.
The procurement process in public safety bolsters this especially deleterious wrong idea. RFPs contain thousands of requirements, the mindless composite of every user’s wish list, the equivalent of a faster horse with a lazy-boy saddle, zircon-encrusted stirrups, and a modem.
New tools benefit users who are willing to change the way they work to take advantage of them. Public safety users would do well to heed Chief Porter’s and Mr. Tribble’s advice. Find the best off-the-shelf solutions available and find ways to use them to their best advantage.