5 questions that will make you a better software architect

Leading up to the O’Reilly Software Architecture Conferences in London and San Francisco this fall, the conference chairs, Rachel Roumeliotis and I, asked the speakers a few questions. Software architecture is a widely varied field, so the scope of answers is revealing, especially the emphasis on the non-technical aspects of the job. Some highlights:

What is your proudest moment as a software architect?

Nancy Nunes provided a detailed answer about her proudest moment, winning FDA approval for a minimally invasive surgical robot system that she architected and developed from day one.

I must say nothing beats the feeling of having a respected and esteemed colleague attribute part of their professional acumen to having learned from working with me.

Other answers were more generic, ranging from “meets functional and non-functional requirements” to pride in the fact that an architecture “can handle large shifts in requirements without need to make drastic changes.” Pramod Sadalage, a data architect, prides himself on clarity, his proudest moments coming from the day to day effort in clear design, so that “developers can understand the data model without much explanation.” Cassandra Shum makes a great point about the experience level that architects bring to the project: “guiding the project into a more flexible, scalable infrastructure and platform … is often a result of seeing similar problems throughout different organizations, and being able to identify them quickly can be quite satisfying.”

Mark Richard’s proudest moment was the revelation that “heroism doesn’t scale—it’s team efforts that make things happen.”

One of my proudest moments as a software architect was making a team of 12 people one of the most effective I’ve worked with. Although we had our share of technical challenges, we worked together to complete the conversion effort on time and within budget. That project really demonstrated first-hand that while technical architecture skills matter, it’s the soft skills of a software architect that makes the difference.

What is the most complex project you worked on? Was it complex for good or bad reasons?

Architects always want to discuss complex projects, partly as primate ranking exercise, but also because we are always fascinated by what the architect learned as part of that project. Complex projects, whether success or failure, always come with a rich set of learnings, supplying patterns and anti-patterns for the future.

Several of our architects talked about the married complexity of domain and technology. Dean Wampler said his most complex project was a “fast data” streaming system, “where the complexity was inherent in the problem domain and the challenges of reliability.” Pramod also discussed the combination of technology and problem space: “The most complex project I worked on was equipment leasing backend system. It was fun for being very complex domain with the need to understand financials, inventory, and CRM-type functions.”

Mark’s most complex project manifested when he was the chief architect on a large-scale enterprise service-oriented architecture effort at a major insurance company, in the early days of SOA.

The sheer size alone made this a very complex project, but it really was the coordination of multiple teams and groups that made it complex.

Mark’s other indelible lesson from this project was the importance of data in architecture:

It is through this project that I also gained an appreciation for the complexities involved with database transformations. Everyone was very excited about all of the enterprise services we were designing, but once it came to talking about data, things changed dramatically. “Don’t you dare touch my data” was a common phrase on that project, and significantly added to the complexity of that SOA effort.

Many developers discount the project they’re working on as not rocket science, but some don’t have that chance. Nancy’s most complex project combined hardware, software, and munitions!

I worked on a missile tracking system for Raytheon that is currently deployed for a number of customers. That system is complicated because it is a “high-caliber” system. It receives high frequency and large volumes of input data, with high stakes on its success. It needs to support highly parallel computationally intensive calculations with accuracy and speed. It isn’t complicated for good or bad reasons. It’s complicated because it’s literally rocket science!

The common theme across all our answers seems to be that complexity arises from the intersection of technology and business. No one owned up to bad complexity (at least not in this answer), but that’s more a reflection of the nature of complex projects in the real world, which always combine both.

What is the most important soft skill for an architect to possess?

We posed this question because burgeoning architects often say that soft skills are the most important under-anticipated part of the job. Not surprising, leadership was called out by all our architects as an important soft skill. Dean’s advice is to “lead by example. Influence the rest of the team not by pushing decisions down, but by demonstrating why they are right.” Pramod also stresses communication skills as a key requisite for being an effective architect: “Of the many soft skills needed to become a good architect, I think the ability to connect with people and communicate is the most important one.”

Cassandra calls out open-mindedness as a key soft skill, saying:

I often see architects be too rigid in “their way” of doing and thinking about solving problems. Because of that, I feel that solutions could have been dealt with better if the architects can open their minds to looking at the actual problems instead of just suggesting what is comfortable to them.

Nancy built a flow chart, based on how much business influence an architect has. When an architect has influence, leadership appears again:

If an architect has the authority to freely make technical decisions which can affect resource utilization, then the most important soft skill is leadership, which, depending on the experience level of the team, may include a significant amount of mentoring.

If, on the other hand, the architect doesn’t control resources, an alternative soft skill rises in prominence:

If the architect does not have a great deal of authority to alter the allocation of resources, then the most important soft skill is selling. It will matter very little that an architect has ingenious plans for software if the plans are not supported financially and politically.

She makes an important point: if an architect can’t control critical aspects of the project (like budgeting), their ability to have real impact is diminished. With practices like continuous delivery and DevOps becoming more prevalent, architects must often display leadership in situations where they have only loose influence, not institutional power.

