The role of the software architect is yet a subject of various debate: it's vaguely determined, hard to define and sometime misleads to nonsense responsibilities in some job descriptions.
I won't discuss here about what is the precise day-to-day job of an architect inside a team or a company, but I will try, through my experience, to describe some of the aspects and the qualities that any architect should have.
Many of us think that we are the main person or the hero of a team/company that holds the design or that solves the hiccups throughout a project's live. Definitely, we are not movie stars nor gurus, but certainly we are change catalysts by guiding, enabling and moving people.
Architects are skilled craftsmen
Skill as in the ability to use a specific set of knowledge to relate to a specific context.
It is a large definition depending on how the functional/organizational/business/enterprise/marketing or technical field is.
I don't think, however, that an architect must have or pass multiple exams and certifications to master all these fields, but I assume that when facing any new challenge, he has to be the referring point to drive the team and the [technical] vision of any project.
You may know that creating software architecture is not a process we may plan ahead of time, it's about how you employ your skills and experiences to guide a process with some accuracy.
Though, as I often say:
your smartness is about the way you are hitting on the solution, not the solution itself.
Spot that the solutions made for a project aren't necessarily an applicable artifact for another, but the effort that went into making those solutions and the experience gained can be seen as a skill that can be reused and seen as an asset.
Unquestionably, architects have to be logical, methodical and organized. They have to be passionate, self-disciplined with a mindset of achievement.
Architects are storytellers
Alistair Cockburn said once :
“At its core, software development is people inventing and communicating, solving a problem that they do not fully understand, which keeps changing underneath them, creating a solution that they do not fully understand, which also keeps changing underneath them, and expressing their thoughts in artificial and limited languages that they do not fully understand and that also keep changing underneath them, to an interpreter that is unforgiving of error, where every choice has economic consequences, and resources are limited. Software development is a resource-limited, goal-directed, cooperative game, whose moves consist of invention and communication.”
-- The end of software engineering and the start of economic-cooperative gaming, 2004
To rephrase his quote, let's say that an architect must be a great interpreter, He must be available every day:
- discussing with stakeholders in order to understand the real needs,
- talking with the managers to notify and alert about the risks and how to avoid them,
- and finally, understanding and driving the teams by giving them the vision, the keys and the responsibility of what will be build and delivered.
Architects must be storytellers: they must share enthusiasm, engage and excite their audience, able to explain complex concepts and topics using simple explanation and particularly build a relationship through their story.
However, semantics are essentials. Depending to the audience, the jargon has to be to adapted and be comprehensible; as an architect you have to rule out any misleading understanding and support a clean vision and ideas.
Thus, dealing with people and being a hub between multiple teams or levels means in multiple ways to know how to manage conflicts.
Conflicts are usually issued from insecurities (or often from ego) which are often unsaid, kept hidden and they are extremely contagious.
As an architect you have to be a good observer to identify such problems and empathize with them in a very non-threatening manner, and usually in private.
Architects are doubtful artists
It is tempting to think that the goal of the software architecture is only to build an intricate yet adequate diagram of components with relations among each other or to choose what tools and impose the patterns to implement. And also that the completeness of the architecture is somehow measured in terms of how the architectural artifacts of the system look.
Sorry to say, but this is the narrow view of what architecture is.
Architecture is about understanding the requirement, the propose and the goal of the system, its added value, benefits, complexity and sustainability.
Notice that any implementation is a technical answer to a precise requirement, and we all know that we can't be certain about our choices without being aware about what are the final result.
As a rule, before any design process, you need to take a step back in your mind and see the design in full function. This has to be done before any cardboard mock-ups or prototypes are built, and the process should be revisited at every major change point during the life of the project.
The architect has to mimic the user and see himself using the system.
Albeit that the end user is not the goal but his expectations are, the fulfilment of this goal is the real reason for which a system will be built.
The better the architect is at seeing this, the better he will be at understanding what needs to be put or implemented.
I believe that art is a big part of software architecture, and that is the ability to visualize a product ahead of time, to feel it or envision it as a whole large solid system in a quite rich detail. It's not only about skills and experience but more about experimentation, creativity, awareness and adoption.
As an architect, you must have a good imagination and be good at painting mental pictures.
This skill may be taught, but aptitude for this activity is critical. Experience builds it, too.
By having this mental picture in your head, the real design process will be more accurate and elegant, which does not end until the project ends.
Architects are negotiators
Undoublty, any project is always an acknowledgement to a customer's purpose, and often the latter himself is the main provider of the trickiest parts of the project: the constraints and the users.
A software is always a tool that any end user needs to simplify and/or eliminate constraints in an activity or a workflow, and often to accelerate the gears by decreasing the latencies.
Usually what's obvious and trivial to a customer/end user may mean more hidden constraints and extra work, thus costs for the project.
In fact, depending of the size of a project, there are several other roles as the business analyst function that can handle much of the work of requirements gathering. Even though an architect might not have to be personally involved in requirements gathering, but no matter what the final specifications are, the architect always needs to comprehend and feel what the end user really needs.
Remark that for any expressed requirements, end users don’t understand technology and developers don’t understand people! Hence this is one of the problem that needs to be smartly bridged.
Understanding the needs, making and trading choices, negotiating about eliminating or delaying a request, bargaining about using a technical solution or pattern are the day-to-day tasks of the architect.
As an architect you have to be good negotiator, with a large visibility on the project's goals and at the same time being details oriented to drive correctly the project.
However, Architects don't have to be talented psychologists, but you have to feel how the winds blow in an organization (customer, managers, stockholders, team), especially if the winds are not just gentle breezes.
I think that is a fundamental mistake to not listen to the organization when creating architecture.
Architects are decisions makers
I believe that any architect constructs the architecture of the solution in a manner that enables developers to use their tools effectively.
He enforces high standards and makes sure that work on the project is as enjoyable, straightforward and efficient as possible.
Yet it's not only about the implementation, but about the best practices and the best tools to use to deliver the project.
It's not about the wide-ego and guru-attitude, but about decision making and the choices to make that fit to the requirement.
this being said, Uncle Bob said :
Good architecture allows major architectural decisions to be deferred. The job of an architect is not to make decisions, but to defer decisions as long as possible, to allow the program to be built in the absence of decisions so that decisions can be made later with the most possible information.
Gregor Hohpe rephrases this in his book The sofware architecture elevator by saying:
[...] Architects are commonly described as the people dealing with nonfonctionnal requirements ... they deal with nonrequirements.
Architecture isn't good or bad, it's fit or unfit for a purpose.
Obviously, Decision is about the context, the trade-offs, the choices, the possibilities and finally the proof.
Hence, A software architect is always labelled as the flame keeper who owns the principles of the project: He don't let stress get the better of him, he assesses the goals and the values, he evaluated the choices and rethink about them.
He must be a stickler for detail and an enforcer of high standards, while always having the guts to make critical changes to a design when necessary.
Architects are agile wizards
First, let's assert that:
Adaptability is mostly centred around considering all possible options, identifying opportunities and devising a plan, whereas agility is more about having the confidence to take swift and decisive action in the face of unexpected change.
Admittedly, one of the main purpose, and the most valuable one, of the Agile Methods is to deal with the uncertainty like uncomplete/hidden requirements or any potential risks.
Moreover, architecture is a journey on an unknown road where we spend most of our time dodging speed bumps and potholes. Architects must provide systems that can evolve alongside with the increasing understanding of the needs and the technology.
Proposing or setting boxed-monolithic-tightly-coupled software or code can't help you if you have to steer out of a pothole, in fact it's a nightmare scenario.
Any system that can't be touched, that can't evolve or changed and has no agility at all is by definition an isolated legacy system.
The value of an architecture increases with its ability to change and insure the sustainability of a system.
Event though, most of architects may adopt "Fail fast, Learn fast" but that has more impact of the overall quality, however reacting quickly and prioritizing changes make your system sustainable by achieving and following the suitable architectural patterns ...
Architects are influencers and impact makers
As stated above, the role of an architect is not limited to be labelled as a technical wizard, his interaction with his peers inside and outside a project may forces him also to push the limits, to improve the global moral and to steer the global vibes.
Furthermore, architects have to break the ground with new ideas, outspread new concepts, and derive new proposals. Additionally, by taking time to be out of their comfort zone, they'll generate more opportunities and may inspire their peers
Likewise, by updating their colleagues about the progress and sharing their knowledge, they engage them to share and collaborate with each others.
Architects have to deliver also a high quality work and be sure that they can be trusted by sharing their skills, oversight and good solutions, they have to be the person other people count on by offering help, patience and understanding. He's the model to follow and to refer to for his proven sense of leadership.
Additionally, architects have to speak up, share, state and defend their opinions by being opinion leaders but also they have to be great listeners and empathetic.
and obviously, Architects are agnostic
Being technology-agnostic prop up that there is no ‘one size fits all’ for a particular problem, there are many ways to solve it.
It means also that a decision to use or not a technology/component/solution/pattern is an educated decision based on wisdom and experience.
Ordinarily, the architect position is (one of) the natural evolution of a skilled developer, but being an architect you have to remind yourself that "technology is a tool", it may be leverageable or disposable.
You have to focus on the big picture and understand the limitations of any (to be) proposed solution according to the customer's constraints and requirements, it's not just choosing the cheapest solution that your are most familiar with.
Similarly, you have to be flexible, open minded and self confident to dive into a huge spectrum of tools, solutions and brands across the market. The architect's maturity is by avoiding vendors lock-in, high dependencies and insuring to accommodate the architecture and cost-save the project without making expensive modifications.
Generally speaking, it's about the good toys for the good purpose.
Closing
Despite the fact that I wrote the first draft of this post some 8 years ago, this updated version summarizes multiple thoughts, experiences, readings and findings. I'm sure there is lot of missing here, but I chose to not go deep in the low-level/day-to-day details but share the most common qualities that a software architect must have.
Let's not forget that the customer wants to efficiently and preferably enjoyably use his software, the software architect has to focus on realizing this and keep the goals clear.
It's not an easy job, but we have to measure our value in our ability to understand the hidden requirements and the trade-off, to look and foresee beyond the product and being articulate while delivering a high quality package.
If you liked this post, follow me on my blog for more.
Top comments (0)