 |
| Christine Miyachi, SDM ’00 |
Editor’s note: SDM alumna Christine Miyachi is a principle systems
engineer and architect at Xerox Corporation. She also writes a weekly blog
about software architecture: abstractsoftware.blogspot.com.
“An accidental architecture emerges from the multitude of individual
design decisions that occur during development, only after which can we name
that architecture.”
—Grady Booch, pioneering software engineer
I enrolled in MIT’s System
Design and Management Program (SDM) because I wanted to become a lead software
designer/architect/systems engineer. I thought the program would give me the
technical skills I needed—and it did. But I also learned that leadership and
negotiation are critical to architecting successful software.
Today, my daily work involves
myriad decisions that depend on both technical expertise and an understanding
of business needs. My background gives me the skills to create an initial framework
that will persist. However, even after an architecture has been designed and
implemented, information about how the system will and can work is often
discovered, requiring design shifts to continue to support the business.
It’s important to understand—and
to be able to communicate—that creating software is not like an assembly line
where every piece of work is completely uniform and understood. In fact, it’s
an intellectually intensive and often unpredictable process.
 |
| Figure 1. The waterfall method of software design calls for work to be done in stages, without any return to earlier stages. |
 |
| Figure 2. In iterative or agile design, requirements, design, and implementation is done in each short cycle, with functionality delivered to stakeholders after each iteration. |
It’s helpful to compare and contrast
two methodologies software developers commonly use: waterfall (Figure 1) and
iterative/agile (Figure 2). Pure waterfall proponents believe that all
architectural decision must be made upfront. Pure agile proponents say that
nothing needs to be decided upfront because methods, requirements, design, and
implementation is done in short cycles, with functionality delivered to the
stakeholders in each iteration. However, most software architects agree that a
combination of upfront and iterative decisions contribute to successful
software architecture.
In Ken Schwaber’s book Agile
Software Development with SCRUM, he discusses the empirical model of a process
that incorporates the unexpected. Control is established through frequent
adaptations, he explains.
My experience with software
architecture is very close to this. While it is tempting to be very rigid in
architecture and not allow changes, this strategy causes conflicts and often
produces a system that does not meet the ever-changing business needs.
For example, in one project I
worked on many years ago, we selected a framework that auto-generated code.
This framework became outdated, the company that provided the auto-generating
tools went out of business, and we got to the point where we couldn’t make
changes to this module in our system. We actually had to design other programs
around it. Finally, thanks to the courage of a few, this section was redone.
The challenge in software is
that, unlike other engineering disciplines, the output is malleable. Changes
can be made fairly easily—at least before the product ships. I think that’s why
I’ve found we always end up with what Grady Booch calls an “accidental
architecture.” The final product is a result of decisions made following each
iteration—and all of these decisions require a lot of negotiation.
Here are three examples of how
design and architecture are negotiated in software. They illustrate the tools
and skills I learned while an SDM student, in particular the leadership and
negotiation methodologies that are critical to architecting successful
software.
Case 1: I’m not the expert, but I bring a team of experts in to make a
decision.
Experts from different
disciplines often don’t agree, so in this case I act as a negotiator, guiding
the team to a solution—usually in one meeting because time is always a factor.
When negotiating and brainstorming, I make sure that everyone’s voice is heard,
and I work to get the quiet people to speak up. It’s important not to make
anyone appear stupid, and not to use anger or aggression to win your case. That
usually backfires.
 |
| Figure 3. Using a template like this one to establish a mind map can help bring logic and rigor to the decision-making process. |
I use tools such as mind maps
or decision matrices to bring logic, rigor, and a common understanding to the
discussion. The mind map (Figure 3, a tool taught in SDM’s system architecture
course) and the decision matrix (similar to the quality function development
matrix taught in SDM’s product design class) are both ways of visually
representing the relationship of ideas. Axiomatic design, another method taught
in the SDM program, is similar.
For more information about
these tools, visit http://abstractsoftware.blogspot.com/2010/08/architectural-decisions-or-on-purpose.html.
Case 2: I disagree with someone else on a design decision.
When should I dig in my heels
and when should I compromise?
I have a colleague on my team
who always wins design arguments because he has a very strong personality.
Other people back down simply because they don’t want to put up a fight.
Sometimes I do fight, but I can also compromise. The question is when to hold my
ground and when to give way.
The following guidelines,
taught in SDM, have proved useful:
• If
I realize the other person is correct (I see something I didn’t see before), I
will agree to change.
• If
I think the proposed decision direction will hurt the project, I will fight it.
• If
I think we can make a change later with no ill effects, I will sometimes wait
and put the change in a parking lot.
Of course, I’m not always
right. Sometimes I end up wishing I had fought harder and sometimes I wish I
had compromised. I’m always learning.
Case 3: A key decision is made, then changed.
This scenario is common in
software architecture, partly because of the product’s malleability and partly
because leadership and teams are subject to change.
For example, I once acted as a
negotiator and an expert for a key architectural decision. We developed a set
of requirements, weighed their importance, and looked at four solutions to meet
those requirements. We rated each solution against those requirements, and two
were very close. One was more robust but not as scalable to low-end computing
systems (not a lot of memory, weaker CPU, etc). One was less robust but very
scalable. Although one team member objected, the team ended up choosing the
more robust system.
About a year later, after some
shifts in the business, we had to revisit the decision. The market had changed
and we had to go with a less robust but more scalable solution. The lesson is
that as an architect you must be able to gauge if a solution is still viable in
the business climate, which is constantly and sometimes drastically changing.
We had to adapt or we would have lost business. It’s also essential to document
decisions as they are made because this will save time and increase efficiency
by eliminating the need for “archaeological excavation.” In short, if the
business changes, you will more easily see when past logic is no longer valid
and know that it’s time to make some changes.
The bottom line is that
software architects need more than technical and managerial expertise—they need
to know how to negotiate design decisions and use a toolbox of ways to examine
tradeoffs logically—something SDM provided for me.
Today, these SDM tools help
enhance the contributions I and my team members can make to Xerox. This
includes the expertise to facilitate and lead groups to create an initial
framework that will persist, but as importantly, the leadership and negotiation
skills to make design shifts that will continue to support the company as it evolves.
No comments:
Post a Comment