SATURN 2011 Session: Agile and Architecture (afternoon session, May 18, 2011)

Notes by Peter Foldes

Agile Architecture: What the Agile Architect Can Learn from a Hurricane Meteorologist
Eric Richardson, Chemical Abstracts Service

– Overview of CAS
– Analogy and some terminology
– etc.

– Division of the American Chemical Society
– Education and world authority on chemical information
– Analyze and index chemicals

Why meterology and architecture
– They are both similarly complex, lots of interaction.
– Meterology has a longer history.

Technique for the agile architect
– Not recipes
– Way to use fundamental craft

Predicting the future
– Timeliness in spite of incomplete information
– There’s a false dichotomy of agile development and architecture
– Reasons for the tension: upfront design vs getting something done

Adding agile to the architecture
– The way we approach analysis and design needs to be changed.
– Takes too long, speed is important; agile team is not going to wait.
– Architecture should be treated as a forecast.
– Create a projected path; evolve the architecture.
– More imporant to be right on your first step than on the last.
– Just have a path, being wrong is still okay.

Hurricane hunters
– Meteorologists don’t have time to take ocean surface temperatures. They don’t have the time to take temperature readings.
– Same with architects, they need more data.
– Code diving is useful and good.
– As you hire developers, you want someone who can identify problem and fix it.
– If plan is not followed there might be problem with communication or the plan itself.
– Hurricane hunters are not just technical people, they know and understand business goals and are experienced people.
– An indication of change might be from a sales engineer about a competitor => A network of communication channels is important.
– Use communication channels (like weather stations) and the collective knowledge.
– Monitor and adjust; a decision made yesterday might not be right today as context changes
– Adjustments are hard things to balance. Constantly evolving architecture is bad; not changing enough is similarly bad.

Influences and impediments: Separating the different kinds of changes
– hurricanes are limited by shearing winds; like corporate culture
– Cultire: 12 meetings and much bureaucracy for approval of this talk.
– Extreme risk aversion against changes; too much risk in trying out new methods if, for example, developers don’t know it.
– Technical inertia: Application silos; self healing – self reinforcing. It’s hard to break down a silo.

Architects can influence cultures
– Meteorologists can go and blow at a hurricane, but architects can sit down in a room with a few people and bring in change.
– Engage leaders and cultivate consensus.
– Disagreement: Great moderating force

– Treat your architecture as a forecast; it will change
– Scope out the cone of uncertainty.
– Engage the people who can promote change.

Covert Use of Architecture for Rapid, Agile Product Development
Robert Curry, IEEE


– Some perception
– Where are we on the hype cycle
– How to trick engineers
– Examples

Context (on missle systems)
– These are pleasurable products, if you’re the one pulling the trigger.
– Most products follow a pattern; they have a rocket, a payload, and so forth. Getting out of this pattern is hard.

PM’s perspective on architecture:
– Is it new? No, it was just not in focus
– Does it save money? Well, there’s not much data. Community would gain a lot with more to show.
– Does it reduce risks? Maybe
– Do customer’s require it? Tough question to answer; architecture is hard to sell.

Engineer’s perspective:
– We have done this for 60 years, we know how to do it.
– Suspicion: only a new title? They don’t understand it, therefore they are suspicious of it.
– Artifacts produced are not usable for them directly, although SysML, UML helps. This creates an architecture chasm.

Trick engineers:
– They need multi-disciplined team to iterate on solutions.
– Methodology to “trick” them

  • Get project context definition. Talk about what they want to do and how, with all stakeholders involved. (output: requirements, assumptions)
  • Get operational context. Does it make sense to build it? How? (output: OV1, OV6 views for example)
  • System concept development. Each discipline helps to flush out the system design concept. Many decisions are made. Representatives of different disciplines can use their team, but the reps work very closely with other representatives.
  • Build and test the system.
  • Design definition (look at costs and risks, make sure artifacts are updated)

– Whole process 3 days to 3 weeks
– All stakeholders are involved -> they become evangelists
– More robust system is designed, architecture just comes out of the end as an artifact


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s