Introducing Brittle Computing
By Scott Andersen
My Amazon author page!!!!
I’ve spent the past two weeks discussing a topic on my other blogs and podcast. It is the concept of Brittle Computing. First off let me begin by saying that Brittle Computing is a concept that explains in part the reality of the new concept “design for failure.” But for the most part it is a rationale examination of why organizations are struggling with cloud computing today. It isn’t an application of brittle solutions to the reality of security and the cloud. It is an examination of the way solutions used to be and from that why there in fact may be some hesitation in moving forward.
As a concept Brittle Computing comes from the 1980’s. Before the birth of the Internet and Google/Ask/Bing/Yahoo and Alta Vista search engines. In fact it is that lack of an Internet connection that created Brittle Solutions. You had to have a good backup. If you didn’t and you upgraded there was nothing you could do except start over. In the time of Brittle Computing (B.C.) you didn’t run to a computer and search the Internet for an answer. You didn’t go download the newest drivers from XYZ company website.
You called a human being and talked to them on the telephone. They were remote and you worked through the potential answers. There were times when you would be the first organization to have the problem you were experiencing. That meant you would try a number of possible solutions hoping one worked. After awhile you would know what each support organization would want from you and you would do the first 5 or more steps before calling or while waiting on hold.
Worst case scenario you had to stop, restore and then start over. From Europe there was the concept of ITIL (and later MOF Microsoft’s adaptation of ITIL to MS products) and Cobit. Operations frameworks that took into account the what and how of operating your environment in a repeatable structured fashion. Call centers began growing adding decision trees and process flows to solve known problems. All of this because you couldn’t in the end embark on an upgrade without a backup.
Brittle meaning that the solution didn’t have the tinsel strength to withstand a load greater than design even for a short time. Brittle in the sense that there were specific controls and limits around the edges of the solution including 8, 16 and 32 bit applications. No matter how good your back-up was you were bound by the amount of data you could back-up in the window you had. Fragility of the solution was the reality of Brittle Computing.
It made you cautious to a degree. It created a mind set in many companies (either the WAN is always up or the WAN is always down) as to how they built solutions. It is that mindset that in the end has created Brittle Organizations. A Brittle Organization has two permutations that we should consider. The first is the fear of a solution failing. It is the ancestor of the Cloud concept , Design for failure. The other within the organization is the very cultural reality the organization is in. Be it the culture of late to the game (we are never the first to embrace new technology) or the more scary Shark Culture (where everyone is ranked against everyone else) the culture of organizations was greatly impacted by the reality of Brittle Computing.
I will post more on this topic soon. This initial post being the opening teaser…