Comment by cies | Hacker News Reader

Comment by cies | Hacker News Reader

At the place where I work, I've recently described the role of Software Architect. It is a project-role, so only exists in the context of a project, and usually only in the first weeks of a project.

We describe it as follows (feedback is very welcome):

# What is expected of a Software Architect?

* Makes high-level technical design choices.

* Records those choices, and the supporting arguments, in a deliverable.

* Ensures feasibility of the technical approach (and informs the PM).

* Identifies risky aspects of the project (and informs the PM).

* Dictates technical standards (e.g.: coding standards, tools, frameworks, platforms).

* Provides the team with a "standard way" to develop the software.

* Ensures compatibility with Hoppinger's technical road map.

* Aligns all his decisions with the resource constraints of the project.

* Recognizes "reuse" opportunities (either existing software that can be incorporated, or spin-off contributed/reused).

* Observes and understands the broader system environment (of the customer).

* Creates architectural overview diagrams and/or descriptions when needed.

* Knows which applications are used in the organization.

* If possible: subdivide a complex application, during the design phase, into smaller, more manageable pieces.

* Understand the functions of each component within the application, and the interactions and dependencies between components.

* Communicate the technical design, "architecture", to developers.

* When needed also provides hardware requirements (or several options), considering the needs and abilities of the customer.

    usually only in the first weeks of a project

If you assume these are only needed in the first weeks of a project then it sounds like the classic waterfall fallacy. Preserving architectural consistency and evolving tech choices and adapting dev processes is a continuous process as a project grows and its easy to generate waste by front-loading too much of this.

My feedback on the list is that some of these qualities like handling risk, reuse, company/customer knowledge etc. should be expected of all senior devs. Other items like decision making, design diagrams, identifying standards etc. should be treated as tasks just like design, development and testing. They will regularly arise during a project and can be delegated across the team.

I would consolidate governance in the lead dev role - they are where the buck stops for all decisions, quality, consistency, delivery etc. but they do this by leading a team and delegating unlike an architect role that ring-fences categories of task for themselves.

Hope that helps!

Good points. We usually prefer to keep the lead developer responsible for all the project's architecture needs. This is more of a role in case the lead is not able to --from early on-- oversee the technical complexity of the project.

Thanks!

I think you are missing some key aspects of the architect role in that you don't mention requirements (apart from hardware requirements which are always funny coming from a developer...) and you only point the communication towards peers but not clients and business partners.

The architecture process can be summed up along these lines:

- Identify stakeholders, their concerns and objective. Translate these into goals and requirements;

- Understanding, validating and designing the requirements;

- Identifying possible solutions but also constraints, risks and assumptions. Document and validate them;

- Document decisions and solutions with blueprints and design documents (diagrams, tables, natural text, etc) that are actionable and can be used as reference material;

- Limit the scope of the development activity to the requirements in order of relevance (to the sprint, or other time-bound metric);

Behalve dat, goed geddan jonge! (edited for clarity)

Thanks for the insights! I'll have a look at incorporating you feedback into the list.

This is pretty much the description of an Architect that the article is arguing against.

From my experience, Architects that conform to the above requirements tend to sit in their Ivory Towers and are oblivious to the problems on the ground.

> ...and are oblivious to the problems on the ground.

Should they even care, if it's not their role? Engineers are hired to problem solve, architects are hired to design.

Think about an architect designing a building: should he/she know the intricacies of every separate sub-system in the building (plumbing, wiring, ventilation, gas...), or rely on experts in each of those sub-systems to resolve implementation issues? The architect is only concerned with pulling together all of these separate efforts to form something cohesive and elegant.

"Problems on the ground" can include things like how much sun the location gets, which direction it comes from, how cold the place is in winter and how many feet of snow it averages. An architect who ignores all these local details will be lucky to design a building that lasts a year.

Not many buildings would stand upright if what you said was true.

An architect absolutely needs to be on top of the technical implementation of both ventilation, fire systems and plumbing. They won't be the ones who installs them those things are taken into consideration when the plans come together. If you think an architect only dreams up what it should look like and then leave the project you are mistaken.

With that said, I think a building architect is a terrible metaphor for what's done in software engineering for plenty of other reasons.

And yes, you absolutely need to have intimate details of how the coherency protocol works if you are the software architect of a clustered system, just to take an example. In the opposite direction lies disaster (which I've seen first hand).

Interesting that you see it like this. In our case architects are (as the article also proposes):

* regular developers, yet senior

* work on/with teams (not part of a separate architects team)

Though I feel you do hit the point where the description could be written more in terms of "creates buy-in" and "raises awareness".

Thanks for the feedback!

>This is pretty much the description of an Architect that the article is arguing against.

I didn't get that at all. I imagined an architect described by that text as a role that one (or more) of the engineers takes on during a project to ensure its success.

Reply on news.ycombinator.com