If software architects' soft skills fail, so does the business

Defining the software architect

Richards and Ford admit that the term software architect itself is ambiguous. The person -- or persons -- in this role could be titled enterprise architect, software or application architect, or even CIO or CTO, depending on the company. "There's no industry standardization around the term architect," Ford said.

Mark Richards

For that reason, Richards and Ford focus the book not on the detailed day-to-day of one specific architect role, but rather the responsibilities of any architect. The book covers three overarching aspects of the role:

• the general practices of an architect;
• the technical structures and styles architects use; and
• the communication and negotiation skills an architect needs.

"We devote about a third of the book toward each of those three categories," Richards said. "One of the many motivations writing this book was to bridge all of these important dimensions of a software architect into one concise tone."

The authors say that a key soft skill -- communication -- is too often buried, not to mention a difficult one for software architects to master. "It's funny that people call it the soft skills, because Mark and I joke that it's the hardest thing most architects deal with," Ford said.

The Pets.com fiasco

Fundamentals of Software Architecture illustrates the importance of IT for the business with specific examples, including the story of Pets.com, an early online retailer. Without scalable infrastructure and a resilient application architecture, companies like Pets.com fail at the moment they have the most potential for growth. Richards and Ford explain in this excerpt, titled "History: Pets.com and Why We Have Elastic Scale."

The history of software development contains rich lessons, both good and bad. We assume that current capabilities (like elastic scale) just appeared one day because of some clever developer, but those ideas were often born of hard lessons. Pets.com represents an early example of hard lessons learned. Pets.com appeared in the early days of the internet, hoping to become the Amazon.com of pet supplies. Fortunately, they had a brilliant marketing department, which invented a compelling mascot: a sock puppet with a microphone that said irreverent things. The mascot became a superstar, appearing in public at parades and national sporting events.

Unfortunately, management at Pets.com apparently spent all the money on the mascot, not on infrastructure. Once orders started pouring in, they weren't prepared. The website was slow, transactions were lost, deliveries delayed, and so on … pretty much the worst-case scenario. So bad, in fact, that the business closed shortly after its disastrous Christmas rush, selling the only remaining valuable asset (the mascot) to a competitor. What the company needed was elastic scale: the ability to spin up more instances of resources, as needed. Cloud providers offer this feature as a commodity, but in the early days of the internet, companies had to manage their own infrastructure, and many fell victim to a previously unheard of phenomenon: too much success can kill the business. Pets.com and other similar horror stories led engineers to develop the frameworks that architects enjoy now.

In addition to the immaturity of application technology and even the internet itself, Pets.com's failure may have stemmed from a lack of communication between the business and the architect, Richards said.

"You can have the best marketing department in the world, you can have the best infrastructure in the world, but if the two aren't talking together -- or [the architect] doesn't understand what the business is doing -- you're going to create something that doesn't support the needs of the business," Richards said. While he can't say exactly what happened inside the meeting rooms of Pets.com, it's likely there were two parallel paths: "Infrastructure didn't understand what marketing was doing, and marketing didn't understand what infrastructure was doing."

Lack of communication can stem from the business leadership's failure to envision what a software architect needs to prepare for, Ford said. "The business may have told [the architect] they were expecting 100 concurrent users, and they built an architecture for that," he said. "And then 500,000 concurrent users showed up."

With this problem still around well into the age of internet shopping and cloud infrastructure, Ford recommends that software architects take the initiative to approach the business side. Supply your expertise directly to business conversations. "No matter how brilliant an architect you are, if you can't sell your idea to the business, you're never going to get to implement that idea," Ford said.

Finding your voice as an architect

Another crucial software architect soft skill is understanding negotiation and acceptable control. Every decision a software architect makes will be challenged, Richards warned, by both tech and business sides on a project. "This is exactly why those interpersonal skills -- combined with negotiation -- are so necessary as an architect," he said.

Neal Ford

Ford explained his method for negotiating with development teams and business stakeholders. "I have strong opinions weakly held," he said. "I'm willing to listen to any counter argument, on its merits, and make a decision." Show that you are willing to listen to complaints about decisions you've made. And demonstrate trust in the developers' decisions. It will encourage them to bring new, better ideas forward in the future.

In Fundamentals of Software Architecture, Ford and Richards created a chart to show the level of decisions an architect should actually make alone. Architects must delineate between the kind of technical decisions that are of significant consequence, and those which are not.

"Say we need to pick an XML parsing library. What's the long-term impact of one XML parsing library versus another one? It's not huge, so I'll defer that decision to a developer," Ford explained. "But if you're choosing the overall object-relational persistence for an entire application, it has a huge implication down the road. That's much more of an architecture-level decision."

To grow developers into future architects, Ford added, the software architect should choose some specific decisions to not make. "If you never give developers and tech leads decisions of consequence, they're never going to learn from mistakes."

"You have to be pragmatic, yet visionary," Richards advised. "You have to be in the code, but you can't lose sight of where the technology is going, where the business is going, where the project is going and where the industry is going."

If you'd like to purchase Fundamentals of Software Architecture, please visit the O'Reilly Media website to learn more.