Agile Architecture Myths #4 Because you are agile you can change your system fast!

Agile designers embrace change. But that doesn’t mean change is always easy. Some things are harder to change than others. So it is good to know how to explain this to impatient product stakeholders, program managers, or product owners when they ask you to handle a new requirement that to them appears to be easy but isn’t.

Joe Yoder and Brian Foote, of the Big Ball of Mud fame, provide insights into ways systems can change without too much friction. They drew inspiration from Stuart Brand’s How Buildings Learn. Brand explains that buildings are made of components organized into shearing layers. He identifies six layers: the site, the structure, the skin, the services, the space plan, and physical stuff in the building.

Each shearing layer has its own value and speed of change, or pace. According to Brand, buildings are able to adapt because faster changing layers (e.g. the services layers and spaces) are purposefully designed so to not be obstructed by slower changing layers. If you design your building well, it is fairly easy to change the plumbing. Much easier than revising the foundation. And it is even easier to rearrange the furniture. Sometimes designers go to extra efforts to make a component easier to change. For example, most conference centers are designed so that sliding panels form walls that allow inside space to be quickly modified.

Brand’s ideas should’t be surprising to software developers who follow good design practices that enable us to adapt our software: keep systems modular, remove unnecessary dependencies between components, and hide implementation details behind stable interfaces.

Foote and Yoder’s advice for avoiding tangled, hard-to-change software is to, “Factor your system so that artifacts that change at similar rates are together.” They also present a chart of typical layers in a software system and their rates of change:

Frequently, we are asked to support new functionality that requires us to make changes deep in our system. We are asked to tinker with the underlying (supposedly slower changing) layers that the rest of our software relies upon. And often, we do achieve this miraculous feat of engineering because interfaces between layers were stable and performed adequately. We got away with tinkering with the foundations without serious disruption. But sometimes we aren’t so lucky. A new requirement might demand significantly more capabilities of our underlying layers. These types of changes require significant architectural rework. And no matter how matter how agile we are, major rework requires more effort.

Because we are agile, we recognize that change is inevitable. But embracing change doesn’t make it easier, just expected. I’d be interested in hearing your thoughts about Foote and Yoder’s shearing layers and ways you’ve found to ease the pain of making significant software changes.

Who Defines (or Redefines) Landing Zone Criteria?

Who should be in on discussions that set landing zone criteria? Because most landing zone have architectural implications, someone knowledgeable about the system architecture, in addition to the product owner and other key stakeholders should have a lot to say in vetting a landing zone.

Someone who has depth, breadth, and vision, is an ideal candidate for crafting an initial cut. But even if you are brilliant, I suggest you fine-tune your landing zone with a small, informed group. If you have lots of stakeholders who want to chime in, give each stakeholder group a voice in identifying qualities and values they find particularly relevant. And ask a representative from each stakeholder group to join in on a landing zone discussion. At a landing zone review, expect healthy discussion. Experts are usually highly opinionated as well as passionate.

You might even want to facilitate your discussions.

I find it much more effective to have an informed facilitator guide landing zone discussions, than a dispassionate, uniformed professional facilitator. An ideal landing zone meeting facilitator should know about the program or product but need not be the “authority” or definitive “expert”. It’s more important that they know the landscape and they are good at gaining consensus and getting the best out of individuals who hold strong opinions. Possibilities: chief business architects, quality leads, the program or product manager, yes, even a software architect.

Sometimes a facilitator needs to step out of that role and offer informed opinions. I find this highly desirable, as long as this shift is made clear: “Hang on, do you mind if I take a stab at explaining what I think are more reasonable targets?”

Minimum, target and acceptable values should be agreed upon by the group and it might take some discussion to reach mutual understanding and consensus. For example, someone might initially propose a set of landing zone values based on historical trends and extrapolation. The software architect could push back with values based on prototyping experiments and new benchmark data. The group might end up adjusting targets because that evidence was compelling. Or, they might agree on tentative values that need to be firmed by an expert. Hammering out numbers just to finish the landing zone isn’t the goal. Instead, you want to shape ideas for what you think will make your product a success based on the best evidence you have, backed up by experience and tempered by group wisdom. To effectively do this, people need to come to the discussion with mutual respect, trust and no hidden agendas.

And if you are agile, recognize that your landing zone can and should recalibrated once you learn more about what’s possible.

Landing Zone Targets: Precision, Specificity, and Wiggle Room

A landing zone is a set of criteria used to monitor and characterize the “releasability” of a product. Landing zones allow you to take product features and system qualities and trade them off against each other to determine what an acceptable product has to be. Almost always these tradeoffs have architectural implications. If you’ve done something similar in the past, the criteria you should use to define your landing zone may be obvious. But for first time landing zone builders, I recommend you task someone who knows about the product to take a first cut at establishing landing zone criteria that is then reviewed and vetted by a small, informed group.

