by Joe Shirey

Contents

Introduction
Why Soft Skills Are Relevant
Business Alignment
Perspective Awareness
Communication
Conclusion

Introduction

Most of us would agree that having strong technology skillsis a key ingredient to being a competent architect. However, the most successfularchitects that I have met possess more than just great technical skills. Theyalso have qualities that enable them to work well with people.

Developing and refining these "soft skills" can takeordinary architects to new levels of effectiveness in their careers. Thisarticle outlines a framework I developed for defining these soft skills andstrategies for the architect based on my experiences and interactions witharchitects I admire.

Why Soft Skills Are Relevant

We have all worked with one of them at some point in ourcareers—brilliant technologists who can solve just about any technical problem,but are so arrogant and insufferable that people despise working with them.Some of these übertechs will reach a point in their careers where they nolonger get promoted and their value is marginalized from a businessperspective. The reason they hit this ceiling is due to their lack of the"people" and "business" skills that we often call soft skills.

If you look at the Microsoft Certified Architect program,you will notice that there is a set of competencies that go well beyondtechnology skills. These competencies were based on focus groups from companieslarge and small. One common theme from these focus groups was that the softskills really matter. In fact, they identified more soft competencies thantechnical competencies. In their view, the soft skills are what separate thehighly skilled technologist from the true architect.

The International Association of Software Architects (IASA)has also gone through a detailed analysis and polled its members to determinethe skills necessary to be a successful architect. Of the five foundationalskill areas the IASA identified, two are based in these soft skills.

It is apparent that attempts to define the critical skillsof an architect contain some measure of soft skills. In my experience this isquite true; the most successful architects I know are able to increase theireffectiveness by combining their technical and nontechnical skills.

In my mind, the successful technical solution also requiresthree distinct soft skills: business alignment, perspective awareness, andcommunication (see Figure 1). Most architects acknowledge the importance of theseareas yet fail to make them real priorities during the project life cycle. Inthis article, I'll take a look at each of these areas and offer strategies forensuring that they remain priorities during the project without significantadditional effort.

Figure 1. Successfultechnical solutions require three distinct soft skills.

Business Alignment

I doubt anyone would deny that business alignment is acritical success factor for any project. Most projects begin with some type ofrequirements document that drives most of the technical decisions or at leastan architecture document that demonstrates how the architecture meets businessneeds. The issue generally isn't lack of intent but with the alignment at thestrategic level.

In my different roles, I have had the opportunity to reviewmany projects and discuss them in detail with the architects. Usually, thearchitect can discuss the business requirements, but it is surprising how oftenthe architect cannot explain the project in terms that the CFO wouldunderstand. There is a lack of understanding of the real business drivers andthe detailed financial implications versus the business requirements. It is thecritical factor that drives the real project decisions.

When I mention business drivers, I mean tangible andmeasurable items. Often, an architect will describe the project drivers as"increase customer satisfaction," which is quite nebulous. I believe thatbusiness drivers should boil down to financial terms when possible. In theabove example, I would recommend a goal such as "increase repeat customerrevenue by 10 percent and reduce call center support costs by 5 percent overthe next year" with detail to support why these goals are attainable based onthe project. These types of objectives will drive the true project benefits andcan frame what a project should cost.

There are some projects that are not driven by purelyfinancial terms, but there is always an underlying business reason for theproject. For example, compliance projects often are not done based on a purereturn on investment model. However, it is important to understand the businessrisks associated with not doing the project and use those risks to develop theappropriate solution.

By understanding the actual business drivers, the architectis able to make rational technical decisions during the project life cycle.Because many projects are based on business requirements, we treat them as a"contract." We sometimes become inflexible about changing requirements becausewe have based all of our plans on that "contract," but business situations anddrivers can change during the course of a project. If we possess a trueunderstanding of the business aspects, then we can help the business side ofour organizations understand the implications of those changes in our solutiondevelopment.

