The IT problem
Oftentimes, IT and the mental baggage that accompanies connotatively is sufficient to fill executives and management staff with dread. A sense of impending doom can pervade when hundreds of man hours are spent in planning disaster recovery scenarios, not to mention the sizable implementation cost of those plans. At the same time, everyone involved must cross their fingers in hopes that those plans, however effectively laid, never need execution.
The need to execute a "disaster recovery" plan implies a "disaster" has occurred. Frantic phone calls, dissatisfied clients, 2:00 AM meetings, and the like become the order of the day (night?). In a best case scenario, no data is lost, and only a moderate amount of service interruption has occurred. IT may see this as a plan successfully executed. Perhaps management may as well. However, the savvy among them will see a tarnished relationship that persists long after.
Ironically, in a best case scenario, a failure never occurs. In this case all of the time and cost in planning and execution is effectively wasted. It becomes an expensive learning exercise for those involved.
In a worse scenario, subsequent to a failure, IT staff is eviscerated for problems they may or may not have even been able to do something about. What can follow these failures may be a return to complacency, patiently awaiting the next event, albeit with heightened nerves and a strained relationship. Luckily, this is no longer the year 1998, and real solutions to these problems are within reach for those who care to solve them for good.
In the modern day, software defined data centers have swiftly changed the roles of IT and development. In a world where development can provision functioning resources with a few clicks or API calls, cloud providers or frameworks take care of many of the tedious and labor intensive IT tasks. No one likes waiting a week for a database server to be ordered, installed, imaged, domain-joined, backed up, and going through the IT initiation rites before hardware is christened as "ready". Not to mention, simply by organizational conventions, usually only one team can be tasked with such an undertaking, introducing a built in bottleneck to the process.
- introduce a democratic system or democratic principles to
- make (something) accessible to everyone
Democratization of IT is the ability to bring these capabilities to others within the organization. This has the capability to greatly accelerate development cycles and improve the overall stability and reliability of a software system.
When mentioning reliability and the cloud, one may counter with the argument that cloud systems are not always entirely reliable themselves. I would mention that in fact, by virtue of being built by humans in the first place, they are fallible by nature. All systems can fail. What sets apart a real cloud system is the ability to recover and work around failure whether machine or human induced. It can all be done without the once-sacrosanct rituals involved with IT ops of bygone eras.
The software solution
What takes the place of those ancient rituals is proper initial planning from a software architecture perspective of handling faults appropriately. Some of this can be handled at a framework level, some within application logic, but in general it is all definitively non-manual. In most of the commodity cloud database and storage products, transparent and geo-redundant replica functionality has existed for years. These built-in features greatly reduce the effort necessary to plan for failure. Combined with other reliability features guarding against "soft failures" involving human error and data loss, the storage and compute proposition of the cloud is compelling.
The remaining task is then to find the proper party who can put the abilities of the cloud to work for whatever your specific need is. IT staff is often not up to the task, as software changes may be necessary to take advantage of platform features. Development, on the other hand, ought to be keen on the idea of being able to improve reliability and scalability all at once.
A properly engineered software application can handle failure of underlying components without significant interruption, surfacing issues that have occurred simply as blips in a log file. Failures such as "a hard drive going out" or "a backup went missing" simply are taken out of the equation. If you've heard those lately, it's time to reevaluate the architecture holding up your business.
If the weakest link in your IT chain is a few lowly hard drives, or that one "critical" machine, rest assured it will fail. Just don't rest too deeply, you've got a 2 AM wakeup call on the way.