AFAIK, there is no consensus on the roles or activities every software architect should do! Even different levels of architect titles (Application Architect, Software Architect, Solutions Architect, Systems Architect) has no formal job description and I saw them used interchangeably.
All architect's roles are determined by the organization she is working for!
In this post I will try to describe the most important duties that I believe an architect should be concerned about. Most of what you will read in this post are arguable opinions, but here is how I see it...
One of the concepts that was popularized by this book is Eisenhower decision matrix, where duties' priorities are divided into 4 categories:
If he sees that buying a solution is better, he should set selection criteria, analyze alternatives that match these criteria, and finally select the best fit from different vendors.
If he sees that building the solution in house is better, he should select technology stack, and do other related duties mentioned later in this post.
Managerial decisions like setting the budget, assigning resources, deciding the scope, ..etc, are out of architect responsibilities, although she may participate in them sometimes.
In such cases, the architect is making the decision not taking it.
By tactical decisions I mean cheap decisions that cost few hours to few days to change in future, like refactoring a given class, deciding to use certain design pattern, ..etc. An architect may participate in such decisions sometimes, but this is not his main concern.
I like to be called "Architecture Owner" instead of "Architect", the architecture owner facilitates the emergence of the architecture instead of forcing it. Architecture contributions are welcomed from all team member, but the architecture owner is responsible of accepting or rejecting them.
The Architecture owner's concerns are not limited to greenfield applications, but she should inspect brownfield applications as well, find design flaws, and lead the refactoring processes.
Among these important but underestimated software features: quality attributes, or non-functional requirements, like: Conceptual Integrity, Maintainability, Re-usability, Portability, Security, Performance, Scalability ..etc.
Quality attributes is a huge topic that deserve a separate article, or more!
Specifying the coding standards belongs to this category of duties as well.
All architect's roles are determined by the organization she is working for!
In this post I will try to describe the most important duties that I believe an architect should be concerned about. Most of what you will read in this post are arguable opinions, but here is how I see it...
Eisenhower Decision Matrix
[Source: Wikipedia]
I am a big fan of Stephen R. Covey and his awesome book: The 7 habits of highly effective people.One of the concepts that was popularized by this book is Eisenhower decision matrix, where duties' priorities are divided into 4 categories:
- Urgent and important
- Not urgent and important
- Not important and urgent
- Not important and not urgent.
If you want to achieve outstanding results, then you should focus in the second quadrant, in the important but not urgent duties, at which I believe most software architect duties fall in!
The Software Architect Role
Now, the role definition IMHO:
A Software Architect is a chief programmer who is the owner of every technical strategic decision in a given organization, by making or taking such decisions.The previous definition may seem a little bit weird, but I will illustrate it in detail in the following words...
Technical Decisions
The architect can analyze alternatives to make the decision whether it is better to buy or build a software solution.If he sees that buying a solution is better, he should set selection criteria, analyze alternatives that match these criteria, and finally select the best fit from different vendors.
If he sees that building the solution in house is better, he should select technology stack, and do other related duties mentioned later in this post.
Managerial decisions like setting the budget, assigning resources, deciding the scope, ..etc, are out of architect responsibilities, although she may participate in them sometimes.
Making or taking decisions
Most of the time, the architect will take technical decisions like the ones mentioned in the previous example, but sometimes his recommendations may contradict with some business or management constraints, for example, he decided that a given tool is very important for the organization, but it is a very expensive tool that the project budget cannot afford, then the project manager will reject the architect's recommendation, and the architect have to adapt to the new constraints by looking for open source alternative for example.In such cases, the architect is making the decision not taking it.
Strategic decisions
An architect is concerned mainly about strategic technical decisions rather that tactical decisions. By strategic decisions I mean expensive decisions that cost weeks to months to change in future, like selecting technology stack, setting the application architecture, what parts of the solution should be abstracted for future replacement?, ..etc.By tactical decisions I mean cheap decisions that cost few hours to few days to change in future, like refactoring a given class, deciding to use certain design pattern, ..etc. An architect may participate in such decisions sometimes, but this is not his main concern.
Architecture owner
I have seen brilliant solutions come out from the least experienced developers. So, don't underestimate your team skills; whatever experience the architect may have, there are many many gaps in her knowledge!I like to be called "Architecture Owner" instead of "Architect", the architecture owner facilitates the emergence of the architecture instead of forcing it. Architecture contributions are welcomed from all team member, but the architecture owner is responsible of accepting or rejecting them.
The Architecture owner's concerns are not limited to greenfield applications, but she should inspect brownfield applications as well, find design flaws, and lead the refactoring processes.
Quality attributes and the second quadrant
As I said before, most of the architect duties lie in the second quadrant of Eisenhower Decision Matrix, that is: the important but not urgent tasks.Among these important but underestimated software features: quality attributes, or non-functional requirements, like: Conceptual Integrity, Maintainability, Re-usability, Portability, Security, Performance, Scalability ..etc.
Quality attributes is a huge topic that deserve a separate article, or more!
Should architect write code?
Definitely!
I know the answer to this question is debatable, but I hate talking from ivory towers and proposing infeasible solutions!
The architect should get his hands dirty to be able to decide which technology/solution is feasible and which is not.
From the other hand, I believe the competitive advantage of architects come from their technical expertise and their hands on experience, once an architect start to write code less, his competitive advantage will fade!
To be fair at closing this important point, the architect should not spend most of her time writing code, I would say she should sometimes write code, not always. For example, to develop a Proof of Concept (POC) for a certain idea, to develop a solution for a challenging problem, to develop a tough part of the system end-to-end..etc. That is why I consider her a chief programmer!
Process owner
Every project has its characteristics, and there is no single process that fits all projects.
One of the architect's roles is deciding the best process/methodology that fits the project.
In agile environments, the architect may be seen as agile coach, or coach of coaches!
In agile environments, the architect may be seen as agile coach, or coach of coaches!
Other duties
The architect role intersects with other roles, he can sometimes do some secondary duties that are assigned to someone else in the team.
An Architect is a leader, he may review developers' code, he may teach them, he may pair with them,...etc.
An architect is a designer, he may do some detailed design, and refactor some parts of the system.
An architect may interface with higher managers, and with customers.
The architect may do some managerial tasks like following-up project statuses, assign resources, ..etc.
I have created a dumb shape to illustrate where the architect's role fall between other roles in the team.
The architect may do some managerial tasks like following-up project statuses, assign resources, ..etc.
I have created a dumb shape to illustrate where the architect's role fall between other roles in the team.
A final word: The architect in agile environments
An architect in agile environment will be concerned about strategic decisions upfront, and then be the architecture owner who is responsible of emerging the architecture incrementally.
Now, Your turn
I think this article is important and what I've said should not be by any means complete, and I hope from readers to enrich this post by sharing their thought in comments.
Want to know more?
I think the following books may help:
97 things every software architect should know -- Creative Commons license
