Thoughts on being a Solution Architect

About a year ago I put together a post called Thoughts On Product Management, containing some random musings about my role at the time. The big reason I put together this post was because so few people had any idea what this job involved or why it is important.

Now that I've got "Solution Architect" on my business card again, I thought it would be worth putting together a sequel post. However the role of "architect" suffers from an entirely different problem to product management, which is that so many people interpret the role in so many different ways. Partly this is because there are so many different types of architects, such as enterprise architects, application/solution architects and infrastructure architects. But even within just one of these job titles, I've see a huge variation in different people's interpretation on the skills, tasks and responsibilities involved.

I'm not going to pretend to be able to answer the question of what a solution architect should do any better than anyone else can. But I did want to share some of my own experiences on what seems to work well - much of it learned from working with other architects on past projects, and hopefully still relevant and effective for my current team. I'd also like to hear your thoughts, whether you are a solution architect or someone who works with one, about where you think the most important responsibilities lie.

When I look at the work of a solution architect, I think it's interesting to separate the "what" from the "how". The "what" side, while definitely not simple, is probably the less contentious. Figuring out how to meet current and future business and non-functional requirements, making sense of new approaches and trends such as SOA, ESB, Web 2.0, federation, etc, and determining where and when to apply patterns are the bread-and-butter of an architect's job. But what does that really mean on a day to day basis? That's where the "how" comes in, and I'm sure that like me you've seen a huge variety of approaches. The stereotypical extremes are the "ivory tower architect", who has a three-ring binder full of Zachman matrixes and UML diagrams but is completely disconnected from reality, and the "developer in denial", who is really just a developer who wants a more fancy job title.

I'm sure you won't be surprised to hear my view that a real architect needs to lie somewhere in the middle. Certainly architecture is a distinct discipline from development. While moving from development to architecture is a common career path, just because you are a good developer does not mean that you are necessarily destined to become a good architect. And the reverse is also true - most architects (myself included) are not able to keep up with the coding skills of the developers on their teams, especially once they stop full-time development. That said, I personally do not see how someone can be an effective solution architect without some kind of development background and a thorough understanding of the application's ever-evolving code base.

So without further ado, here are some of my current thoughts on what being a solution architect (specifically one in an agile team) is all about.

Minimise the amount of code the developers need to write

Developers are paid to write code, and they are generally excellent at it. However once a developer is assigned a swag of requirements or stories they need to get down to work on those specific requirements, and it's not easy for them to keep up with what everyone else is doing in any level of detail. This can include discovering synergies between different requirements or opportunities for macro-level code reuse and refactoring. A big part of the architect's job is to pick up on these opportunities as they arise and ensure that developers aren't reinventing the wheel in their own worlds. Ideally this should result in patterns, components and frameworks that allow the developers to get their requirements done with less code, by concentrating on those parts that are unique.

Ensure an approach works before you ask the team to follow it

While it's nice to be able to replicate approaches that have proven successful in the past, new technologies and unique projects mean that it's often necessary to break new ground. Dealing with these challenges is a part of the job for everybody in the project team, not just the architect. However when there is a work coming up which will require the attention of multiple developers at the same time, those developers will be a lot more productive if they are given some initial guidance on how to approach the problem. Some architects like to communicate to developers with documentation, which can be fine when the approach is well understood. But when the solution has never been tried before, I believe it's critical for the architect (possibly with help from others) to do enough prototyping to ensure the solution is sound before it's handed over to the dev team for the real work to begin.

Make sure the requirements, and the technical implications are understood before it becomes a distraction

Business priorities and requirements are always in flux. The great thing about agile projects is that this fact is embraced rather than feared. Good developers and testers are able to cope with change well through high test coverage and continuous refactoring - but at the same time it's important that developers don't get too distracted while there is still considerable churn in requirements. Understanding how new requirements get injected into the project is largely the domain of product and program managers, but the architect has an important role to play too. In many situations I've found that the business stakeholders will modify, reprioritise or cut requirements based on advice on the technical implications. This process can take some time, and I believe it's important to shield the development team from most of these discussions so they can concentrate on implementing and testing the requirements that are better understood.

Put together just enough design docs and diagrams, just in time

I've seen a huge spectrum of opinions on how much, and what kind of documentation architects should produce. In my experience, face-to-face discussions over a whiteboard or computer terminal are normally a far better communications tool than any kind of documentation - however this does not mean that documentation has no value. In particular when there is a need to persist ideas or solutions for the team or external stakeholders, documentation is unavoidable. My strategy is to write documents only if I can identify the exact individuals who need it, and to hold off on writing the documents to the last responsible moment (to avoid rework when everything changes). In practice I tend to produce small design documents (typically about 5 pages long) throughout the project that each drill down on one specific topic. This may include a few block or UML diagrams, but I don't like to use any standard templates as each topic will require a different level of detail and will need to be explained differently.

Do enough development work to stay relevant

Whenever someone assigns me a requirement or a bug I often joke that if they want it done anytime soon they really should assign it to somebody else. There is quite a bit of truth to this - on any given day I'm randomised enough to make it difficult to make a lot of progress on development tasks. Still I believe it's very important to have these tasks on my plate (especially when I get the fun ones!). The main reason is that it forces me to stay familiar with the code base and the day-to-day issues facing the team (like how long it can take to check in!).

Help with questions, problems and code reviews at any time

I've left this one for last, but I think it's the most important part of my job (and definitely most time consuming!). On any given day most of the developers in my team will come up with unexpected issues and questions. In most cases they can be resolved with a quick chat or whiteboard session, and in almost all cases everybody involved contributes great ideas that help shape the solution. Since these kinds of issues are by definition unpredictable, helping people out with these can be quite a distraction. However if somebody isn't available then small issues can become major roadblocks very quickly. In addition, participating in these discussions helps me keep my finger on the pulse of what issues the team is facing, and can sometimes uncover a need for the overall architecture to be revised to minimise future issues.

So consider this one more opinion to add to an ever-growing collection of thoughts on this topic. As always, I'm always very interested in hearing yours as well.

Source Click Here.