At work we’ve been looking at how to improve our processes for quite some time. Essentially, our goal is to increase both customer and worker happiness by introducing a new methodology for how we work. We’re basing it on MSF Agile, Scrum and to some extent eXtreme Programming.
One of the things I’ve been struggling with getting right in our methodology is defining the different roles in it. MSF Agile provides a base for this, but there are some things in there that I’m not quite happy with. One of the most difficult areas is the difference between a business analyst and an architect, and how much both are required to understand of and take part in defining the business requirements.
In MSF Agile the Architect’s role is described as “The architect’s main goal is to ensure success of the project by designing the foundations of the application. This includes defining both the organizational structure of the application and the physical structure of its deployment.”
The Business Analyst on the other hand is defined as “The business analyst’s main goal is to define the business opportunity in the form of a solution that will provide value to the customer. The business analyst works with the customers and other stakeholders to understand and translate their needs into persona definitions, scenarios, and quality of service requirements that the development team will use to build the application.”
The problem I run into in real life is that for the architect to be able to design a good solution he really needs to understand the business requirements, but he might not be the person who is best suited for eliciting those requirements. The business analyst, on the other hand, rarely knows enough about software design to sketch out a correct solution. Some of them do try, but rarely with good results. And who should actually be responsible for UI design? MSF Agile says it is the business analyst, but we’ve also observed situations where that might tend to guide the solution in a direction where the UI mimics any existing solution as far as possible. Some times that is a good thing, sometimes not. On the other hand, some architects are seriously unsuitable for UI advocacy, so where should it be? I strongly believe an architect needs to have an understanding of the business, and act as some kind of bridge between the technical and the business side, but I have found it hard to put this in words that clearly define where the responsibility of the architect ends and that of the business analyst begins.
TechEd 2006 Pre-conference session on architecture
I didn’t actually know what to expect from this session. There actually weren’t that many preconf sessions that seemed interesting, because they all appeared to be pretty entry-level. I picked this one based partially on the people running it but also because the field of software architecture is so vast that you can always learn something new. It turned out that this session was valuable to me mostly from the point of view of how to organize the architectural activities in our company and how to train people to become architects.
In the preconf Ron Jacobs talked about what an architect is and what he should be doing. He structured that around three different areas, analyzing different key aspect of an architect.
The architect as an explorer
This one I identified with a great deal. He made comparisons to Vasco da Gama and Christopher Columbus; men with a vision of something that could be done to solve a problem, and with the guts to believe in that vision despite it flying in the face of what was considered accepted knowledge at the time. The architect has to have the vision to see which of the emerging technologies, tools or practices will become commonplace and which can be used to solve a specific business need. He needs to be able to convince people of their suitability, and in the end be accountable for what happens if they are used.
The architect as an advocate
This is about the architect understanding the business domain. About listening to the customer and trying to understand what it is that really is required in order to provide a solution to their needs. Learning the business domain is necessary in order to design a system that is correct for the specific situation. This involves observing the domain in order for sufficient knowledge to be obtained.
Here is one area where I might slightly disagree with Jacobs. His view on this included quite a lot of things that might belong in the domain of the business analyst as well. As I mentioned earlier the architect needs to have the ability to understand the business, but he might not be able to elicit them from the customer efficiently.
The advocate-segment also contained a piece on strategy. Strategic understanding and thinking is required on both the technical (what tools/technologies can solve a particular problem) and business (how can the business develop over time, and which sections of the software are relevant from that point of view) levels, and again the architect and the business roles clash somewhat.
The architect as a designer
Designing the correct solution involves understanding the engineering constraints involved, understand the user needs for the solution, and doing so through a solution that is both beautiful and elegant. In a way this ties together the two previous areas, where you combine a vision for how to solve something with a thorough understanding of what you are trying to solve.
The architect vs. the business analyst
A lot of the stuff in the preconf was interesting and was stuff I agreed with, but didn’t give a clear answer to my question of what the separation of the roles of the architect vs the business analyst is. But when looking at what architecture is an answer started to emerge. Jacobs said that “Architecture is an idea, a plan of the solution that will be built”. And to reach the level of an architect was described as “Becoming an architect is a journey towards becoming one who dreams of the solution rather than the one who builds it”. Pretty inspiring, but how should it be interpreted?
In my view this is where the answer to my question lies. The role of the architect is to envision the correct solution to a given problem. The role of the business analyst is to make sure that we are trying to solve the correct problem, and to define what that problem actually is. That means that eliciting requirements and defining the vision for the project should be the responsibility of the business analyst. The architect needs to have the ability to understand and care about the information given to him by the business analyst, but he does not have to know how to extract these from the customer.
So in the end, should we perhaps think of the Business Analyst as a proxy for the customer? A way to achieve what XP calls an on-site customer, i.e. a person who is available all the time to answer questions about what the customer needs and how it should work? And perhaps as a more coherently packaged version of the customer, one that is actually able to express what he needs, instead of what he thinks the correct solution to these needs are. Because in the end, the reason for introducing a business analyst role is because the customer can not himself express the business problem to the architect or the developers on such a level that makes it possible for them to come up with and develop a solution that solves the customer’s problem. Much too often the customer expresses a need that might not be the actual need, but a symptom of it. This actual need is what the business analyst needs to determine, and to communicate to the architect and the developers.
Seems good. Let’s see how long this lasts until I change my mind about it. 
One last thing: I feel it is very important that the architect also writes some of the code for the system. If he isn’t involved in the development there is a significant risk that he becomes so detached from the actual day-to-day process of developing the solution within the given constraints, and then dreaming of the solution becomes just that, a dream that can not be translated into practice. For this reason I think it becomes difficult to combine the roles of the business analyst and the architect, especially if the person in this role comes from the business analyst side. He will most likely not be able to contribute to the code on a level that corresponds to what I wrote here.