I often think back upon a project that I worked on for aniche software vendor a couple of years ago in which the customer was pushingus to complete a fairly large and complex project in a timeframe that wasunrealistic for building a high quality and maintainable solution. After manyheated discussions about the situation, we started to understand that the datewas not arbitrary; it was about the company's ability to survive. If thesolution wasn't done by a certain date, they would likely go out of business.That sense of urgency certainly drove the architecture of the solution (or somemight say "lack of architecture"). We had to sacrifice quality andmaintainability for project schedule. The CEO was aware that he would have topay the price down the road, but that was better than having to shut down thebusiness.

In that example, I certainly wasn't very proud of thetechnical solution, but we solved the customer's problem and kept the businessafloat, which was really a loftier goal. We also took the appropriate steps toensure the customer understood the trade-offs made during the project and thefuture implications. Because we took the time to understand fully the issuesthat drove the business, we moved into a strategic—instead of a tactical—role.

In my opinion, agile methodologies are a strategy foraligning with the business. The methodology enforces regular and scheduledstakeholder interactions, resulting in better understanding of and alignmentwith the underlying business needs. Not to say that agile projects will alwaysachieve this alignment, but the agile methodology does make it more likely. Noris it true that non-agile methodologies cannot be aligned, but many of thesemethodologies do not enforce the regular involvement of the business.

Summary Strategies for Business Alignment

• Think about your project like a CEO and CFO. Invest the time up front to dissect the business drivers for the project, and if possible, determine the true financial impact of the costs and benefits of the project.
• Use business drivers instead of requirements as your guide for developing the solution architecture. Keep a finger on the pulse of the business throughout the project life cycle to maintain the appropriate flexibility in the project.
• Evaluate how your methodology maintains business alignment during the project life cycle. If needed, inject some regular touch points to keep the business close to the project.
• After your solution is put into production, look for ways to measure its ability to meet the defined objectives.

Perspective Awareness

Each member of the team, from the project stakeholders tothe developers and testers, has views and motivations that have the potentialto create conflict, posing problems for the architect that can even derail theproject.

It is fairly common for the development team to dismissviews from outside of the team. This attitude is dangerous not only because theteam might miss some important business aspects of the solution, but they alsorisk alienating others and gaining a reputation for being difficult. It is therole of the architect to bring these groups together to ensure that the team isbuilding the solution that best meets the needs of the business.

Understanding others' often diverse needs is key to ensuring that the solution is the optimal fit. Thebest way to understand their needs is to view the business issues from theirperspectives. An end user of the system has concerns about usability while anoperations manager wants to ensure the system performs properly in a productionenvironment. Every stakeholder's perspective should inform the shape of thesolution architecture. Having a mindset that every individual has something tocontribute facilitates genuine interactions and meaningful communication.

The architect should be cognizant that not everyone involvedmay understand or believe in the business drivers of the project. Personalmotivations or organizational politics can sometimes work against fruitfulinteractions. As the architect, you cannot control all factors, but if you takethe time to frame these interactions within the scope of the business drivers,then it becomes more difficult for others to inject non- important or divisivefactors.

Many architects are in leadership roles with regard to thedevelopment team. Managing the attitude of the development team in someenvironments can be a challenge. Some development teams rarely interact withanyone outside their own teams; in their isolation, these teams becomedisconnected from the organization. Often it takes someone on the project teamto continually remind people that others have a job to accomplish and everyoneis on the same team. It is amazing to watch teams transform when leaders takethe initiative to help them see other views and motivations instead of joiningin when the group starts complaining.

Summary Strategies for Perspective Awareness

• Take the time to understand the perspectives and motivations of the individual.
• Ensure that multiple perspectives are taken into account.
• Frame the conversations with the guiding business drivers to alleviate personal agendas.
• Lead by helping others see alternate perspectives.

Communication

Most people would probably agree that communication is a keyskill of the architect, but few architects employ deliberate strategies forsuccessful communication as part of their roles. Since many of us havetechnical roots, we tend to revert to our technical strengths when problemsoccur.

