July 2007 Archives
The august edition of Wired has a long article on the disappearance of Jim Gray, earlier this year. Steve Silberman worked diligently on this article and interviewed many people including Donna Carnes, Jim’s wife. I like the article because it focuses more on Jim as the technologist, friend and mentor than on the technicalities of the search after his disappearance.
He remains lost without a trace.
2.223 million pre-orders on our sites world-wide. 1.4 million on Amazom.com alone. These orders trickled in over the period of 5.5 months, but from a distributed systems perspective today is the day as these orders go en-masse from pre-orders to orders, being charged and delivered. It is one smooth operation. The planning for single day delivery is truly impressive, especially on the supply-chain, transportation and fulfillment side where we need to do this without impacting the regular delivery flow. 1.3M books are being delivered today weighing close to 1700 tons. The excitement that our customers have for this book absolutely rubs off on anyone involved with the process and it was absolutely marvelous to see the kids run out of their houses when the UPS truck arrived in our street.
When I was building one of my first teams at Amazon, one that had to work on some really advanced distributed systems technology I put up a job description on this weblog. I was certainly pleased with the responses. Last year at a conference I heard from some of my former academic colleagues that they were using this description to educate their students abput where they were lacking in knowledge or experience. “Werner’s requirements” were used to explain to them that if they wanted to work on one of the really interesting distributed systems of this world, they better recognize the importance of [insert some random topic]
There are only a few engineers at Amazon who work directly for me and I currently have a job opening for such a position. It has most of the requirements from the previous description, but in this role there is more emphasis on analysis and modeling. If you are interested and you feel you qualify you can apply online at the Amazon careers site for job # 025213 or send email to the address on the right column of this page.
This is a job with some really tough requirements but it is an important job as you will have direct influence into how systems are build at Amazon and that is something we take very serious.
Senior Research Engineer in the Office of the CTO
Amazon.com's website is the most well-known front end to one of the world's largest and busiest service-oriented architectures. Its systems requirements are very challenging: maintain high-availability and guaranteed performance in an ultra-scalable fashion while being very cost efficient. From webpage rendering to order pipeline workflow, from data-warehouse to distributed caching, all require unique solutions. Many of these solutions require significant innovation: often these challenges have not even been addressed in research in a production setting at the scale of Amazon.
I was putting together a short panel presentation on the role of a Chief Technology Officer in corporate innovation and I once again realized that there is quite a bit of confusion around the role of the CTO. The first thing that always comes up when you want to discuss the role of a CTO is that there is no well established definition of what a CTO actually does. The role is very different depending on the type of company and the role technology plays in the company.
Some time ago I did some digging into the history of the CTO roles and how to best classify them. I am posting it here as it might be of general interest. Some of the sources I used are at the end of this note.
When John Brockman, founder of Edge, interviewed Nathan Myhrvold his first question was “What’s a CTO”, to which Nathan replied:
“Hell if I know. You know, when Bill and I were discussing my taking this job, at one point he said, Okay, what are the great examples of successful CTO's. After about five minutes we decided that, well, there must be some, but we didn't have on the tip of our tongues exactly who was a great CTO, because many of the people who actually were great CTO's didn't have that title, and at least some of the people who have that title arguably aren't great at it.
My job at Microsoft is to worry about technology in the future. If you want to have a great future you have to start thinking about it in the present, because when the future's here you won't have the time. “
The first CTOs came onto the scene during the late eighties. A number of companies started to capitalize on the results their R&D laboratories were delivering and the directors of these labs were moved into positions where they could use technologies to provide the company with strategic advantages. The role developed into very different positions and there are several ways how to categorize them. There are good reasons for following any of the categorization models, but I believe Tom Berray’s quadrant gives the best framework for reasoning about what makes CTOs successful:
Infrastructure Manager – In companies where the role of the CIO becomes too complex, the CTO takes on the responsibilities for infrastructure and IT operations: data center operations, network operations, application development and maintenance, security, and other line functions. The CIO retains the responsibility for how technology is actually used within the organization. This is mainly a model used in traditional businesses where IT is in a pure support role.
Technology Visionary and Operations Manager – This pattern is usually found in dot.com and other technology-oriented companies where information technology is key ingredient in implementing business strategy. The CTO is responsible for determining how technology can be used to implement the business strategy. This is the ‘technology visionary’ aspect of the role. But then subsequently, the CTO is responsible for actually integrating and running the technology, i.e. the role of the ‘operations manager.’ In this pattern the CTO is often a co-founder of the business, or one of the first hires.
External Facing Technologist – We see this model often in companies where technology is used to provide products and services to customers and partners; the CTO is the intermediary between clients and internal development and the main influencer in the development of the product portfolio. The CTO is in constant contact with key customers and is prominently involved in market research. Some of the larger software companies have successfully used this model with multiple CTOs who are seasoned technology experts and whose main task it is to be the bridge to customers. A number of CTOs of software companies in the middleware space have also described the customer contact as their main activity.
Big Thinker – The CTOs in this model mainly spend their time evaluating how technology can be used internally to developed new business models and business lines, and how to preempt competitor’s attempts to use technology to disrupt the markets. This CTO’s responsibilities often include advanced technology, competitive analysis, technology assessment, prototyping lab, partnering, planning, and architecture standards.
In the first two models the CTO directly manages an engineering division and much of his/her influence in the organization is exerted through technology development in their own organization. I have met CTOs who manage divisions that had 500 - 1000 engineers or more.
In the last two models the CTO has a role in which he/she needs to influence other divisions to execute on new directions. To guarantee this level of influence the CTO is often part of or close to the executive team, often reporting to the CEO. The CTO does supervise a small team (typically 10-50 engineers, depending on the size of the company) that functions as an incubator for high risk technology directions.
Below are some sources. Not all are good, but together they paint a reasonable picture and give you a good starting point for further research.
- Aspatore Inside the Minds Series, Leading CTOs
- Mark Minevich, The CTO Handbook
- Tom Berray and Raj Sampath, the Role of the CTO: Four Models for Success
- Roger Smith, the Role of the Chief Technology Officer in Strategic Innovation, Project Execution, and Mentoring
- Roger Smith, 5 Patterns of the Chief Technology Officer
I omitted the Dynamo reference from the previous collection, but now that the SOSP program is live:
Guiseppe DeCandia, Deniz Hastorun, Madan Jampani, Gunavardhan Kakulapati, Avinash Lakshman, Alex Pilchin, Swami Sivasubramanian, Peter Vosshall and Werner Vogels, “Dynamo: Amazon's Highly Available Key-Value Store”, to appear in the Proceedings of the 21st ACM Symposium on Operating Systems Principles, Stevenson, WA, October 2007.
The final version needs to be camera ready by August 9, I will see whether the ACM allows us to put it online at that time.
Update: The paper is online at "Amazon's Dynamo".
I recently gave a few talks in which I gave some reading advice to the audience and I promised to follow-up with posting the links here.
The first article is the interview of Michael Stonebraker by Margo Seltzer in the May/June edition of ACM Queue (unfortunately the article is online yet, but this link seems to work thanks to Peter O’Kelly). One of the points Mike makes is that almost everything in the data management world has changed dramatically over the past decade: applications, operating environments, hardware architectures, but that databases management systems have stuck to the one-size-fits-all architecture from 25 years ago. He goes into several examples why there is a need for different approaches to address application needs and to exploit hardware advances.
I refer to this article in my talks as it resonates strongly with my experiences. Even if you would only take a narrow look at scalability and reliability requirements you can see that the traditional database architectures have clear, well understood, limitations. There are many data patterns at application level that can be served by simpler data storage systems, for example applications that only need to access their data store through a primary key (promotion for this product, shopping cart of this customer, thumbnail image of this product). One can develop storage technologies that specifically address this category of applications and that have excellent scalability and reliability properties and are very cost-effective.
The second reference is a presentation by Richard Gabriel where he lays out a time model of traditional software adoptions: “Models of Software Acceptance: How Winners Win”. I use the data from this presentation for two purposes: the first to show that for companies such Amazon, who require technologies to address scaling needs that have not even left the research labs yet, it is essential to accelerate this adoption model through active involvement with productizing research results. Most often these advanced research results will come from our own product teams. The second point is how service oriented software development can help break through the traditional barriers.
A paper I refer to often is “From Push to Pull – Emerging Models for Mobilizing Resources” by John Hagel and John Seely Brown. This paper describes the shift in economic models to deal with uncertainty in demand and growing consumer power, etc. At Amazon we are addressing these new realities with our web-scale computing services. On-demand, pay-as-you-go, connectable services are key in the “Pull models” that are arising in many different economic areas.
I use Richard Conniff’s “Limits of the Alpha Male” as an easy intro into self-organizing systems and how in real life self-organizing is a proven concept. For any truly scalable agile environment, self-organization is essential.
I then use Steve Grand’s “Creation:
Life and How to Make it”
