Software Architecture Books Summary And Highlights -- Part 3 Development Process

 

Development Process

Highlights

Decision Making

Knowing we are going to get some things wrong, what are our options? Well, I would suggest finding ways to make each decision small in scope

MSV Ch 12 Bringing It All Together

Detecting problem early in development workflow will lower the cost of solving it significantly.

SWG ch 1 what is software engineering?

Data driven culture: back decision by data. And decision can be corrected if the new data shows a changing pattern.

Being data driven is a good start, but in reality, most decisions are based on a mix of data, assumption, precedent, and argument. It’s best when objective data makes up the majority of those inputs, but it can rarely be all of them.

SWG ch 1 what is software engineering?

It is better to fail fast and iterate. Failure is a process to learn lessons.

SWG ch 2 how to work well on a team

How to dig out concepts

1. Listen to Language
2. Scrutinize Awkwardness
3. Contemplate Contradictions
4. read the book about business fundamentals
5. Try, Try Again

DDD ch 9 Making Implicit Concepts Explicit

How to design an architecture

General

1. determine the scope of the system
2. several iterations of attribute driven design

Detailed Steps:

1. Review and clarify input such as functionality, QA, constraint
2. Establish Iteration Goal by Selecting Drivers e.g. function, QA
3. Choose One or More Elements of the System to Refine for that selected drivers
   1. either decompose or merge components
4. Choose One or More Design Concepts That Satisfy the Selected Drivers
   1. Identification of Design Concepts
      1. reuse existing design concepts based best practices, your own knowledge, other expert
   2. Selection of Design Concepts
      1. list pros cons
      2. realize constraint
      3. realize previous iteration’s decision
   3. create a throwaway prototype:
      1. The goal is to clear some uncertainty with a small cost such as uncertainty of new tech, lack of trusted info
5. Instantiate Architectural Elements, Allocate Responsibilities, and Define Interfaces
6. Sketch Views and Record Design Decisions
7. Perform Analysis of Current Design and Review Iteration Goal and Achievement of Design Purpose
   1. let other people review your design
   2. use categorized todo list and priorities

SAP ch 20 Design an architecture

Six Essentials for Strategic Design Decision Making

1. Decisions must reach the entire team with good communication
2. The decision process must absorb feedback from application development team to architects
   1. architecture team can circulate its own members through application team to let architect get hands on exp of using the framework they developed
3. The plan must not be too restrictive and allow for evolution with feedback
4. Architecture teams must not siphon of all the best and brightest
   1. It is essential to have strong designers on all application teams.
   2. It is essential to have domain knowledge on any team attempting strategic design.
   3. It may simply be necessary to hire more advanced designers.
   4. It may help to keep architecture teams part-time.
5. Strategic design requires minimalism and humility
   1. Even the slightest ill fit has a terrible potential for getting in the way.
6. Objects are specialists; developers are generalists
   1. The essence of good object design is to give each object a clear and narrow responsibility and to reduce interdependence to an absolute minimum. So object should be specialist.
   2. developers should understand the whole picture. so they should be generalist

DDD Ch 17 Bring the strategy together

Avoid master plan

Master plan with too many guidelines is impractical to implement.

A better way is a set of principles for all community members to apply to every act of piecemeal growth, so that “organic order” emerges, well adapted to circumstances.

DDD Ch 17 Bring the strategy together

Tradeoff Analysis

How to find trade-off area?

• Find and analyze coupling points: Common coupling points are sensitive to changes to communication, consistency, and coordination
• iterative design is very important ; Building sample topologies for workflows allows an architect or team to build a matrix view of trade-offs, allowing quicker and more thorough analysis than ad hoc approaches.

SAH Ch 15 Build Your Own Trade-Of Analysis

Trade-Of Analysis Techniques

• Qualitative Versus Quantative Analysis
  • qualitative analysis is highly needed because few opportunities for true quantitative analysis exist in architecture.
• MECE Lists
  • It is important for architects to be sure they are comparing the same things rather than wildly different ones. e.g. invalid to compare simple message bus with enterprise service bus
  • MECE: mutually exclusive and collectively exhaustive
  • to make sure compare all in a category space
  • Mutually exclusive None of the capabilities can overlap between the compared items.
  • Collectively exhaustive This suggests that you’ve covered all the possibilities in the decision space,
• Analyze trade offs in most important context with sample scenarios rather than in all possible cases
• Prefer Bottom Line over Overwhelming Evidence
  • Architect should summarize trade-offs to several simple points and give them to non tech stakeholders to make decision
• Avoiding Snake Oil and Evangelism
  • An architect should also be wary of any tool or technique that promises any shocking new capabilities. Need to consider real scenarios and compare with alternatives.

SAH Ch 15 Build Your Own Trade-Of Analysis

The Architecture Tradeoff Analysis Method

The ATAM is designed so that evaluators do not need prior familiarity with the architecture or its business goals, and the system need not be constructed yet

Participants in the ATAM

1. evaluation team
2. project decision maker
3. architecture stakeholder

Outputs of the ATAM

1. concise architecture decision
2. articulation of business goal
3. Prioritized quality attribute requirements expressed as quality attribute scenarios.
4. risk and non risks
5. risk themes
6. Mapping of architectural decisions to quality requirements.
7. A set of identified sensitivity points and tradeoff points.

Step 1: Present the ATAM

Step 2: Present the Business Goals

Step 3: Present the Architecture

Step 4: Identify the Architectural Approaches

Step 5: Generate a Quality Attribute Utility Tree

Step 6: Analyze the Architectural Approaches

Step 7: Brainstorm and Prioritize Scenarios

Step 8: Analyze the Architectural Approaches

Step 9: Present the Results

SAP Ch 21 Evaluating an Architecture

