Month: June 2012

What a Software Architect is NOT

In another post, I defined the role of a software architect. This post points out some duties that are not necessarily part of his or her job, for clarity.

foreman

A foreman–vital but usually not the same person as the architect. Photo credit: USFS Region 5 (Flickr).

* An architect is not necessarily a lead engineer. Lead engineers translate architectural guidelines and vision into implementation, not just in the design phase, but all the way through RTM. Lead engineers work for dev managers and are accountable directly to them. Lead engineers might have a technical director pay grade, but whether they are asked to function as architects is a separate question. When lead engineers push back, it’s usually about whether an implementation works or is reasonable, not about whether a vision is the right one. Lead engineers may “own” a particular facet of the technology portfolio through multiple release cycles, and this cross-release perspective is architect-like. However, lead engineers are far less likely to radically question the value of what they own than an architect, because an architect is looking at a bigger picture over a longer horizon. When Bill Gates told every MS employee to drop what they were doing and spend a month thinking about the Internet because the company wasn’t “getting it,” he was being an architect. The lead engineers on all the projects and components that ultimately got ditched so MS could go chase the web wave would never have done that.

* An architect is not a dev manager or dev director. Dev management coordinates the work of a team that delivers product to spec. Dev management scopes work and speaks with authority on whether something is doable with what schedule and what resources. Dev management is extremely focused on release cycles. If we were constructing buildings, dev managers would be foremen — reading blueprints, hiring and monitoring subcontractors, cutting checks, giving status reports. A dev director or Sr. Dev Director would be the general contractor. But neither the general contractor nor the foremen would decide to put an elevator shaft in a different spot without talking to the architect who calculated the load-bearing capacity of the walls. Like lead engineers, dev management should understand technical guidelines provided by an architect, and should be accountable to work within them, pushing back to the architect as necessary. This is parallel and analogous to the push-back that dev management provides to PM when the schedule is threatened.

* An architect is not a product manager. A product manager proxies customers and builds business plans for releases of products. A product manager says with authority, “This is what the market wants, and we can make X selling it.” These business plans should represent our best understanding of revenue-maximizing choices. But without an architect to provide feedback, these plans typically have a one-release horizon — whatever maximizes revenue in the next release is assumed to be best. Or else we have a long-term business perspective, but implementers receive little guidance about technical tradeoffs that are aligned with an appropriate evolutionary path; the technology becomes a patchwork quilt of kludges and dead-ends that is progressively more expensive to enhance and less useful as a competitive weapon.

What Role Are You Playing in RPCD?

When you role play in RPCD, you could be standing in for either software, or a flesh-and-blood human being. As RPCD explicitly acknowledges, both are part of your final system.

A key insight of RPCD is that the distinction between these two entities is a lot less meaningful than we usually think. Most software is created to solve a problem that ordinary human beings are already addressing in some fashion. In fact, I might go so far as to say that this is true of all software. The quick exceptions that come to mind just take a little more pondering to map. Biometric scanners? Just a replacement for humans judging whether a person matches that photo on their driver’s license. RFID tags? Just making the human inventory team’s job easier. Firmware in high-speed switches on the internet backbone? Just a step or two removed from postmen and switchboard operators. Word processors and IMEs? Just a replacement for a transcriptionist. Signal analyzers for SETI? Genome sequencers? Protein folders for Folding@Home? Just substitutes for human researchers.

human researcher

photo credit: armymedicine (Flickr)

Even if you’re playing a role that you’re sure will ultimately be encapsulated in a tidy software abstraction, RPCD helps you remember that the problem that entity solves is ultimately a human problem. We don’t pay engineers the big bucks to make computers happy.

Long-Term Benefits of RPCD

In a previous post, I wrote about a methodology for designing software that has role-playing at its heart. If you take a look at the example RPCD interaction, I think some benefits will immediately become apparent.

But there are subtler advantages that might not be obvious:

The system never needs to wait for functional code to be deployable.

As soon as you have a set of reasonably clear roles defined, and at least one specific use case, you can observe the system in action. Granted, you’re observing people instead of software, but the full complexity and dynamism springs to life right before your eyes. People can hold clipboards and use checklists to model how wizards populate databases; they can move post-notes on a whiteboard to explore organizational algorithms. Seeing in toto, from the beginning, is incredibly useful.

checklist, from http://www.flickr.com/photos/alancleaver/

The first deployments you do are demos. I am a big fan of demos; you should demo something at the end of every sprint or milestone, to guarantee that you’ve actually accomplished something useful and that it’s aligned with the needs of stakeholders. But with RPCD, you take demos to a whole new level, because your demos become interactive. If sales asks “What happens when the user pushes the big red button?”, you don’t have to say, “Sorry, we can’t demo that today.” You walk over to the person modeling the UI, push the red button on the piece of paper or the whiteboard that they’re holding, and let the system chug.

