vision

Architects: manage risk like a Vegas bookie

In the world of cloud computing, “risk” is a big buzz word. Lots of analysts are debating how much risk is involved in using SaaS offerings like Salesforce, or hosting corporate applications with a public IaaS provider like Amazon’s EC2. They’re worried about outages (Amazon’s had several ugly ones, most recently for 49 minutes in January), about security, about regulatory compliance, and so forth.

Werner Vogels, Amazon CTO, NextWeb 2008: "Everything fails, all the time."

Werner Vogels, Amazon CTO, NextWeb 2008: “Everything fails, all the time.”

These worries are well founded. However, I pointed out today on Adaptive Computing’s blog that the question “Can I take the risk to use the cloud?” is a bit naive. Sometimes you can just avoid risk altogether. In many cases, however, risk is endemic, and the smart course is to manage it.

How does risk figure in your architectural vision? You should think about it all the time. You should count it, weigh and balance alternative outcomes in ways that would impress even the gaming industry.

Here are 6 key questions to kick-start your pondering:

  • Is my architecture properly accounting for risk of environmental problems such as DDOS, routing failures, brownouts, and temporary loss of an internal component? (See my article about circuit breakers.)
  • When one of my components crashes, will its state be cleanly recoverable (e.g., on transaction boundaries) rather than corrupt? What data loss contract am I targeting?
  • Will it be easy for users or admins to notice when theoretical risks I’ve planned for become true emergencies? How will they be notified?
  • Is it possible to put the system in a “scabbed” state that’s degraded and safe, but functional, while more extensive repairs take place?
  • Am I assuming success too often? (Werner Vogels, Amazon’s CTO, is fond of saying “everything fails, all the time.” That’s on my top 5 list of major insights to remember.)
  • Am I diversifying intelligently, and enabling my customers to do so as well?

Action Item

Make a list of a handful of important risks from your customer’s perspective. How many of them can you help with?

Related articles

Smart Geeks Think Like Cheerleaders

Technorati code: FMUS579NQBM8

Saturday I went to a high school half an hour north of our home, to watch my 16-year-old daughter compete in a cheerleading competition. And I learned something about software.

Photo credit: neys (Flickr)

I’m not sure how many teams were there–maybe a hundred. The competition started at 9 am and was scheduled to run through 5. Every team consisted of dozens of girls, all dressed in spangles and glitter, with identical ribbons in their hair. They’d march out onto the floor, drop their heads and arms to their sides, and wait for the first blast of music to initiate the routine. Then they’d tumble and dance their hearts out, finishing out of breath with a flourish.

Every hour or so, the performances suspended so judges could announce winners in a particular division that had just fielded its last competitor.

I noticed a pattern. Even though I have no knowledge of competitive cheer scoring, I could tell who had won. Continue reading →

Why

Recently I’ve been digesting Start With Why, by Simon Sinek (Another nice find, Trev!) For an overview, watch his TED talk.

Maslow’s hierarchy of needs. A person’s “why” can derive from any of these levels, but I think I’ll be happiest if I can map mine to the top of the pyramid.

I don’t buy everything in the book, and I think many of the author’s assertions would be stronger if he offered detailed evidence. For example, he asserts that Apple is special because it has a driving “why” that shapes company decisions in fundamental and pervasive ways, and glosses over how Apple lost its vision during the non-Steve-Jobs years.

Why “why”?

Nonetheless, his central premise is insightful and important: starting with “why” we do things will create greater satisfaction, wisdom, and success. Once we have a why that’s correct in our hearts, many of the whats and hows of life flow naturally. Sacrifice, patience, and creativity blossom. This is true of our software architectures, product requirements, general business activities, personal relationships, and other endeavors. People who hate their jobs often feel that way because they find their days filled with activities that they deem empty or soulless. Human beings can’t be passionate about stuff that doesn’t resonate with their deep values to some degree.

I find interesting resonance between Sinek’s thesis and other important ideas such as Jim Collins’ hedgehog concept, the idea of laddering in marketing theory, Maslow’s hierarchy of needs, and Covey’s “begin with the end in mind.” I also find it interesting how congruent this is with a central tenet of Bridging the Communication Gap, by Godjko Adzic; he argues that the “why” of a product requirement, rather than the “what”, is the most important thing for product management to articulate. (Thanks, Shawn, for the great book recommendation.)

My Why

Which leads me to this: I need to articulate and then be true to my own “why.” Why, exactly, am I in the software industry? What do I hope to accomplish? Why do I work on enterprise software, as opposed to mobile apps or cool web mashups? Why did I start a blog? Why do I pick certain topics for my posts, and then spend significant time articulating my thoughts?

Here’s my current answer:

I believe in making complex computing simple so the world can innovate and improve.

