- ~ Posted by Deepak Kamboj on February 24, 2010
What is a Solution Architect?
The essence of the Solution Architect (SA) role is the conversion of the requirements into an architecture and design that will become the blueprint for the solution being created. This conversion is based largely upon the previous design patterns that the SA has been involved with in the past through reading and staying abreast of the latest techniques, or through personal experience.
It is this conversion part of the role - the role of the SA -that most often is underestimated in its complexity. Just as the ability of the Functional Analyst to create a requirements document is one part science and wrote procedure so is the creation of the architecture. The rest, however, is an art form. Creating effective architectures to create a solution requires the careful balance of dozens of development concepts ranging from "Keep it Simple Stupid" to "Fail to Safe".
In the process of converting requirements to an architecture there are often parts of the SA's role which seem out of place. For instance, there is often a fair amount of research that happens during this phase. The research may be targeted at testing a technology that will become critical to the architecture. For instance, the SA may test to see if USB or serial port access is available from Java if there's a need to read a device without downloading software. This process can either be done alone or depending upon the size and velocity of the project can be delegated to a development lead.
In addition to research on technologies and approaches critical to the architecture, there is often a review of patterns that might be useful to the architecture. Patterns are previously described and validated approaches that can be used to create portions of the solution. Patterns are released through research and can come from places such as Microsoft's software development libraries. Reviewing the pattern allows the architect to refresh their memory on the details of the pattern and to evaluate what additional guidance they will have to provide if they choose to use the pattern.
The final component to the role of solution architect is the motivation and guidance of the development leads. Development leaders need to buy into and accept the architecture, to know how the pieces will fit together at a high level. They must also see the art portion of the architecture to get an appreciation of the subtle nuances of their portion of the architecture. It's the art portion of the architecture that makes it elegant. That elegance helps to maintain cohesion between various parts of the design and encourages simplicity. It is necessary for the lower level design and approach to match the higher-level architecture for the solution to be cohesive. Once the development leader has internalized their portion of the architecture the SA must continuously motivate and reinforce the good work that is being done. They must continue to motivate the Developer Lead(s) to push through tough issues and create the solution.
Getting Started as a Solution Architect
For most people becoming the SA on a large project doesn't just happen. It's not like winning the lottery where one day your name is drawn out of the proverbial hat. It is, instead, a slow steady progression of learning and developing. A person may find their way to this coveted role within only a few years of professional experience but more frequently it takes a dozen or more years to consistently find themselves in this role.
The starting point is generally being the only person on a very small, and sometimes insignificant project. The project may be small enough that a single person may fill every role - including the role of solution architect. These little projects can even be ones where the organization hasn't identified the project as something that needs to be done yet but are items that a member of the software development team realizes that would be helpful.
Another approach to becoming a SA is to become a distinguished Development Lead (DL). The SA role and the role of the DL are very similar in the skill sets needed. The SA skill set is slightly broader and requires a bit more finesse, however, fundamentally the same. The SA lays out the architecture for the overall solution whereas the DL converts that architecture into detailed design. One approach to getting started as a SA is to become a DL and work towards the additional skills that a SA possesses. Most SAs have that ability to give some of their work to DLs looking to step up.
One of the ways to demonstrate an interest in the SA role, no matter what role you may currently be filling is to invest time in learning patterns. Because patterns form the basic building blocks of nearly every architecture, learning patterns makes it far easier to identify where they can be helpful. Also, reading books and articles on different architecture perspectives and new development techniques can broaden your point of view and allow you to see opportunities to create your own small sections of the solution.
The distinction between a development lead and the SA are often subtle. Where the development lead focuses on detailed knowledge of a particular area the SA is very broad. This allows the SA to view the problem from a different perspective. Instead of getting mired down into the details of implementing one specific thing the SA focuses on integrating various parts of the solution into one cohesive network that solves the larger problem.
The other subtle change is in accountability. While the development lead is responsible for their part of the solution, the SA is the proverbial one neck to choke if it doesn't all come together right. The SA has the ultimate responsibility for making the technologies work together. As a result the SA role comes with a requisite level of responsibility for the success of the project.
What's in their Toolbox?
The toolbox of a SA has more tools in it than most other roles. Most SAs have grown up in the software development world and have learned dozens of tools designed to help them be more productive.
Perhaps the most important tool in the toolbox is a visual documentation language, such as UML. The UML structure for describing a variety of different views of the software development problem in pictorial form is the most recognizable visual documentation language for developers. The SA should be familiar with each of the various UML forms and have expertise in the development of use cases, class diagrams, and occasionally state diagrams as well. Mastery of UML allows quicker, easier, and better communication with the DLs and the developers.
In addition to UML, the SA may need to be good at database design. Because most of the time the way that data is stored and retrieved is integral to the success of the solution, knowing how to design a database to hold the information is a critical part of the solution being successful. SAs know how to create databases and optimize them for good performance.
In addition to mastery of UML and database design, it's sometimes necessary for the SA to have experience with specific tools and processes when the organization has decided upon a specific process for software development. The most common software and process is the Rational Rose Unified Process. Other tools and processes exist the ones that the SA will have to master are based on what the organization has chosen.
Perhaps the most critical skills for the SA are the ability to create consensus and understanding around the architecture. While a development lead my need to involve a few people in their detailed design the architecture of the application touches every member of the team and there's a need to get them to understand it and agree with it. Once the SA has created the architecture it's time to communicate and sell it.
Where's the position heading anyway?
There is a great deal of pressure in the US to move development to countries with cheaper labor. While the SA role could be outsourced, , there is some insulation because of the need to work closely with the Functional Analysts in the gathering and organization of requirements. The distributed software of the global world requires more effort on the part of the SA and increases their need.
The overall need for SAs will continue to increase as the problems that the SMEs present are more complex and thus they require more complex solutions. The more complex the solution, the more SAs will be required to create it.
The software development tools were supposed to reduce the effort of the SAs and therefore reduce their need for the role, however, that increase in efficiency has been far outstripped by new demand.
The Good, the Bad, and the Ugly
- Good: Key, High-Value Position - The SA is a key role and one which can provide immense value if done correctly. This generally means a healthy salary.
- Good: An SA is likely to get to interact with many of the key members of the development team as well as key members of the user community. This makes it a very visible position.
- Bad: Hard to keep up - Being a SA means keeping up to date on a wide variety of new techniques, patterns, and tools. The effort to keep up can be very draining at times.
- Bad: Difficult to get right - The role requires balancing so many factors that it's difficult to get right. In other words, it's easy to fail.
- Ugly: Requirements - Although a good Functional Analyst can provide great requirements a moderately skilled one may not. The difficulty is that most people, including seasoned SAs, have trouble spotting bad requirements documents before it's too late. The SA must always have to consider that the requirements may require the SA to do a lot more research and legwork into what the client really needs.
- Ugly: If a project fails, the SA is at the top of the list for people to blame.
Conclusion
The solution architect role may be the most sought after role in the software development process but it's not without its challenges. Learning the broad array of skills, shouldering the responsibility, and dealing with the consequences can be more than the average mortal may want to take on.
About the Author
Robert Bogue, MCSE (NT4/W2K), MCSA:Security, A+, Network+, Server+, I-Net+, IT Project+, E-Biz+, CDIA+ has contributed to more than 100 book projects and numerous other publishing projects. He writes on topics from networking and certification to Microsoft applications and business needs. Robert is a strategic consultant for Crowe Chizek in Indianapolis. Some of Robert's more recent books are Mobilize Yourself!: The Microsoft Guide to Mobile Technology, Server+ Training Kit, and MCSA Training Guide (70-218): Managing a Windows 2000 Network. He was honored to become a Microsoft MVP for Microsoft Windows Server - Networking. You can reach Robert at Robert.Bogue@CroweChizek.com
Backtrack: http://www.developer.com/mgmt/article.php/3504496/Anatomy-of-a-Software-Development-Role-Solution-Architect.htm