|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.