Another Innovative use of Twitter to connect the public with public safety using “hyper-local” twitter accounts. Incidents, with a few exceptions, such as sexual assault, are tweeted on a one hour delay (to reduce gawking and interference with investigations). Of course, it being twitter, the creation of the neighborhood oriented accounts gives residents a point of reference to discuss happenings in their neighborhoods as well. Here is the New York Times Article via @KiwiChief.
In the SaaS model, a vendor takes responsibility for not only infrastructure, but also for all of the processes required to manage an entire application solution (patches, upgrades, backups, database management, systems tuning, performance management, etc.). Because SaaS vendors manage many customers on a small number of application instances, they can amortize infrastructure costs over many customers. In other words, the inherent savings of the cloud are compounded when many agencies share a single system.
| The terms Cloud and SaaS are sometimes (incorrectly) applied to hosted applications that are not multi-tenant. The benefi ts described here accrue from sharing resources. Simply hosting a dedicated system is insuffi cient. As traditional on-premise solution vendors move to the cloud, they learn that multi-tenant architecture is very di fficult, if not impossible, to retrofit into legacy applications. |
The software architecture of such shared systems is called multi-tenancy because a single instance of the software application serves multiple client agencies, referred to as tenants. Databases and configurations are partitioned so that each tenant’s user experience is identical to having a dedicated (rather than shared) system.
Because multi-tenant SaaS applications run on shared infrastructure, the incremental cost of deploying an additional customer is far lower. There is no hardware, operating system or database to purchase, no site preparation, no staging, and no delivery. By contrast, on-premise systems require an initial investment that leaves vendors no choice but to “front-load” costs. The SaaS model opens the door to pay-as-you-go subscription pricing. Of course, there are discounts for pre-payment and for multi-year contracts.
| The SaaS model ultimately provides the same type of products as a software licensing model – but with a better economic model, one that is lower in cost to the customer and structurally inclined to keep getting better for the customer with every new release. Scott Sehlhorst, Pragmatic Marketing, The Economics of Software as a Service (SaaS) vs. Software as a Product – http://goo.gl/T75dQ |
Hurwitz Group estimates that the four year total cost of ownership (TCO) for SaaS based applications is about one third of the cost of a comparable premise based application. But the cost-benefit of SaaS is even greater. Upgrading premise-based systems is expensive. A vendor may release new versions of an application several times per year, but most customers only upgrade when the version they have deployed approaches end-of-life, or when a new version has features that justify the upgrade cost. Except for a short time after initial installation and occasional upgrades, customers are deprived of the benefits of the newest features. Furthermore, because upgrades almost always skip multiple releases, they are disruptive and require retraining.
SaaS applications are upgraded more frequently and in smaller increments. Most such improvements require little or no retraining. All customers get the benefit of all upgrades the moment they are applied, and there is no upgrade cost.When most customers do not take advantage of most upgrades, vendors are encouraged to put most of their development effort into features that will enable them to acquire new customers. In the SaaS model, vendors’ profits depend on keeping their subscribers happy, largely through new features that benefit existing customers.
Mike Phibbs, of Richmond police, suggests an almost embarrassingly simple way of connecting beat officers with the communities they serve.
For the non-twitter-literate: A hashtag is a tag embedded in a message posted on the Twitter microblogging service, consisting of a word within the message prefixed with a hash sign, for example: “#usopentennis”. The hash (“#”) indicates that what follows is a searchable tag that indicates the subject of the message.
Phibbs writes, “Twitter could be used to connect citizens with the beat officers 140 characters at a time. By using the hash tag #Your Neighborhoods Name Here anyone can be instantly alerted to suspicious activities in the area. People can tweet a picture of the activity to officers, dispatchers and the rest of the community. The technologies allow everyone to be a crime fighter in their own way, as part of a neighbor action team or an individual who simply wants to improve their neighborhood.”
ConnectedCOPS.net – Law enforcements partner on the social web.
Forbes reports AlertLogic’s survey of 70,000 security breaches indicates:
“…on-premises Web application systems get hammered more frequently with attacks, the study shows. The average number of web application attacks is 61.4 among on-premise customers and 27.8 on service provider customers. Brute force attacks and reconnaissance attacks were also experienced with higher frequency in on-premises environments.”
The U.S. Federal Government has adopted a “cloud first” policy[1] that requires agencies default to cloud-based solutions whenever a secure, reliable, cloud option exists. The National Institute of Standards and Technology (NIST) has issued a three volume Cloud Computing Technology Roadmap[2] and initiated a standards acceleration program so that best practices from the private sector can be used for government systems immediately, without a protracted standards process.
The motivation for this unprecedented initiative is clearly economic. Figure 1 shows the cycle of excess and insufficient capacity inherent in premise-based systems, versus how cloud based infrastructure scales quickly to meet, but not exceed, demand.
Figure 1 – Elasticity of Infrastructure as a Service
A Booz Allen Hamilton Study[3] (Figure 2) compared the cost of 1000 premise based servers with equivalent capacity in public, hybrid, and private cloud environments. Their findings show that shared infrastructure alone results in 50-70% life cycle cost savings. Furthermore, the cost of the cloud itself is decreasing dramatically. The cost to run a basic Internet application on LoudCloud in 2000 was $150,000 / month. Running the same application on Amazon today costs $1500 / month, two orders of magnitude less. It is a conservative expectation that we will see still another order of magnitude reduction within the current decade.
Figure 2 – Cost Advantage of Shared Infrastructure
All of these cost benefits accrue from the migration of systems infrastructure from premise to cloud, or Infrastructure as a Service (IaaS). Even greater savings and benefits are possible when platforms and applications are migrated to the cloud.
[1] Federal information technology shared services strategy – http://goo.gl/fNdFK
[2] NIST Special Publication 500-293, US Government Cloud Computing Technology Roadmap, Release 1.0 (Draft), Volume I High-Priority Requirements to Further USG Agency Cloud Computing Adoption – http://goo.gl/CPmQR; NIST Special Publication 500-293, US Government Cloud Computing Technology Roadmap, Release 1.0 (Draft), Volume II Useful Information for Cloud Adopters – http://goo.gl/qLebx; NIST US Government Cloud Computing Technology Roadmap Volume III – Technical Considerations for USG Cloud Computer Deployment Decisions (First Working Draft) – http://goo.gl/skV2Q
[3] Booz Allen Hamilton, The Economics of Cloud Computing – http://goo.gl/wPSLE
Is competitive bidding the best way for public safety agencies to buy software solutions? This question is rarely asked. The RFP process is simply a way of life for buyers and sellers in the public safety software business, ostensibly because competitive fixed price bidding assures that vendors will offer their very best prices.
While many would defend this view, few would argue that the industry as a whole is innovative, or that service levels are of the highest caliber. Customer satisfaction is generally low. Is it possible that a process designed to obtain the lowest price might diminish an entire industry’s capacity to deliver the highest possible value?
Research indicates that competitive bidders, “…may perform poorly when projects are complex, contractual design is incomplete and there are few available bidders. Furthermore, competitive tendering may stifle communication between buyers and sellers, preventing the buyer from utilizing the contractor’s expertise when designing the project.” (Incentives and Award Procedures: Competitive Tendering vs. Negotiations in Procurement, Tadelis, Bajari) Certainly, public safety software projects meet these criteria. The authors suggest that in such cases, characterized by uncertainty on the part of both buyer and seller, negotiated purchases may result in greater value delivered.
In the bidding process, buyers are responsible for defining requirements, but lack the necessary time or information. Requirements are cut and pasted from others’ RFPs, or vendor-supplied lists, resulting in two problems:
Real requirements are missed. Even the best efforts to gather users’ requirements come up short because processes and workflows change, and new requirements invariably emerge.
Unneeded features become requirements. An unfortunate bit of conventional wisdom holds that extra features do no harm. Wrong! Feature-bloated products are not just a little overweight; They are morbidly obese and unhealthy. Every feature adds complexity and increases the cost of vendors’ development, support, and service, and of customers’ installation, training, and maintenance. Furthermore, excessive complexity reduces usability and makes users less efficient.
When vendors are forced to develop and support features that aren’t needed, they do so to the detriment of features that have greater value to users. They create unnecessarily costly products that are difficult to use and administer.
In a negotiated purchase, buyer and seller are motivated to work together to discover the minimum set of requirements that meets the buyer’s needs fully at the lowest reasonable vendor cost and customer price.
Consultants are often hired to assist in the development of requirements. Unfortunately, they carry long wish lists from one engagement to the next, essentially cross-pollenating RFPs to the point where every known requirement appears in every RFP. This minimizes the consultants’ time and effort, but leads vendors to charge for extraneous features, and to waste their development effort on features their customers don’t need.
Unnecessary expansion of the scope of procurements is another unintended consequence of the bidding process, especially when costly consultants are employed. When each trip to market costs thousands or even hundreds of thousands of dollars, the buyer is encouraged to fill the shopping cart to the brim.
Buyers end up replacing multiple applications before the end of their useful lives because one system is on its last legs. The lower procurement cost of negotiated purchases enables buyers to go to market more frequently and to realize the benefits of right-timing their purchases.
Vendors know that requirements are incomplete, bloated, and often inaccurate. But because they must offer fixed price proposals anyway, they pad their bids to make room for anticipated changes. In some cases, the most qualified vendor loses on price. In an even worse scenario, a low bidder is awarded the contract and ultimately fails or performs poorly under the financial pressure of an unprofitable project. In a negotiated purchase, the padding, risk, and procurement cost are all reduced.
RFP requirements are supposed to serve as measurable performance criteria by which the supplier’s performance is verified. They are not, simply because they are not nearly specific enough or objective enough.
The ambiguity favors suppliers to the extent that arbitrators or courts cannot verify delivery or failure to deliver, and vendors are incentivized to presume the least costly interpretation of vague requirements. Negotiated procurement enables the refinement of requirements and acceptance criteria from an informed perspective.
It is easy to manipulate the outcome of what appear to be competitive procurement processes. It is generally accepted in the vendor community that most bids are “wired” for a predetermined vendor. They are not rigged to the extent that they would be judged fraudulent, but prior to the formal procurement process, the preferred vendor will typically feed requirements to buyers that favor their offerings, often providing complete requirements documents (ask any vendor if they have an “RFP template” for their products). Having chosen a preferred vendor and written the requirements to match their capabilities, all that remains is to recruit predestined losers. Informal vendor consensus holds that the win rate with no pre-procurement “influence” is in the low single digits.
Negotiated purchases are not inherently non-competitive. Many states, government councils, and cooperative groups of buyers conduct full competitive procurement processes that make it possible to work openly and cooperatively with pre-qualified vendors to:
· Negotiate contracts that fit the buyer’s real requirements;
· Eliminate the cost of unneeded capabilities;
· Provide for inevitable refinement of requirements;
· Eliminate extraneous time, effort, and cost of the bidding process.
When possible, a negotiated purchase from a reputable vendor has the potential to be more efficient, less contentious and wasteful, and to deliver far greater value.
At the very least, smart buyers should:
1. Include an assessment of negotiated purchase options in their procurement process. Explore existing contracts, reciprocal purchase vehicles with other jurisdictions, the Federal GSA schedule, and options such as extending an existing contract with one agency to include others.
2. Consider the full cost of a competitive procurement; not just the price of the consultant and out-of-pocket expenses, but also the cost of the inefficiency of a process that is known to be poorly suited to nature of the purchase. Effectiveness is diminished and costs are increased every day that users have to live with a feature-bloated product that is poorly matched with their real requirements.
Public safety agencies and vendors have long suffered under the current procurement system. Those who can’t avoid traditional competitive procurement can at least recognize and take measures to mitigate some of the pitfalls. Ultimately, a process is needed that acknowledges and manages uncertainty rather than denying its enormous effect. Negotiated procurement, where applicable, goes a long way in that direction, and offers the additional advantage of leading to significant cost savings.
Steve Yegge defines software liberals and conservatives here.
He writes:
… Software engineering has its own political axis, ranging from conservative to liberal.
(Note: Technically, you could stop reading right here and be at pretty much 90% comprehension. In case you care.)
Put another way, YOU are either a liberal or a conservative software engineer. You may be more of a centrist, or maybe an extremist, but you fall somewhere on that left/right spectrum.
He goes on to define conservatives as risk-averse, strong typing extremists, overly concerned with performance, and liberals as undisciplined lisp or javascript meta-programmers that (gasp) use eval().
Not surprisingly, I find myself on both sides of the fence. I’m a language liberal, but a performance conservative. Oh well, I don’t fit either political party either. But, I have noticed over the years, that my “moderateness” has changed. I used to try to embrace both sides. Over time I find myself decreasingly tolerant of them both (in politics and programming). Dogmatic adherence to a predefined doctrine is intellectual laziness, and antithetical to progress. In my experience, anyone who is not a skeptic or at least ambivalent is selling something.
##
The U.S. Federal Government has adopted a “cloud first” policy that requires agencies default to cloud-based solutions whenever a secure, reliable, cloud option exists. The National Institute of Standards and Technology (NIST) has issued a three volume Cloud Computing Technology Roadmap and initiated a standards acceleration program so that best practices from the private sector can be used for government systems immediately, without a protracted standards process.
The motivation for this unprecedented initiative is clearly economic. Figure 1 shows the cycle of excess and insufficient capacity inherent in premise-based systems, versus how cloud based infrastructure scales quickly to meet, but not exceed, demand.
A Booz Allen Hamilton Study (Figure 2) compared the cost of 1000 premise based servers with equivalent capacity in public, hybrid, and private cloud environments. Their findings show that shared infrastructure alone results in 50-70% life cycle cost savings. Furthermore, the cost of the cloud itself is decreasing dramatically. The cost to run a basic Internet application on LoudCloud in 2000 was $150,000 / month. Running the same application on Amazon today costs $1500 / month, two orders of magnitude less. It is a conservative expectation that we will see still another order of magnitude reduction within the current decade.
Figure 2 – Cost Advantages of Shared Infrastructure
National AED (Automated External Defibrillator) Registry provider Atrus, announced it will collaborate with PulsePoint, developer of a CPR Notification App. According to their announcement, “The partnership allows data stored in the National AED Registry, a free AED program management tool, to seamlessly flow into the PulsePoint app in real time.”