When to refactor

• The design does not express the team’s current understanding of the domain; • Important concepts are implicit in the design (and you see a way to make them explicit); or • You see an opportunity to make some important part of the design suppler.

DDD Ch 13 Refactoring Toward Deeper Insight

Refactoring process

the only way a useful structure can be found is from a very deep understanding of the domain and the problem, and the practical way to that understanding is an iterative development process.

To control the iteration cost vs gain:

1. Minimalism: keep the structure simple and lightweight.
2. Communication and Self-Discipline
   1. The entire team must follow the structure in new development and refactoring. To do this, the structure must be understood by the entire team. The terminology and relationships must enter the UBIQUITOUS LANGUAGE.
   2. This require communication.
3. Restructuring Yields Supple Design
   1. models changed frequently are usually easy to change
4. continuous distillation reduces the difficulty of changing the structure

DDD ch 16 Large-Scale Structure

How to merge

3 ways to merge 2 separate domain models:

1. choose one model and refactor the other CONTEXT to be compatible.
2. Choose different best parts from each model
3. have a completely new model

DDD ch 14 Maintaining Model Integrity

Steps to decompose monolithic data

1. Analyze Database and Create Data Domains
2. Assign Tables to Data Domains
   1. When tables belonging to different data domains are tightly coupled and related to one another, data domains must necessarily be combined, creating a broader bounded context where multiple services own a specific data domain.
3. Separate Database Connections to Data Domains
   1. each service can only access its own data directly
4. Move Schemas to Separate Database Servers; 2 options
   1. backup and restore
   2. replicate data during runtime;
      1. pros no downtime;
      2. cons more complicated
5. Switch Over to Independent Database Servers

SAH Ch 6 Pulling Apart Operational Data

When and when not to Measuring Engineering Productivity

There are many good reasons to not measure the impact of a tool or process on productivity.

1. You can’t afford to change the process/tools right now
2. Any results will soon be invalidated by other factors e.g. before a planned reorg
   1. different decision makers believe different types of evidence. e.g. some believe more of individual survey while others believe more of logs
   2. if a stakeholder is limited to believing only in methods that are not appropriate for the problem, there is no point in doing the work.
3. The results will be used only as vanity metrics to support something you were going to do anyway
4. The only metrics available are not precise enough to measure the problem and can be confounded by other factors

We should only measure a software process when a concrete decision will be made based on the outcome.

SWG ch7 Measuring Engineering Productivity

How to increase productivity

rather than relying on each team to chart its own course to increase productivity, a centralized team can focus on broad-based solutions to complex problems.

Aim to create recommendations that are built into the developer workflow and incentive structures.

SWG ch7 Measuring Engineering Productivity

Style guide and rules

Rule principles:

1. lightweight, only the most important and less people know things
2. optimize for code reader rather than writer
3. be consistent across whole company so that easy to apply formatting tool and scale
4. follow external standards
5. Avoid error-prone and surprising constructs
6. allow exception for performance or compatability with external lib or more beneficial

3 types of rules:

1. avoid danger
2. enforce best practices
3. ensure consistency

Rule can be changed based on usage pattern shift.

Guidance tends to focus on things that we’ve observed people frequently getting wrong or new things that are unfamiliar and therefore subject to confusion.

• Rules and guidance should aim to support resilience to time and scaling.
• Know the data so that rules can be adjusted.
• Not everything should be a rule.
• Consistency is key.
• Automate enforcement when possible.

SWG ch 8 Style Guides And Rules

Code Review

A reviewer shouldn’t propose alternatives because of personal opinion. Reviewers can propose alternatives, but only if they improve comprehension (by being less complex, for example) or functionality (by being more efficient, for example). In general, engineers are encouraged to approve changes that improve the codebase rather than wait for consensus on a more “perfect” solution.

Checking for code correctness generally ensures that a change works, but more importance is attached to ensuring that a code change is understandable and makes sense over time and as the codebase itself scales.

Automation is critical for scaling the process. The code review itself provides a historical record.

SWG ch 9 Code Review

Deprecation

For long-running software ecosystems, planning for and executing deprecation correctly reduces resource costs and improves velocity by removing the redundancy and complexity that builds up in a system over time.

On the other hand, poorly deprecated systems may cost more than leaving them alone.

Some teams don’t even know they depend on sth. So one way is to find them dynamically through tests of increasing frequency and duration during which the old system is turned off temporarily. These intentional changes provide a mechanism for discovering unintended dependencies by seeing what breaks, thus alerting teams to a need to prepare for the upcoming deadline.

Much of the initial work of deprecation is determining who is using the old system—and in which unanticipated ways. Depending on the kinds of use, this process may require revisiting the deprecation decision once new information is learned.

A complete deprecation process involves successfully managing social and technical challenges through policy and tooling.

SWG Ch 15 Deprecation

How to detect dependency?

1. static analysis
2. detect 2 files are changed together

SAP Ch 23 Managing Architecture Debt

Related Chapters

DDD ch 9 Making Implicit Concepts Explicit

DDD Ch 13 Refactoring Toward Deeper Insight

DDD ch 14 Maintaining Model Integrity

DDD ch 16 Large-Scale Structure

DDD Ch 17 Bring the strategy together

SAP ch 14 working with other quality attributes

SAP ch 20 Design an architecture

SAP Ch 21 Evaluating an Architecture

SAH Ch 6 Pulling Apart Operational Data

SAH Ch 15 Build Your Own Trade-Of Analysis

MSV Ch 12 Bringing It All Together

SWG ch 1 what is software engineering?

SWG ch 2 how to work well on a team

SWG ch7 Measuring Engineering Productivity

SWG ch 8 Style Guides And Rules

SWG ch 9 Code Review

SWG Ch 15 Deprecation