Name three non-technical skills crucial to success as a software architect and why.

Continuing the theme, Pramod calls influence one of his crucial non-technical skills “because architects need to bridge the gap between business and IT, work with many silos. Without good influencing skills it hard to bring folks to understand your vision.” He also calls out decision making “because without good decision making the architecture will decay into a mess.” One of Mark’s, negotiation, follows this theme as well:

As a software architect the decisions you make will in most cases be challenged. Those decisions cost money, have broad-reaching impact, and might even be controversial. Therefore, knowing how to negotiate is critical for getting your decisions accepted and approved.

Most of our architects call out communication in various forms as a key soft skill, encompassing writing, speaking, and graphical rendering of vision onto media like white boards, to ensure ” the architecture is thoroughly understood and can be designed and implemented as intended.”

Observation is a key soft skill that Nancy elucidates nicely:

Observation, through watching, listening, and reading, is important to an architect for learning factual information and discerning legitimate requirements. Facts can be distorted by miscommunication or misinterpretation. Requirements can be buried in products in existing documentation or code. The naturally different perspectives of different stakeholders can skew the perception of the relative importance of some requirements over others. The architect must objectively observe to sort the facts from the fiction in order to create an appropriate and viable solution.

Mark Richards makes this same point in many of talks about non-functional requirements. The business’ real attitude about important characteristics of software, such as security, scalability, evolvability, and others won’t come in a nicely defined memo but rather extracted from the context of meetings between business people, discussing business goals that impact software architecture. Architects who are keen observers preemptively solve problems before they become problems.

All three of Cassandra’s key skills involve people:

Empathy, Delegation, and Organization. These three skills are very people oriented, because at the end of the day, people are crucial to the success or failure of a project. More often than not, people are the problem, not the technology.

Pramod’s last non-technical skill is often under-appreciated, the ability to continue to learn. He says “an architect needs to learn new things and also from the past, learn from others, and become a good teacher of what they have learnt.” Good teachers are often good leaders, reinforcing the importance of informed leadership. As Dean says, influence by demonstrating correctness, not by fiat.

What is your “If I could do it all over again…” project?

Not surprising, all these sad stories lament missed opportunities, because of inappropriate technology choices or difficult business environments. Nancy’s story will make many readers cringe in recognition:

Early in my career I was a member of a software team which was working on a next generation redundant control system for gas and chemical applications. The existing control system product was a substantial source of revenue for the company and the product hardware was reaching end of life. The company happened to be transitioning through a merger and new management was part of that transition. The new management decided to proceed with a new team, new object-oriented methods, and new tools. This left a few members of the team that had been long time contributors of the legacy system working in maintenance mode for the products in the field, which left them not particularly happy to be left out of the loop. As the hardware team designed new electronics, the new software team was tasked with upgrading the software architecture and design in order to position the product line for growth. And to make things a little more interesting, there was a potential customer, which would have been a very large new account, that required triple redundancy and support for a proprietary scripting language.

When the project progressed to software / hardware integration, there were the usual glitches. A few people from the legacy team took the opportunity to spread fear that the new software was doomed and a no frills port would save the day. At this point the potential business deal with the new customer had also been lost. Management canceled the triple redundancy feature, abandoned the software architecture upgrade and reverted to the existing design, taking the less risky route of porting the existing code base to the new hardware with no software improvements.

It was very disappointing to the entire team to have done so much good work and to have come so close and then have all our efforts discarded. There was huge potential in the redesigned system, and it was abandoned out of fear of risk.

This project was my introduction to software architecture and was a major catalyst in steering my career towards software systems architecture. The lessons I learned from that experience regarding the value of soft skills in helping a project succeed, are just as valuable, if not more so than the technical skills I learned.

Experienced architects become that way by enduring both project success and failure, always leaving with new lessons. Often technical failures become terrific lessons in soft skills and understanding how messy real projects work, including messy real people.

Mark experienced the dichotomy of successful and disastrous simultaneously on his “do it again” project:

Technically, this project was a big success … However, as a software architect, I failed in epic proportions. While I had the technical know-how to lead this project and design the new systems, I literally had no people skills. As a result I alienated almost everyone on the team. Several members of the team left the company, and others specifically requested never to work with me again. I learned a lot of lessons from that project, and if I had the chance to do it over again I would. There were good people on that team, and I failed them. It is because of this project I learned that the soft skills of software architecture are often times more important that the technical ones.

Aligned with his appreciation for lifelong learning, Pramod would like to do all his projects over again!

There are many [projects I would do all over again], especially with the advent of new technologies in stream processing, NoSQL databases, CQRS, event sourcing architecture styles getting popular. I think about how I would have done some of my projects using these new techniques and technologies. Its always fun to think about your old project in the context of new learnings we have had.

Learning is what we’re all about at the O’Reilly Software Architecture Conference. We cover technical aspects of architecture, but also the critical soft skills discussed by all our experienced architects here. We have built a program that tries to touch each and every aspect of software architecture. Come join us!