Later in the evolution of code, when most parts of the system are automated, the roles that humans still have to model give you critical information. Are these roles something that you ought to permanently delegate to human intelligence? Is the wizard you expected to build so complex and error-prone that online chat with a human is a better option, at least in this release? Perhaps you should hire an online chat person as a component of your system, take the risk out of the near-term release, and then study the behavior of that person intensely to learn how to automate in the next release… If your system has always used humans for cogs, adapting it in this way will be natural, not a major departure from expectations.

Another possible insight is that roles where humans are forced to continue to work represent the high-value aspects of the problem. Solve those problems, and customers will really love you, because you’ve radically changed their work.

The needs of all humans interacting with the system are inherently “baked in” and obvious, instead of being implicit.

UCD says to center your design on the user. But so often we forget support, sales, IT, executive management, and so forth. If you’re writing an app for the iPad that uses social ranking to recommend shows airing in the next hour on cable channels, you probably have a team of data managers that maintains current listings for all channels, and a team of backroom IT that keeps your DB running. These people are part of the system; if one day your data center dies, and no IT people show up to fix it, or one day your channel listings goes stale and no data manager steps in to solve the problem, you don’t have a product.

These people should all have roles in your role plays, and by regularly representing them, you can’t help but make better decisions. Overhead and cost centers become obvious. Risks jump out at you.

The clumsiness of certain touch points becomes obvious.

Or in other words, user feedback and usability testing are built in, because actual people, not abstract boxes on your system, are interacting from the very beginning.

Example RPCD Interaction

In my last post on RPCD, I explained its key tenets. In this one, I’ll imagine one way to put it into practice.

Suppose a team is chartered to build a tool that locates birth mothers of adopted children. The team’s received some vague marching orders (“make it as easy as possible; we want to sell this as a service on facebook and the iTunes app store”). Maybe they’re using “agile” methods or even full-blown XP to guarantee that the customer’s viewpoint is represented, and that small units of work are fully processed into releasable systems on a regular basis. Or maybe they’re doing traditional waterfall, with an elaborate design phase followed by a long implementation.

Regardless, adding RPCD to this team’s behaviors might result in interactions like the following:

Step 1. Team discusses charter. They frame the charter in terms of a concrete use case. Since they don’t have a specific “real-life” customer to talk to, they postulate one. It might look like this:

Rafael just turned 18. He knows he was adopted, and he wants to find his birth mother. He knows he was born in Portland, OR on Sep 3, 1993, that his birth mother’s name was “Cindy” or “Cynthia”, and that his birth mother might have been a twin. He will interact with this product via an app on Facebook.

Step 2. Team imagines how the problem would be solved with people only, assuming that money and time is no object, and that a “white gloves” treatment is the goal. This analysis helps crystallize roles for later role play. For example:

Rafael (role = client) requests the services of a “birthmother locator” firm. The firm immediately sends an intake interviewer, Summer (role = liason) to Rafael’s home. Summer records all of Rafael’s contact info so she can interact with him in the future, clarifies Rafael’s goals, and records all information Rafael can contribute. Summer then returns to the office and arranges for Jenny (role = case mgr) to convene a group to work on Rafael’s case. The group consists of Summer and Jenny, plus Oscar (role = researcher) and Mike (role = gopher). Oscar and Mike are to begin work immediately and to report back on a daily basis. After two days, Oscar has identified 62 women whose life facts might overlap with what is known about Rafael’s birth mother. Summer contacts Rafael to report status and ask a follow-up question: does Rafael know whether his birth mother was athletic? Rafael says yes, he thinks she might have been a swimmer. Based on Rafael’s confidence in this new info, Oscar decides to narrows the search to women who appeared in high school yearbooks within +/- 5 years of 1993 and who were involved in sports. He dispatches Mike to get some HS yearbooks. He also looks in yearbooks for any girls who have a peer in the same grade, with the same last name. After three more days, Oscar has narrowed the list of candidates to two. He reports back to Summer and Jenny. Summer presents the list of candidates to Rafael and asks if he’d like them to contact the women. Rafael says no; he’ll do the final part himself. Rafael is delighted with the results and the “white gloves” treatment, and happily pays for services rendered. Summer asks him to be a reference customer, and he agrees. In fact, Rafael is so happy he can’t wait to tell all of his friends about the cool service.

Step 3. Team builds a diagram of the system, using boxes for the roles that people play. The draft a “job description” for each role.

Step 4. Team assigns roles to team members. “Fred, you’re going to pretend the client. Sally, you get to be the liason…”

Step 5. The system is deployed and goes live — in “role play” mode.

Yes, you read right. After some very early design work that can probably complete in an hour or so, the system goes into “production”. Not in its final form. Not with ultra-high standards. But in a form that allows the team to learn and refine through repeated role plays. These role plays vett the roles and the model that the team has postulated.

