Considering the technological breadth and depth of cloud which crosses every technology boundary and impacts elements in every layer, no one person can be a one stop solution shop. It will take time and experience, successes and failures, before even the smartest gain the insight to know instinctively what works and what doesn't. And therefore like all new grand experiments we need to start off with the soundest foundation we can which gives us the greatest flexibility to adjust as we learn.
Inherent in this approach is having two talents at our disposal: the cloud architect who views cloud from the business point of view as a technology implementation of a business process; and the blank. It's not a sexy term, the blank, but it's very appropriate. Most organizations have architects, or at least an architect, who is responsible for ensuring technology is implemented logically according to a master design which aligns with the business strategy. These architects are always focusing on the future with limited feedback on how things are working today. However I have yet to find a company or person whose sole job it is to identify and resolve issues and inefficiencies; someone focused on today and how to make things better in the future.
Today when an issue arises it goes to a committee of people: application and data gurus, infrastructure engineers, architects, security shaman. There is no role responsible for capturing a problem, identifying the cost of the problem, then resolving the problem if its worth resolving. As a result the tools we employ to identify and debug problems is deplorable. Our infrastructure teams have gone the furthest down this route in both methodology with ITIL and tools including instrumentation and health monitoring. What about the other three fourths of the world: applications, data, and integration?
Cloud computing only works when the user uses the application. Whatever process it is the user wants to execute must come to a complete and acceptable resolution for the user to continue using the application. Cloud solutions are inherently complex leveraging a dynamic set of services across a dynamic infrastructure with a combination of static and potentially dynamic data sources. Yet for the most part the only tools available for tracing the cause of a problem end at the boundary. If the process doesn't end at the boundary neither can the debugging. If we can't resolve the problem quickly the application provides no value to the user, and tolerance continues to dwindle.
Today we rely on the hero model; that really smart person or group of people who combine intelligence and experience to sweep in and save the day. In the cloud we need to reset that experience to near zero while at least doubling the breadth of the issue. Our only option for survival is to start emphasizing the need for robust tools. However without a focal point, a role whose success depends on such tools, the tools will continue to stop at the domain boundaries: infrastructure, applications, data, and integration.
We need the blank, or perhaps a better name is Quality Architect, a role across domains responsible for ensuring our systems can be debugged, our knowledge is increased and captured, and for being the person in charge when a serious issue arises.
Today it's a blind spot we survive by luck and hard work. In the cloud with it's ability to rapidly scale and morph, that blind spot will become a killing field with the careers of well intended but unsupported IT experts littering the ground.
No comments:
Post a Comment