A business architect, product owner, or lead engineer might prepare a “proposed landing zone” of reasonable values for landing zone criteria that are questioned, challenged, and then reviewed by a small group. On one program I was involved with, the chief business architect made this initial cut. He was a former techno geek who knew his technical limits. More important, he had deep business knowledge, product vision, and had a keen sense about where to be precise and where there should be a lot of flexibility in the landing zone values.

Some transaction criteria were very precise. Since they were in the business of processing a lot of transactions, they knew their past and knew were they needed to improve (based on projected increases in transaction volumes). For example, that transaction throughput target for a particular business process was based on extrapolations from the existing implementation (taking into account the new architecture and system deployment capabilities). This is a purposefully obfuscated example:

Example Landing Zone Attribute
Characteristic Minimum Target Outstanding
Payment processing transactions per day 3,250,000 4,000,000 5,500,000

Some targets for explicit user tasks were very specific (one had a target of less than 4 hours with no errors, and an outstanding goal of 1 business day). On the other hand, many other landing zone criteria were only generally categorized as requiring either a patch, a new system release, or online update support. The definitions for what was a patch, a release or an online update were nailed down so that there was no ambiguity in what they meant.

For example, a patch was defined as a localized solution that took a month or less to implement and deploy. The goal was eventually to get closer to a week than a month, but they started out modestly. On the other hand, a release required coordination among several teams and an entire system redeployment. An online update was something a user could accomplish via an appropriate tool.

So, for example, the landing zone criteria for reconfiguring a workflow associated with a specific data update stream had minimal and target values of “release” and an outstanding value of “online update”.

When defining a landing zone for an agile product or program, carefully consider how precise you need to be and how many criteria are in your zone. Less precision allows for more wiggle room. Without enough constraints, however, it’s hard to know what is good enough. The more precise landing zone criteria are, the easier it is to tell whether you are on track to meet them. But if those landing zone criteria are too narrowly defined, there’s a danger of ignoring broader architecture and design concerns in order to focus only on specifically achieving targets.

We live in a world where there needs to be a balance. I’ll write more about who might be best suited to defining and redefining landing zones in another post.

Agile Landing Zones

In my last post I introduced the idea of landing zones, a set of criteria used to monitor and characterize the “releasability” of a product. A landing zone contains system attributes that must be achieved to declare “success” along with their minimally acceptable, ideal target, and outstanding values.

If you’re unfamiliar with landing zones, one concern you might have is the size of a landing zone. How many discrete system characteristics can you reasonably expect to track? At first blush, you might expect that the more complex a product or system, the more attributes should be tracked.

But an agile mindset leads me to a different answer: You don’t want to keep your eye on too many dials and gauges. It’s simply too difficult to monitor that many constraints for most projects. Yet you don’t want to have too skimpy of a landing zone either. A handful of disconnected system attributes isn’t worth much. You want to capture the essential success criteria in your landing zone. Things that are both important and measurable.

If you have more than a few attributes, it can be helpful to organize them according to category: e.g. cost, performance, data quality, reliability, usability, etc.). One large multi-year program I know of had a separate landing zone for each functional area (which was comprised of dozens of applications and services). In each functional area, dozens of individual landing zone characteristics were tracked.

Establishing and monitoring landing zone for a phased-release or multi-year product or program can be a big challenge. How can you establish accurate target values for what’s going to be delivered two years from now? You may not be able to. But you do your best given what you know now and what you can reasonably project for the near future.

Agile teams believe it is better to plan to replan than to over specify the future. If you embrace agile values you need to get comfortable with periodically re-planning and readjusting your targets. You should strive to firmly nail down parts of a landing zone that you expect to achieve over the next few months, leaving the rest of your landing zone purposefully sketchy.

And when new evidence comes to light, you likely will need to readjust your landing zone. What initially appeared to be achievable or reasonable targets can shift in light of new facts or market changes. No one wants to deliver yesterday’s product to today’s market. Landing zones, like release criteria can and do change. When they do, people have to make informed decisions to readjust targets.

For instance, you may have worked hard to meet some early achieved landing zone targets, only to find out that your early decisions had negative consequences on future work. You may have created some technical debt that either needs to be paid off (with interest) in order to achieve your next targets. But given time or budget constraints, you may decide to recalibrate your landing zone (and set expectations lower).

A landing zone is rarely cast in concrete. Things that can wiggle around and get more defined over time should be allowed to do so. But as your system architecture emerges and requirements inevitably change; it still helps to have concrete targets to shoot for. And the more precise the landing zone criteria are, the easier they are to design for and verify. I’ll say more on that in my next post.

Introducing Landing Zones

On an aircraft carrier, the landing zone describes a small section of deck that a pilot must touch down in to land the plane safely. By analogy, a landing zone for a product describes a range of measurable attributes that your product must deliver to achieve the product vision.