Many problems stem from the inability to communicate withpeople in the terminology they use on a day-to-day basis. Some of the bestarchitects I've known have the ability to meet with executives and discusstopics in business terms, then walk down the hall to the development team anddive deep into technology discussions. I believe this skill can be learned, butit takes discipline and listening skills.

If you have ever traveled to a foreign country where youdon't speak the language, you probably understand how daunting it can be tointeract with others. Sometimes you are distrusted, just because you don't knowthe language. But if you learn a few basic words and seek to understand theculture and customs, you may even be welcomed. In general, people who arefluent in the language are much more likely to be trusted and embraced.

You have probably experienced a similar phenomenon when youhave taken a job at a new company. You have to learn a new language, culture,and customs. For example, the term "architect" at one company can mean aradically different role from an architect at another company. Over time, youpick up on the language nuances and begin to use them in your everydaycommunications. You start to incorporate acronyms in your daily language thatmeant nothing to you before.

This kind of subgroup acculturation also happens within anenterprise. Each group develops its own "native" language. As an architect itis important to listen carefully for these language clues and understand theirusage across the enterprise. You need to become multilingual, using theappropriate language and terminology based on the audience.

The skill to develop is the ability to pick up on thelanguage in a group rapidly and to use it effectively, even within the courseof a meeting. This means learning to listen effectively during the course ofyour time with a group and to start cataloging the terms. By communicating withsomeone in their "native tongue," you get over a trust barrier and increase thepossibility for open communication.

After becoming multilingual within an organization, youmight want to restructure your meetings to bridge languages and needs. I haveattended many meetings among business and technical groups in which one groupwill dominate the meeting and the other will lose interest and stopcommunicating. When the situation calls for bringing together disparate groups,you may need to play translator to ensure that each group is communicatingeffectively.

In all of your communications, one of your primary goalsshould be to build trust with your audience. The best way in my opinion is tobe tactfully open and honest. In general, if people feel that they can trustwhat you have to say, they are more likely to give you their true thoughts evenwhen they are unpopular.

Open and honest communications are of particular importancewhen communicating with the project sponsor. I have observed many projectsdeveloped with a strong communication plan between the architect and theproject sponsor. In these cases, because the sponsors were always the first toknow about positive or negative situations, they were in control of the projectand could react when necessary.

These types of communications need to be very efficient.Sending a 20-page status report to the sponsor on a weekly basis with theminutiae of the project is not an efficient use of anyone's time. I believethat a written status report on one side of one sheet of paper with themacro-level project statistics and the primary issues and risks delivered inperson in 15 minutes a week sets up an effective communication channel andbuilds rapport. When using this process, I have had project sponsors commentthat they felt more engaged with the project than any other in the past.

When communicating with others, it is important to avoidabsolutes. Terms like "can't" and "won't" convey inflexibility. The alternativeis to present options and implications of decisions in an open and honestmanner. This approach also endows the conversation with a peer quality—openingthe lines of communication to a discussion, instead of a debate. If thebusiness drivers are also a part of the discussion, then there is a frameworkfor making joint decisions.

Summary Strategies for Communication

• Communicate with others in their "native" language.
• Foster an open and honest environment.
• Provide efficient communications to the project sponsor.
• Present alternatives and implications, when possible.

Conclusion

Most of us could benefit from further developing our softskills to improve our effectiveness in our day-to-day role. The framework I'vedescribed can help you develop strategies to improve these important skills.

About the author

Joe Shirey is a senior architect evangelist forMicrosoft Corporation, based in Denver, CO. Prior to joiningMicrosoft, Joe was a vice president at Interlink Group where he was responsiblefor services delivery for their largest market. In the past, Joe was aMicrosoft Regional Director; he has served on the Microsoft Architect AdvisoryBoard and the .NET Partner Advisory Council. He has more than eighteen years ofhands-on technical and functional experience in project management, systemsanalysis, design, development, and implementation. Joe attained his MicrosoftCertified Architect in Solutions in 2005.

This articlewas published in the Architecture Journal, a print and online publicationproduced by Microsoft. For more articles from this publication, please visitthe Architecture Journal Web site.