In 1961 at the MIT Centennial, John McCarthy opined “if computers of the kind I have advocated become the computers of the future, then computing may someday be organized as a public utility just as the telephone system is a public utility…. the computer utility could become the basis of a new and important industry” [1]. In 2006, Amazon Web Services was launched providing computing on a utility basis. Since that time the notion of cloud computing has been emerging and evolving.
Cloud computing is a paradigm that makes the notion of utility computing a reality. Instead of Information Technology (IT) organizations investing in all of the hardware, software and infrastructure necessary to meet their business needs, cloud computing makes access to hardware, software and infrastructure available through the internet, generally utilizing a pay for use model. Basically cloud computing allows an organization to adopt a different economic model for meeting IT needs by reducing capital investments and increasing operational investments, a model which is likely to offer cost savings to many organizations.
There is still a great deal of hype around cloud computing, as many vendors have their marketing engines further into the clouds then their technology supports. Despite this Gartner predicts that by 2012 one in five businesses will not own its own IT assets. [2]. In late 2010 the Office of Management and Budget (OMB) under direction from the White House told federal agencies that starting in 2012 they are expected to consider cloud first “whenever a secure, reliable, cost-effective cloud option exists.” [3]
There are certainly many reasons why an organization would consider moving at least some of their IT functions into the cloud. In addition to potential cost savings the cloud offers the possibility of increased availability, easier collaboration, lower capital costs, scalability and virtualization. There are of course concerns as well. The technology is still relatively immature with no definitive set of standards for interface or compliance with regulations. Businesses lose hands on control of their IT resources with little recourse if their IT vendor shuts down or goes out of business. Additionally, there are security and data privacy concerns. There is also the fact that not all ventures into the cloud will be cost effective for the business.
This paper introduces the concept of cloud computing and discusses the potential benefits for a business as well as those things which could be barriers to adoption. It examines the types of applications where cloud computing is an efficient cost effective solution and the types of applications where its use could be problematic or costly. Several examples of successful cloud implementations are presented and discussed.
For a white paper describing this reearch on cloud computing email info@pricesystems.com with the code word CLOUD in the subject line. To share your cloud computing experiences comment on this post
Since I don’t really follow college basketball closely during the year I make my picks somewhat randomly – loosely based on the teams' standing but occasionally predicting an upset. Naturally, the upsets I predicted were not based on knowledge of who is injured or how well a given team plays in certain situation. I really do it for fun and to be social – not really expecting to win.
I’m guessing most people have a more sophisticated method of making their picks – an analysis of the performance of the teams throughout the season, or maybe the last several seasons, the records of the coaches and information about current circumstances that may impact a particular team's ability to perform at their peak. In other words, most people attempt to perform some sort of data driven predictions. Based on their analysis of the data they develop a model to predict the future. I’m guessing that in most cases there is also a non-analytical aspect to picks – focusing on a favorite athlete, favorite school or long held rivalry. Some picks are based on the future; the way you want it to occur may not be what is most likely. Maybe it just happens that this year the real dreamers get to win (as well as those who pick unconsciously).
Here’s another question – what if our picks were made through an entirely analytical process – would we have been better off this year or not? Check this out – The Official 2011 March Madness Predictive Analytics Challenge – a contest where the bracket is composed entirely of picks generated by computer algorithms. It will be interesting to see how this data driven approach with all favoritism and gut instincts removed will fare – I’ll be watching.
The concept of the fuel cell was first published in 1938 by Christian Friedrich Schonbein. Based on this publication Sir William Grove invented the precursor of the fuel cell in 1839. The Grove Cell created current by applying two acids to zinc and platinum electrodes separated by a porous ceramic pot. In 1842 Grove developed the first actual fuel cell which produced electricity with hydrogen and oxygen, much like many fuel cells in use today.
Fuel cells remained an intellectual curiosity until the 1960’s when the US space program identified a requirement for extended life batteries for which fuel cells seem to offer a promising solution. The focus on green technologies has increased interest in consumer uses of fuel cells for transportation, residential and commercial power supply, emergency backup power and portable power supplies for consumer and battlefield applications. Increased usage of any technology begs the question of how to address the costs associated with that technology.
A fuel cell is an electrochemical cell which converts some fuel, usually hydrogen, into electric current. It does this through a reaction between the fuel and an oxidant in the presence of an electrolyte. The waste product of this chemical process is water and heat. Fuel cells, unlike conventional batteries, consume reactant from an external source rather than one stored in the battery. They do require a continuous supply of fuel, but given that this supply is available, they will not run out of charge like a conventional battery.
Because fuel cells require neither flame nor combustion to convert fuel to electricity, there is much hope that they will become a viable power source of the future as we try to reduce our carbon footprint. Fuel cells are very reliable and less likely to be effected by the environment as some more conventional power delivery systems are. Because of this they are being adopted in industries such as the telecommunications where outages are particularly problematic. They are often considered for power generation in remote areas where energy from the grid is expensive and outages are frequent. Because heat is a waste product of the fuel cell electricity generation process, micro combined heat and power systems are gaining popularity for residential and small business needs. Other interesting uses of fuel cell power include material handling, backup power systems and uninterruptable power supplies.
Despite increases in the use of fuel cells, they continue to evade wide spread use because they are expensive. Certainly significant progress has been made through increases in efficiency and improvements in manufacturing processes, but it is still more expensive, in most domains, to get electricity from fuel cells than from more conventional methods. According to a report from the Department of Energy in May 2010, high volume automotive fuel cell stack cost has been reduced from $275/KW in 2002 to $61/KW in 2009 and appear to be on track to reach the $30/KW goal by 2015. The same report indicates a 24% increase in system power density for stationary fuel cells making it possible to reduce the fuel stack volume, weight and cost.
PRICE recently conducted a research effort using publically available data to develop cost estimating relationships for various types of power systems utilizing fuel cell technology. For a white paper describing this project and the resulting cost estimating models email info@pricesystems.com with the code word FUEL in the subject line.
Last year the conference occurred shortly after Congress passed the Weapons System Acquisition Reform Act of 2009 (WSARA) - and the majority of the sessions were focused on discussions about how the services, contractors and the government leadership planned on dealing with this new law. From the agenda, it looks like this year there will be much discussion of how these plans were executed; what worked and what didn’t. Topics range from will cost and should cost analysis, cost efficiencies, earned value management, quality data, affordability analysis, and other topics of interest to the acquisition community.
There will be an address by the Honorable Christine Fox, Director of the OSD Cost Assessment and Program Evaluation office (OSD CAPE) as well as a session with the Cost Directors of each of the Services. Shortly after her appointment as CAPE Director, Ms. Fox addressed the attendees of DODCAS 2010 with her plans going forward. She described the US Budget process and illustrated where the CAPE will fit in that process. She discussed WSARA and its intended benefits and the challenges it presents to the CAPE and the cost community as a whole. And finally she addressed the issues associated with acquiring, training and retaining the necessary human resources to support the CAPE and the objectives of WSARA. I found her talk interesting, informative and hugely relevant to what I do every day. I’m looking forward to her address this year and learning about CAPE successes, challenges and lessons learned.
Have you attended DODCAS recently? What cost estimating and analysis conferences are the staples in your training budget?
Hmmm….. There’s probably some statistics about how many folks in a population of 1100 software measurement and process professionals are also experts on English honeybees. Or maybe not, but it’s a good guess that a lot of them don’t know the first thing about honeybees and even fewer are apiologists (one engaged in the scientific or systematic study of honeybees). And yet they were comfortable estimating with certainty with no questions asked.
Certainly, one must recognize that for these software professionals, answering a question about honeybees posed during a presentation at a conference or symposium or the like, clearly does not carry the same implications as preparing an estimate for an actual piece of software being developed or considered. Nonetheless – one would like to think that these software measurement and process people, when asked to estimate, would actually think like estimators.
Because you can literally do anything with software, software estimators are often asked to perform estimates for features or technologies that are nearly as unknown to them as English beehives. They need to stay on their toes and resist the urge for complacency. They need to have good tools like TruePlanning to guide them through the questions to ask and help them quantify the impacts of uncertainty.
A fuel cell is an electrochemical cell which converts some fuel, usually hydrogen, into electric current. It does this through a reaction between the fuel and an oxidant in the presence of an electrolyte. The waste product of this chemical process is water and heat. Fuel cells, unlike conventional batteries, consume reactant from an external source rather than one stored in the battery. Because of this they require a continuous supply of fuel but in the presence of this continuous supply they will not run out of charge like a conventional battery.
Because fuel cells require neither flame nor combustion to convert fuel to electricity, there is much hope that they will become the power source of the future as we try to reduce our carbon footprint. Unfortunately, fuel cells have yet to be widely used because they have yet to be cost effective in any wide spread way. And while there has been talk for years about the promise of fuel cell powered cars – this also has not come to fruition because of the costs of the fuel cell and the lack of infrastructure to support hydrogen refueling.
There are some areas where fuel cells are gaining purchase. Fuel cell power is very reliable and not as likely to be subject to effects of environment and weather as conventional power delivery systems. Because of this they are being adopted in industries such as the telecom industry where outages can be problematic. They are also used for power generation in remote areas where energy from the grid is expensive. Because heat is a waste product of the electricity generation process, micro combined heat and power systems are gaining in popularity for residential and small business uses. Other interesting uses of fuel cell power include material handling (forklifts and such), backup power systems and uninterruptable power systems.
Portable power is also an interesting application for fuel cells. The Medis 24/7 power pack is a commercially available fuel cell power system for recharging laptops, cell phones and iPods. It lasts for hours and is approved for use on aircrafts. Portable power for soldiers in the battlefield is often supplied with fuel cells which traditionally weigh less and last longer than conventional batteries.
This research is on-going. There is still lots to learn. Check back here for more information as it unfolds. If you have any experience with fuel cells, especially with costs of fuel cells, feel free to share.
But I digress; I really wanted to share my thoughts about the lessons learned, challenges and opportunities in the software estimation world. I think the most significant lesson learned (in my 25 years at least) is that the more things change, the more they stay the same. We continue to experience project failures. We continue to let requirements grow and blame the software folks. We continue to plan based on unproven impacts of silver bullets. Mostly, we continue to disregard what history should be teaching us. And if we don’t start to take our history seriously, things will be the same 25 years from now.
I think the biggest challenge that estimators face centers not around the mathematical or scientific but rather around issues of credibility, acceptance and successful negotiations. Many project failures are the result of poor negotiations between the business and the project leadership. Reasons for this include: failure to successfully communicate the complexity of the project, unrealistic schedule expectations forced on the project team, over-optimistic predictions of the project team. And (in case I haven’t said this before) failure for the business and the project to learn from history and negotiate geometrically using the project management triangle.
OK – so far I am pretty much repeating the sentiments of a fellow panelist (Dan Ligett) “We’re doomed!” Dan, of course, did not stop there but offered some encouragement going forward. I will attempt to do the same. You might have noticed that I believe firmly that much of the problems in the software industry are rooted in our inability to learn from and/or believe the lessons that history has taught us. Data really will set us free. The opportunity is for the estimation community to collaborate and cooperate in order to provide paths for historical data to usefully and credibly inform future actions. We need to look for ways to facilitate the sharing of data and models that will help the community at large make it possible to grow the practice of well informed, thoughtful geometrical decisions based on well developed, history informed estimates.
Here’s a cool project. The Bloodhound Project is focused on building a land vehicle capable of breaking the 1000mph speed barrier. The mission of the project is twofold. The first is to “overcome the impossible using science, technology, engineering and mathematics”. But the second is more interesting – this project is intended as motivation for the upcoming generation to embrace technology related fields. Britain doesn’t have enough students interested in such fields and they are worried about their ability to compete in technological forays going forward.
But how much should something like this cost and how could they possibly figure it out? There is no historical data on which to base an estimate – no one has ever done this before. And of course, they are currently in trouble, expecting the cost to rise above the 6.6m (British Pounds) original estimate for researching, designing and building the vehicle So just for fun I thought I would look at the project from a parametric perspective. I did a quick search to determine the weight of the car (6 tonnes or 13228lbs), made some assumptions about the complexity and engineering difficulty, and ran the whole lot through the TruePlanning for Hardware Model. While the technical information I was working with was scanty – I was able to come up with an estimate of 8.6m (British Pounds). Hopefully, for the project team, my assumptions on complexity were overstated and the project completes successfully within the original estimate. Regardless it certainly is a creative, if somewhat expensive, way to grow new engineers
Project problems abound; delays, turnover, scope creep. Management concerns are palpable. Estimation exercise supports successful scope, schedule, cost negotiation. Another rabbit out of the hat.
All social commentary aside, this notion of hint fiction drove me down the path of what other things might benefit from a few hints. Naturally I thought of project management. Suppose every project manager picked a few metrics that would be easy to track, quick to calculate and would give them a hint if a project started to go south. Well in truth, this is what good project managers do (till now they’ve just been calling this Good Project Management - descriptive I suppose but so old school).
- Effort (hours charged to the project so far or in a given time period)
- Productivity (Hours per LOC or FP)
- Duration (calendar months since project has started)
- Requirements creep (# of requirements added or changed)
- Number of tests
- Defects discovered
- Defects corrected
- Percent of requirements complete
- Percent of requirements accepted by customer
Well run, tightly scoped projects with little scope creep and excellent project and change management practices are less likely to suffer from the ambiguities outlined above. (How many of us work on one of these every day?) These of course are the projects least likely to run out of control in the first place. The things that make a project risky are the things that make it easier to misread what EVM is telling you, creating an allusion of control for a project which has little. It is unwise to rely on EVM results as the only measure of a project's health, rather, one should heed Millaly's suggestion that blind adherance to earned value could cause your project to crash and burn.
To be honest, when I first wrote the abstract for this talk – I was really looking for a catchy title so the conference reviewers would pick my paper. Not that I didn’t believe that SOA governance was critical, but I knew that all governance was important and it felt a little disingenuous and self serving to just focus on SOA governance.
But as I was presenting this topic, it hit me how critical governance is to a SOA initiative. SOA is successful when the enterprise realizes savings through reused assets and all of the benefits that come with business agility. Without good SOA governance this will only happen in pockets of the organization at best. Organizations that purchase SOA technology and then continue to develop “SOA” in silos – are not realizing these benefits. SOA Governance ensures that decisions on SOA projects are made with knowledge of all of the SOA initiatives in the organization, not just within a certain aspect. It makes sure that projects are coordinating their needs for services and taking advantage of existing services (internal and external) while composing SOA applications.
Alert readers are undoubtedly now lauding me for my flair for the obvious. And you are absolutely correct. All that I said above should be perfectly obvious to anyone involved in or contemplating adventures into the world of SOA. Despite this fact, in our research we have talked to a lot of people who struggle to keep from developing ‘stovepipes of SOA’ and a fair amount who have conceded the battle. Taking this into account along with the fact that I (who thinks about this stuff a lot) needed to be reminded, I figured this was a blog worthy topic.
To learn more about PRICE’s research in the governance area, download the webinar "Estimating the Costs of Service Oriented Architetcure" or read the whitepaper "Estimating SOA".
Joint Confidence Level (JCL), NASA’s current best practice for program planning and management, also presents a circuitous conundrum. When a program has a JCL of 70% this implies that there is a 70% confidence that the cost will be at or under X$ and the program will be completed at or before Y months. Much time and effort has been invested in developing methods for performing JCL using lots of different mathematical and statistical processes. But many of these methods and techniques ignore a rather important aspect of cost and schedule estimating – schedule drives cost and cost drives schedule.
This fact does not make JCL analysis impossible. It merely means that cost and schedule risk analysis cannot be performed in vacuums. Rather than calculating a JCL we should be trying to converge on cost/schedule pairs that meet specific JCL requirements.
Next week I will be attending the 2010 NASA Cost Symposium in Kansas City, MO. Because JCL is such a hot topic with the NASA cost community, nearly half the program, including my own talk, is devoted to this topic. Lots of great work is being done in this areas. I encourage anyone with interest to attend if they can or follow up with conference materials when they become available later this month.
The reason I think it’s important to share this is that so many of us in the cost estimating community rely heavily on expert judgment as a means to perform or validate estimates. On page 48 of the paper a section entitled “Experts have a High Opinion of Their Own Opinions” begins. In this section the authors describe an experiment where researchers took a group of smart people (Harvard Business School students) and asked each to estimate high/low range numerical answers to several questions in such a way that they had a 98 percent chance of being correct and a 2 percent chance of the correct answer falling outside the range they selected. So for example “I am 98% confident that tomorrow’s temperature will be between 50 and 120% F”. There were no limitations on the ranges they could select and yet the students failure rate was close to 45%. Similar studies have had similarly lackluster results. To paraphrase the authors’ conclusions….
“We over-estimate what we really know while underestimating the possibility of our being wrong.”
The author is quick to point out, and I completely agree, that this is not evidence that all expert judgment is not valid, just a warning to those who depend exclusively or significantly on expert judgment. No estimation should be done in a vacuum. The more methods (parametric cost estimation included) used to arrive at an estimate the more credible the estimate and the higher the confidence level in that estimate.
Earlier this week I conducted a webinar intended to make PRICE users aware of the Cost Research Services available to them as part of the license fee they pay to use PRICE products. I thought I would recap the highlights of this webinar for those of you who might have missed it.
At PRICE we understand that cost estimating tools, while useful and valuable, do not always present the complete solution. Every single cost estimation projects presents new and unique challenges. We think it's important that in addition to solid, time trusted cost estimating models, our users have access to the many years of experience we have as seasoned costestimators, subject matter experts and operations researchers.
This service is nothing new. For the 30 years that PRICE has been in existence, we have worked as partners with ourcustomers to optimize their use of our models and methodologies. This was just an opportunity to formalize the offerings and remind the community what services are available.
So what does the Cost Research team at PRICE have to offer the cost estimating commmunity? On average our researchers have more than 24 years of experience with hardware estimating, software estimating, operations research or some combination of the three. We are constantly engaged in cost research projects addressing market needs as they arise. The results of these studies vary depending on the need they attempt to address. In some cases, data collection indicates custom models should be developed. These can be developed and deployed in TruePlanning, the flexible cost estimating framework. Some results are published as updates to tables or calculators in the PRICE Software and Hardware cost estimation models. White papers, webinars and the PRICE blog are all means we use to communicate the results of cost research studies.
PRICE's Cost Research Team is available 24/7 to address users cost estimating question on an as needed basis. Some issues require more attention than a single phone call. Users are encouraged to schedule working sessions with one or more of our analysts to take a deeper dive into cost estimating issues that perplex or intrique them.
Some areas the team is currently studying include Total Ownership Costs, Joint Confidence Level, Performanced based models for technologies such as FPGAs and ASICs, semi-rigid cables, and Operations and Support costs for space systems.
The most important thing the cost research team at PRICE wants to do is make our clients better estimators while adding value to the cost estimating community as a whole. We can't do this without input from our clients. Share your cost estimating challenges with us. Call, email or comment on our blog. 856-608-7201 or info@pricesystems.com
Software project falures coupled with rapidly changing business needs are forcing organizations to revisit the way they go about buiilding software. Agile development has emerged as one possible solution to the woes of the software industry. Agile enthusiasts claim significant increases in productivity and quality, while detractors cite instances where the reverse is true. It seems to me that probably both are right - some of the time anyway.
Agile means many different things to different organization. There is a long list of agile tenets but not every method of agile applies all of them. And some organizations have cultures which adapt well to agile methods while others don't. All of these things affect the 'success' of applying agile practices to your organization.
Personally I don't think that most agile practices inherently improve productivity. The long term application of agile within a cohesive development team should definitely improve their productivity but this would probably be true of the same team if they were applying some other philosophy.
I do, however think there are agile practices specifically focused on improving the quality of the software that is delivered. My list follows.....
Test Driven Development No code is written until there is a test. Business Analyst build tests that coders use to determine if the code meets the requirement. Only enough code is written to make the test pass. As code is refactored (improved) over time, the test remains to ensure that subsequent changes do not degrade the initial requirement.
Continuous Integration and Automated Testing Builds are run with each change to the code base or at regulalry scheduled intervals during the day. Suites of automated tests are run against each build. When tests fail making them pass because a number 1 priority of the test
Pair Programming All production code is written by two coders one at the key board and the other navigating, correcting and thinking of better solutions. Sort of like just in time peer reviews. Pairing occurs regularly throughout the development - with no set pairs but rather pairs that make sense at the moment. Driver and navigator roles should shift often.
Customer involvement Customers (or their surrogates) actually participate on the development team helping the business analysis develop the right tests and testing and reviewing the frequently released versions of the software
While these practices are included as tenets of agile, a shop need not be 'agile' (in the purest sense of the word) in order to incorporate one or more of these quality focused practices into their software development processes.
To read more about Agile practices and software quality check out my article in Software Tech News
Despite the plethora of literature on Technology Readiness Levels (TRLs) it remains a difficult concept. I thought I would share my interpretation,
For most of us the concept of technology readiness is hard to grasp. This is because in general, our experiences with technology are with fully matured technology. In 1961, President Kennedy challenged US scientists, mathematicians and engineers when he announced that within the decade of the 1960s the US would ‘land a man on the Moon, and return him safely to Earth’. At the time, there were no solutions to solve problems such as reaching earth’s orbit and traveling to the moon, let alone for how man would be able to survive in space. Some very smart people and creative thinking was needed to invent solutions that didn’t exist in order to make Kennedy’s dream a reality.
One of the many things that these smart people discovered was that programs envisioned when the technology is very new or non-existent are much harder to plan for than programs using technology that has been used successfully on other programs. As the possibilities for the space program greatly outsized the budget for space programs this fact became increasingly problematic. In 1974 Stan Sadin of NASA developed Technology Readiness Levels as a methodology to assess the technology readiness of a proposed spacecraft design. Eventually the methodology was institutionalized by NASA and later similar methodologies were developed by the US Department of Defense (DoD) and other organizations responsible for the acquisition of complex aerospace and defense programs. TRLs are used by NASA and the Departments of Defense worldwide to support go/no-go decisions at various acquisition milestones.
Here's how I like to simplify TRLs.....
Level 1 => Back of the napkin sketch
Level 2 => Idea confirmed as both good and useful
Level 3 => Idea proven possible
Level 4 => Idea proven to present a realistic solution
Level 5 => Alpha version of technology
Level 6 => Beta version of technology
Level 7 => Release candidiate ready for operational test
Level 8 => Technology has gone gold
Level 9 => Technology used successfully in target environment
Failed software projects are always bad but there are additional complications when there is a contract in place to deliver the software. Disputes over failed software can result in costly litigation that generally damages both the vendor and the buyer. According to observations of Capers Jones in "Conflict and Litigation Between Software Clients and Developers" (2007) , 5% of the projects his clients were involved in either had litigation pending or were currently involved in litigation over project failures. His findings indicate that it is very large projects, over 10,000 Function Points that are most prone to litigation, which makes sense if you consider the relative increased complexity, as well as the large amount of money such a contract would involve. Although one occasionally hears of pending litigation over software projects in the news, determining the background and outcomes of such litigation is difficult because they involve large customers and software contracting organizations, both of whom would rather keep their failures out of the spotlight. This is likely a significant contributor to the fact that such litigations still occur since the industry is denied opportunities to examine and learn from the mistakes of others.
A report in Computer World [6] details a law suit filed by health insurer Highmark against KPGM for malpractice, fraud and brief of contract for a software system that Highmark had outsourced to KPMG. While the article does not detail the outcome of this lawsuit, it makes it clear that the disagreement stemmed from misunderstandings and the failure of the two organizations to communicate and collaborate.
In light of this I have compiled a list of four responsible actions that both bidder and buyer should engage in when software projects are outsourced. These may seem like common sense and the same old story, but clearly they bear repeating......
1. Create and Communicate Good Requirements ... misunderstood, constantly changing and new requirements are a common source of angst in software development projects. Bidders need to understand the buyers requirements, document them fully, and incorporate the risk of requirements growth into their plans
2. Create and Maintain a credible cost estimate - the buyer needs to know what the effort should cost to evalute bids. The bidder needs to properly assess the cost to them in order to make the project profitable and to avoid having the project cost them money
3. Understand and document risks; Plan up front for risk mitigation - bidders should work with buyers to understand their uncertainties. These uncertainties need to be incorporated into the estimate and documented in the contract.
4. Create and maintain a cooperative relationship... when bidders and buyers collaborate and work nicely together, bumps in the road and set backs are handled sensibly, reducing the possiblities that things get out of hand.
Recently I was interviewed by Doug Beizer of Federal Computer Weekly for an article about the shift of government agencies away from custom software development and towards the use of cloud computing. The interest in this topic seemed to stem from the introduction of Apps.gov online store earlier this month.
Having been in the software cost estimation community for more than 25 years, I have experienced this transition first hand but never really stopped to think about the whys and wherefores until questioned by Doug. It was an interesting stroll down memory lane. As an example, just think for a minute about how much communication has changed. When Ifirst started working if I needed to discuss something with a co-worker or friend I either needed to pick up the phone or pick myself up out of my chair and go talk to them. If I wanted to leave a paper trail – I actuallyneeded to use paper. There was no internet, no e-mail, and certainly no social networking. Like everyone else,government agencies needed to develop custom application to meet specific communication, networking and other needs. Because the government had many communication needs – both on the business and mission side – government agencies became a leader in developing these types of applications.
With the advent of the Internet and ever evolving forms of social networking, the commercial sector has been forced to get really good at developing communication software – so good that the government agencies are nowl ooking more and more to the commercial sector and the cloud for such capabilities. Not to say that all government needs can be solved with commercial solutions, but many more so than back in the day. And while communication capabilities are my favorite example, let’s face the fact that there’s a lot of software out there– many of it that’s completely adequate (if not superior) to meet the needs of the government.
Powered by Compendium