The Role of the Software Architect

Hayim Makabee

International Association of Software Architects in Israel

About Me:

Education:

Experience:

Today:

Roles in Software Development

Software Architect

Product Owner

Developer

Tester

Technical Writer

Methodology Decisions

The software architect should participate in decisions about the

software development methodology.

Examples of methodology decisions:

1. Agile methods imply reduced design up-front and thus some form

of emergent or evolutionary design.

2. Test-Driven Development (TDD) reduces the risks associated to

Refactoring and thus requires less detailed design.

3. Pair Programming requires less design and code reviews.

Non-Functional Requirements

Non-Functional

Requirements (NFRs)

Examples of NFRs

Latency

Throughput

Robustness

Scalability

Fault-Tolerance

Architecture Planning

(High-Level Design)

Architecture Discussion:

• Frameworks

• Platforms

• Technologies

• Abstraction Layers

• Components

• Design Patterns

High-Level Design Decisions

Examples of high-level design decisions:

1. Service-Oriented Architecture (SOA) based on stateless RESTful

services returning JSON objects.

2. Staged Event-Driven Architecture (SEDA) based on message

queues and adaptive load balancing.

Requirements Specification

Use Cases

(Functional Requirements)

Use Cases

Requirements

Discussion:

• Generalizations

• Commonalities

• Patterns

• Exceptions

• Impact on NFRs

Domain Modeling Decisions

Given the Requirements Specification, the software architect

should participate in Domain Modeling.

Examples of domain modeling decisions:

1. Should a relationship be represented as an object or as an

association between two objects?

2. Should an object have a fixed list of attributes or a dynamic set of

properties?

3. Should an attribute be represented as a primitive type or as an

object?

Planning for Software Evolution

Planning for software evolution requires a good understanding

of the application’s domain:

Modeling of the main domain entities, their attributes and

relationships.

Refinement of generalization/specialization hierarchies.

Identification of the domain aspects that are not represented in the

current requirements.

Identification of areas of volatility that are likely to change.

Domain analysis should drive the introduction of mechanisms

for flexibility and extensibility.

Design Reviews

Design Review:

• Several design alternatives

• All alternatives satisfy FRs

• Different alternatives have

different impact on NFRs

• Discuss trade-offs

Design Integrity

Software Quality Attributes:

Correctness

Modularity

Coupling

Cohesion

Testability

Maintainability

Extensibility

Reusability

Multi-product Company

Sharing opportunities:

• Technologies

• Infrastructure

• Components

• Patterns

• Reuse

Product A

Product B

Product C

Infrastructure Team

Development of new:

• Infrastructure

• Reusable Components

• Tools

Product A

Product B

Infrastructure Team

Non-Functional Testing

Non-Functional Testing:

• Performance Tests

• Load/Stress Tests

• Robustness Tests

• Simulators

• Bombers

• Log Players

Internal and External Documents

External Documents:

• User Guides

• Manuals

Internal Documents:

• Infrastructure

• Service Interfaces

• Proprietary Protocols

Summary

The Software Architect works in tight cooperation with:

Product Owners: Functional and Non-Functional Requirements

Developers: Domain Modeling and Design Reviews

Testers: Non-Functional Testing

Technical Writers: Internal and External Documents

Multiple Teams: Reuse and Infrastructure

Thanks!

Q&A