Landing zones are useful for products as well as complex projects and programs. For such complex systems it can be difficult to define “good enough to ship” without considering a lot of different factors and making tradeoffs between them. Recently I have been introducing landing zones as one technique for getting a bigger picture on agile projects and programs. I also find landing zones helpful in identifying architecture and design risks and potential required innovations.

I first learned about landing zones from Erik Simmons. Erik is responsible for creating, implementing, and spreading requirements engineering practices at Intel. Long ago, he and his colleagues taught requirements classes at Oregon Graduate Institute. That’s where I met Erik and learned about landing zones. Since then I’ve helped several clients use them for managing complex programs and projects. They are particularly useful when many requirements needed to be considered and it is important not to lose sight of make or break requirements.

Online information about product or program landing zones is scarce (the only other references I found were a brief glossary definition in Tom Gilb’s Competitive Engineering: A Handbook for Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage.

At first glance a landing zone seems nothing more than a glorified table. Each row in the landing zone represents a measurable requirement. Each requirement has a range of acceptable values labeled Minimum, Target, and Outstanding. The goal is to have each requirement within this range at the end of development. Inside the range is the desired value, labeled Target. Minimum, Target, and Outstanding are relative to your budget and timeframe.

Here’s an example of a landing zone for a loan processing system (all the examples I am using are concocted for simplicity’s sake; any relation to landing zones for real projects is coincidental):

Landing Zone for a Loan System
Attribute Minimum Target Outstanding
Adding new loan agreement 2 weeks 24 hours 12 hours
Add new product 3 weeks 2 weeks 1 week
Adjust loan terms 4 days 2 days 1 day
Access loan risk 1 day 6 hours 10 minutes
Assign loan servicer 1 month 1 week 1 day

And another for a smart phone (this one was cooked up by comparing competitive benchmark data):

Landing Zone for Smart Phone
Attribute Minimum Target Outstanding
Battery life – standby 300 hours 320 hours 420 hours
Battery life – in use 270 minutes 300 minutes 380 minutes
Footprint in inches 2.5 x 4.8 x .57 2.4 x 4.6 x .4 2.31 x 4.5 x .37
Screen size (pixels) 600 x 400 600 x 400 960 x 640
Digital camera resolution 8 MP 8 MP 9 MP
Weight 5 oz. 4.8 oz. 4.4 oz.

A landing zone is similar to release criteria, except it allows for tolerances in acceptable values. There isn’t one number you are aiming for; you have a range of values for each product attribute or characteristic you are targeting. This gives you some flexibility in defining what’s “good enough.” You’ll note on the smart phone that the minimum acceptable screen size is exactly the same as the target. This is not uncommon. It just means that there is no margin between your target and what is minimally acceptable. Sometimes the variance between minimum, target and outstanding can be small (this is when you know what your target is and how to achieve it, and are willing to accept only marginally less).

When you have little wiggle room in meeting requirements, you might simply want to define acceptance criteria with hard and fast numbers that simply must be met. I find it helpful to define landing zones for those product attributes that have some degree of flexibility in their outcome.

I like the way landing zones can help bring focus to a lot of complexity. If you are building something really big, you can roll up your product’s success to a few dozen things to monitor (instead of hundreds). In contrast to a list of release criteria, a landing zone also allows you to see a bigger picture and make sense of it: When one attribute is edging below its minimum, what is happening with the others? Are they trending below minimum, too? If so, you have a big problem with achieving your overall product goals. No, and you have a landing zone which allows you to achieve a successful product/system launch even if every requirement isn’t exactly on target.

Most important, landing zones allow you to make tradeoffs in multiple dimensions. The art is in understanding the tolerance for those attributes that define your landing zone, and then selecting reasonable values for minimum, target and outstanding.
If you are defining a landing zone for a new system or product, it may require you to do some research, experimentation, and prototyping to determine appropriate attributes and their values. If you are replacing an existing system, you probably know what capabilities need to be improved (and your minimum values are likely at least as good as the current system you are replacing).

If you have competitors, you will most likely benchmark their products as part of investigating what you can reasonably expect to achieve. For inspiration, look at comparative product reviews. For example see http://cell-phones.toptenreviews.com/smartphones/. Simple criteria, if met, are checked; other cells have explicit values.

Yet what’s good enough? A good landing zone allows for some flexibility in meeting goals without forcing you to accept unreasonable compromises. If all your landing zone attributes fall in the minimum acceptable category, do you still have a viable product? By definition, yes, your product is minimally acceptable. But that doesn’t guarantee its success. It means you have “landed”. You didn’t miss the aircraft carrier, but you are perilously close to the edge. You’d like to be in the target zone for most of the attributes.

In my next post I’ll write about using landing zones on agile projects and how architects can and should be involved in defining, vetting, and recalibrating landing zones.
If you’ve had experiences with landing zones I’d like to hear from you.