Introduction
Some time ago, I came across a software architect who had the “my way or the highway” attitude on providing solutions. I had a very interesting conversation with him about IoC containers; here is a part of the conversation:
him: What are you using currently as the IoC container?
me: I wrote one based on our companies requirements.
him: No, you cannot do that, you have to use Microsoft’s Enterprise Library!
This is totally opposite thinking approach to mine; so far I read, learned and experienced about software architecting is that you cannot hold on a solution and try to stick it into every problem. First, the famous saying, “If you only know how to use a hammer, every problem is a nail” comes to my mind, second I’m asking what does he know about my problem domain? Does he know what my non-functional requirements are? Does he know what kind of company, team, time or project I’m talking about? Certainly not, he is just thinking solution first!
After thinking about this situation, I figured out that a lot of people are thinking alike: certain things HAVE to be done in a certain way with a certain technology. I believe that this mindset is the biggest roadblock of becoming a good architect who delivers projects successfully. Therefore I decided to write this post to explain what are some basic steps that you have to follow which will help you to become a better software architect or better said, deliver projects successfully.
The key term here is “successful project”; a project is meant to be successful when it complies with the requirements. Having said that, the most important aspect of a solution is to be compliant with the requirements.
Requirements
Requirements describe the problem domain. Depending to the project and the chosen methodologies, the requirement can be acquired in advance or can be adjusted while the project is in progress. Requirements are provided by the stakeholders usually in a form of a document named System Requirements Document, which could be directly a subject matter expert or a business analyst which is a domain expert.
Note: This document should not be confused with a project vision document. There are different deliverables in software development projects. For more information, you can visit Microsoft Solution Framework resources like this link). Actually, some projects are not started with a requirements document, but that does not mean that we can just omit the requirement; an architect needs to work with the stakeholders. It is also well-known that there is nothing temporary than permanent requirements in a project:) but this fact should also not be a reason to act like a stranger to the stakeholders.
The problem domain contains a horizontal and a vertical axis. Mostly, the stakeholders are responsible for the vertical axis which contains their specific industry knowledge. The horizontal axis defines domains which apply to all industries, like SSL, WCF, etc. But I’ve never seen a document defining the domains, we always define requirements and provide solution in domains.
Requirements are divided into two main categories named functional and non-functional requirements. Functional requirement defines what a system is supposed to accomplish, like input, output and behavior. Functional requirements are usually implemented in code; it helps to design a system and architect the application. But, I saw a lot of architects thinking that code is the only artifact that matters in a software development project. This mindset is known to be a developer attitude in solution space and architects should avoid it.
Note: This mindset is really hard to change especially if you got promoted from a developer to an architect. Unfortunately, that is the way it is happening today: once you develop software for 10 years, you become an architect. This makes us believe that architect is the next title. But in reality, software architecture is a totally different career path and just a small part is about coding. I strongly suggest reading Microsoft Architecture Journal 15 for those who are architects. A good architect understands that software solutions consist of more than functional requirements.
On the other hand, non-functional requirements define the operation of the system, which gives the project its unique flavor or better said quality. Security, performance, scalability, testability, usability, price, privacy, extensibility, support, deployment, etc. qualities are just a few of them.
It is very possible that functionally two same products can be totally different because they are relative to functional requirements, e.g., a web site which will support 10 users for its entire life would be different from a web site which will support million users.
Therefore, I believe that problem first thinking approach will save your project a lot of time and money; as much as you listen to your stakeholders, as much as you study them and understand the problem, as closer solution to their needs you will provide.
I saw the humorous drawing below, which is based on project management, but has some architecting flavor in it. I don’t know who the credits should go to for capturing this real world problem, but this picture is worth a thousand words.
Solution
The solution should always come after the requirement is understood well. But, that does not mean that the whole project requirement has to be understood well. You can grab one, all or group of related requirements, understand them, and work on the solution in that context.
That’s why I look at the solution as something relative to the requirement. And because every project is unique by time, company, team, budget, culture and requirements, it is impossible to have two with the same solution. Therefore, even having finished a project successfully will never guarantee you success for another one.
Every architect provides his solution in the way she/he knows the best. The only common ground is the industry proven patterns and best practices; those are an architects tool belt. An architect has to look at the requirements and investigate a tool for the problem. I’m not saying choosing a tool, because there are and will always be more tools than you know, no matter how much you learn. I’m suggesting to start every requirement by accepting that we don’t know anything about it. The worst thing we can lose is to read a subject the second time. But what we gain is to extend the solution space outside our knowledge.
Perhaps there is no exact formula of how to architect a good solution; there is common logic which every human brain can think about, there is experience which everybody holds a piece and there are diverse blogs like this to increase communal innovations. Please also visit the Microsoft Architecture Center which is a great resource for those who are on the architect path. And please don’t forget that every solution is relative to requirements, time and place.
Conclusion
Going back to the top of this post: I would expect from a good architect to reply to me as: “Interesting choice; what were the requirements to make this choice?”.
CodeProject