Role play #1 is a walk-through of exactly the scenario that the team just imagined. Fred (playing Rafael) walks to a computer, pretends to be using an app on Facebook, and says “Okay, I’m now pressing enter to submit my request.” Then Sally (playing Summer) looks at a computer screen and says, “Oh, I see that we have a new potential client. I’ll go visit him.” Already, some interesting questions should be coming to the team’s mind: Will clients be happy to be contacted by the app/service as soon as a liason like Summer is available? If so, what info should the “request help” form require so the client can be contacted? Or could a wizard automate Summer’s job? How about a chat with an online representative? Do different clients need different priorities, so that if Summer is busy when a new request arrives, she knows whether to be interrupted? Does a case manager like Jenny have to assign Summer before Summer will pay attention? The team works through these questions and continues with role play #1. Lots more questions come up as they get to the work of the researcher and the gopher. What resources will researchers have? What is the latency of getting info from those resources? How much will it cost to access those resources? Who bills the customer for expenses, and what accounting procedure must be followed? Should researchers report breakthroughs as they occur, or only once a day?

After the team works through the role play #1, it should have some intuition about which parts of the system are going to be easiest to automate. It should also have a long and ever-growing list of questions. Not all of the questions are of equal value. The team should look for ones that have major ramifications on the user experience and the scope of work, and explore those first.

Exploration takes the form of additional role plays. Since Fred was assigned the role of Rafael, his job is critical. He gets to introduce variation into the system. He shouldn’t go hog-wild all at once (“Can you bring me a pizza with your next status report?”). But he might do something like try to call his liason after a pretend hour has elapsed, to find out if any status report is available. That should cause the team some debate and head-scratching. :-) What if he asks to be notified by text in the middle of the night, no matter the hour, with new developments?

Step 6. Boundaries between automated and human components of the system are clarified. More traditional design work begins.

Step 7. The team returns to role plays whenever additional clarity is needed.

Step 8. When “the system” is delivered, it is always done as both code AND people. This means at the end of an iteration, for example, you don’t just provide a build with no bugs. You provide a role play of the system. This role play is more than a canned demo; it is an interactive demo, with people filling roles that code is not yet mature enough to handle. By viewing delivery of a “system” as delivery of a code+people ecosystem, the team is forced to consider things like how tech support will be staffed, how help will be delivered, and so forth.

Role-Play Centered Design

User-centered design (UCD) is important. I hope I’ve been a good advocate for it during my career. Its basic tenet is that software should be constructed as much as possible according to how users think and work, not according to techie considerations. (A seminal book on this topic is The Design of Everyday Things, by Donald Norman.) At its best, UCD promotes an alignment between technology and customer pain points that keeps software’s value proposition compelling. Even on a bad day, UCD makes software a lot more pleasant to use.

However, UCD rarely yields all potential benefits, which is why I’d like to suggest a specialized form of UCD for many software teams. I’ll dub this idea “Role-Play Centered Design” (RPCD, prounounced /ˈrɪpˌsɪd/) because of the way the various parts of the system come to life. (This idea is similar to–though conceived independently from–the concepts in this article from the proceedings of HCI ’07.)

Role plays can help you build software — not just entertain. Photo credit: TheArches (Flickr)

Manifesto

RPCD is distinguished from ordinary UCD by three key tenets.

  1. The “system” includes people.
  2. Specifics are non-negotiable.
  3. The best way to understand is to “be” the system.

Let me justify each of these ideas, and then I’ll give an example of an RPCD process at work.

The “system” includes people.

Most architectural and UML diagrams focus on software and/or hardware entities. The user’s role in the system is implicit. Even among users of activity diagrams, most workflow is computer rather than human.

This is wrong. software – people != software. Any thoughtful veteran of the industry can tell you stories about why this is so. Engineers who accept the flawed premise that only the computer side of software needs to be designed are already handicapping their UCD fatally. The system built by a software team includes people — individual users, a community, support personnel, sales folks, professional services, maintainers of docs on a web site, etc. If you let an engineer construct “the system” with no serious thought to the people, you often end up with misalignments that make it irritating to understand/use/configure/support, expensive to maintain, or even impossible to sell.

Specifics are non-negotiable.

The devil really is in the details, and if you don’t solve detailed problems, you won’t solve problems at all. The design of a system is therefore best driven by specifics–even if the specifics are only postulated. Specifics are best exemplified by use cases, and role playing forces specifics into use cases.

The best way to understand is to “be” the system.

You should “be” the software in the system, and you should “be” the people as well.

When a human being actually interviews someone in the same way an automated wizard eventually will, you learn things. The human reorders the questions or short-circuits part of the interview because she knows it’s unnecessary. Or the human gets frustrated at how needlessly cumbersome a particular part of the process is. Or the human asks some intelligent questions that you never considered. When two humans interact to model what’s eventually going to be a formal protocol, you confront asynchronicity and error handling in ways that UML or whiteboards don’t.

Modeling the system in role plays also has some other profound long-term advantages that go far beyond just what you learn. I’ll discuss these in a different post.

In my next post, I’ll give an example about how RPCD works.

Action Item

List all the people that interact with or help create your software. If your list has less than four or five unique roles, think some more. Hint: see this post.