Testing My Answer

What I like about this answer is that it ties back to my core values. I believe we have opportunities to do lots of good in the world–eradicating poverty and disease, advancing science, learning to understand and value one another better. And I believe an impediment to that is all the complexity we create and discover. Big data is hiding a lot of the insight that would let companies serve customers better. Number crunching supercomputers are needed to predict the weather better, to help predict crop yields in Bangladesh. And so on.

Thus, if I can do my part to make really tough computing problems more tractable, I’m helping make the world a better place.

I also like that this answer tells me when I’m wandering. If I’m building systems that don’t hide/manage/solve complexity, I’m probably off track. If I am building software that’s frivolous (“Angry Birds” comes to mind), I probably won’t be very happy. If I work for a company that aspires to nothing more grandiose than making money, I should either change the company or change my job. If my blog posts don’t help me understand or communicate on topics that reinforce that goal, I’m wasting my time.

Challenge

What is your “why”? Struggle with it until you come up with a satisfying answer. Then use it to test your current work assignments. Does this exercise give you any insight or point to ways to rebalance your priorities?

Related articles

Earned Pragmatism

The other day I was on Gene Hughson’s blog (he’s a smart guy, btw; I recommend a visit), and I noticed a badge that said that he had signed “The Oath of Non-Allegiance.”

That piqued my curiosity.

I followed Gene’s link and ended up on Alistair Cockburn’s website. Alistair is one of the early torchbearers for the agile software movement. I’ve written previously about signing the Agile manifesto, so I felt like I was swimming in friendly waters.

The oath is about being open-minded and pragmatic:

I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation.

In other words, let’s examine ideas on their merit, rather than dismissing them because they don’t align with the programming or process or architecture or platform buzzword du jour.

I signed. Good stuff.

However, the oath got me thinking a bit, and I want to register two notes of caution.

Caution 1: It is possible to be too pragmatic.

On the continuum that has “ivory-tower idealism” at one end, and “pragmatism” at the other, I’m well past center, favoring the pragmatic side. However, we should not discount the value of idealism. It was pragmatists who found enough compromise to ratify a constitution that made a loose confederacy into the United States of America–but it was the firebrand idealism of folks like Thomas Paine that articulated a vision, inspired a previously fragmented public, and provided the heat to carry the revolution through its darkest winters.

You need both.

I have seen architects that are way too ivory-tower. They make recommendations based on their favorite patterns and methodologies, with little regard for practical consequences. Smart engineers quickly dismiss them as being out of touch and irrelevant, and they are right to do so.

On the other hand, I have seen “architects” who, despite deep talent as engineers, are forever in the mode of “whatever gets the job done” and “if it ain’t broke, don’t fix it.” I believe this view is short-sighted; it loses touch with the opportunity cost of sub-optimal decisions, and with the human passion that keeps architectures healthy. Codebases owned by this type of “architect” tend to be rife with tech debt, with no roadmap or process to haul the team up and out. Where there is no vision, the people perish.

Caution 2: Pragmatism must be earned.

Before you can be a pragmatist, you have to understand what’s possible, what’s good and bad about each alternative, and why certain considerations might trump others given a certain business context and time horizon. This perspective doesn’t come cheap; it’s been my experience that only the school of hard knocks teaches these classes, and the tuition is expensive.

I mistrust anyone who lightly dismisses OO or message passing or actors or whatever the technique is, on the basis of shallow prejudice–but I also mistrust anyone who picks and chooses from the smorgasbord based purely on convenience of the moment. As Oliver Wendell Holmes said, “I would not give a fig for the simplicity this side of complexity, but I would give my life for the simplicity on the other side of complexity.” Unless you truly wrestle with the complexity, pragmatism can degenerate into cheating and chaos. Or said another way: only seasoned idealists earn the right to be pragmatists.

Action Item

Consider where you fall on the idealism~pragmatism continuum. Advocate the opposite end of the spectrum with yourself in a mental debate; do you have anything to learn from those who position themselves differently?

Related articles

George and the Flood

Here’s a simple little test that teaches an important lesson. Take a moment to work through all 3 questions. I promise it won’t take long. :-)

 
 

Question 1. A flood is coming. George can only swim for a little while. What should George do?

Screen Shot 2012-12-09 at 12.27.01 PM

 
 

Question 2. A flood is coming. George can only swim for a little while. What should George do?

Screen Shot 2012-12-09 at 12.28.05 PM

 
 

Question 3. A flood is coming. George can only swim for a little while. What should George do?

Screen Shot 2012-12-09 at 12.28.43 PM

Ready to grade your answers?

The Yellow Belt Answer

Most people say “go right, toward higher ground” if picture 1 is the only input to their analysis. The logic is pretty indisputable. But…

Continue reading →