Software architect

As explained in Collaborative Software Design: How to facilitate domain modeling decisions

A software architect is a person responsible for making and communicating significant structural decisions about a software system.

A software architect makes significant structural decisions while helping teams understand, discuss, and own the architecture. The role works best as an enabler rather than an external designer who becomes a delivery bottleneck. section 1.2.5 section 1.2.4

In an Agile setting, architecture develops through collaboration, experimentation, prototyping, and emergent design. Facilitation makes disagreements visible, helps groups reach supported decisions, and connects stakeholders with the engineers implementing the result. section 1.2.5 section 1.2.4

A practical architect can:

• Initiate collaborative modeling sessions instead of imposing a design. section 1.2.5
• Surface stalled disagreements, false consensus, and other social dynamics affecting design. section 1.2.5
• Help teams take ownership of architectural decisions and shorten feedback from requirements to deployment. section 1.2.5

When architecture stalls delivery

At BigScreen, disagreement between two people brought architectural progress to a standstill. A facilitator-led collaborative modeling session could expose the competing assumptions, involve stakeholders, and help the team make a decision it can support. section 1.2.5

Figure 1.4 Detailed diagram of the Waterfall process

Use the Waterfall process diagram to contrast sequential architect-led design with collaborative, iterative architectural work. section 1.2.4

How Collaborative Software Design: How to facilitate domain modeling decisions covers it

How deep it goes

Develops facilitation, collaborative modeling, and social dynamics, but does not detail specific architectural structures or implementation techniques.

Examples

Uses BigScreen’s stalled architectural disagreement and the contrast between Waterfall design and collaborative Agile architecture.

What you can do after

Apply it via collaborative modeling to facilitate supported architectural decisions with teams and stakeholders.

How it connects

Connects software architecture with Agile methods, collaborative modeling, emergent design, prototyping, stakeholders, and team ownership.

liveBookmanning.com

Read Collaborative Software Design: How to facilitate domain modeling decisions on liveBook Get the book at manning.com

Also explained in

• 

  liveBookmanning.com
  Lead Developer Career GuideA professional who designs the high-level structure, technical direction, and integration of software systems.

Compare how 2 books explain software architect →

Related concepts

• technical leadcontrasts with · A technical lead is a software engineer who provides technical ownership, direction, coordination, and guidance for a team or project.
• feedbackuses · Feedback is information about an action, system, or outcome that can inform evaluation, decisions, or subsequent behavior.
• tradeoffuses · A tradeoff is a situation in which improving one objective or property requires accepting a cost, limitation, or reduction in another.
• collaborative discovery and modelinguses · Collaborative discovery and modeling is a group technique in which stakeholders jointly create and refine representations to establish shared understanding of a domain or system.
• designconfigures · Design is the process of planning and specifying an artifact’s structure, behavior, or presentation, and the resulting arrangement, to meet intended purposes and constraints.

This explainer was generated by Manning's knowledge graph from the text of Collaborative Software Design: How to facilitate domain modeling decisions. The section links point to the parts of the book it draws on.