crowdsourcing software architecture: the distributed architect · architectural awareness within...

1

SATURN 2017

Crowdsourcing Software Architecture © 2017 embarc Software Consulting GmbH Crowdsourcing Software Architecture © 2017 embarc Software Consulting GmbH

Crowdsourcing Software Architecture: The Distributed Architect Stefan Toth

2

SATURN 2017

Crowdsourcing Software Architecture © 2017 embarc Software Consulting GmbH

The cross-functional idea

Analyst (RE)

SW Architect Designer

Developer Build Engineer

Operations

Problem Solution

3

SATURN 2017


My background on this

§  Classic Architect by training §  10+ years of experience in agile projects §  40+ projects to gather concepts that work

4

SATURN 2017

Crowdsourcing Software Architecture © 2017 embarc Software Consulting GmbH Title of the Presentation Goes Here © 2017 [Copyright Owner[s]]

1 Why think about crowd-sourcing?

5

SATURN 2017


Classic Software Architects…

Often not on the train…

6

SATURN 2017


Software architects defined …

The following is defined…

Character of an architect

Know How that an architect needs

Duties of an architect

7

SATURN 2017


Character and Know-How

8

SATURN 2017


Even if you find such a person…

there are s(ll the Duties…

9

SATURN 2017


In general…

You stand a better chance by finding a group of people who jointly live up to this role

You are quicker if more people can react to requirements or technical problems

You get a better system if the developers think architecture is their problem

: “Nobody take care of a problem like the owner does”

10

SATURN 2017


Agile Principles

§�Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Continuous attention to technical excellence and good design enhances agility.

The best architectures, requirements, and designs emerge from self-organizing teams.

11

SATURN 2017


So why crowd-sourcing?

§  Realistic concepts §  Broader know-how §  Better motivation of engineers §  Faster reaction/cycle times §  Bottom-up standards (proven / often more stable) §  Better evolution of architecture over time §  Reduced / omitted overburden of ‘the architect’

12

SATURN 2017


2 Challenges and Risks

13

SATURN 2017


Software Architecture in jeopardy?

§  Lacking Conceptual Integrity

§  Wasteful process with low efficiency

§  Getting a useful initial design

§  Distributing the ongoing architectural activities

2 Challenges 2 Risks

14

SATURN 2017


3 Initial Design

15

SATURN 2017


Twin peaks model

16

SATURN 2017


What do we need upfront?

As an idea, not as an irreversible decision!

17

SATURN 2017


Walking Skeleton

„A Walking Skeleton is a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel.“

-‐ Alistair Cockburn

18

SATURN 2017


Distribute? Don’t… Tiger Team

1.  Bring together some specialists with expertise and experience

2.  Let them formulate an architecture vision that is powerful and accepted

3.  Try to integrate them into (different) software development teams to §  Represent the vision §  Recognize it’s non-applicability §  …

19

SATURN 2017


4 Ongoing Architectural Activity

20

SATURN 2017


The OODA Cycle

Act… Implement the idea (operational part)

Decide… Select an alternative or candidate (hard part)

Orient… Design and evaluate options (creative part)

Observe… Recognize potentials, risks or problems

21

SATURN 2017


1 - Observe

Responsibility for architecture is officially with the team (more eyes) Architectural awareness within the iteration – Not only implementation, but also a conceptual step back Tests for quality attributes (from architecture vision) show problems or the decline of effectiveness Recurring evaluation workshops for feedback and communication purposes (sync)


22

SATURN 2017


Architectural Awareness within an iteration

23

SATURN 2017


The implementation cycle...

6

24

SATURN 2017


Direct Problem Solving

Focused analysis

Fast decisions

Good to find local optimum

No synthesis

Little strategic thought

Little abstraction

7

25

SATURN 2017


Non-trivial Problems §  High quality requirements §  Complex Trade-Offs §  restrictive constraints §  many options (all not good/perfect) §  many stakeholders §  many teams or system parts affected

Great insights don‘t come from permantent low-level activity

8

26

SATURN 2017


The architecture cycle...

6

27

SATURN 2017


Good teams do this often...

Define the problem

Think (Hamock time)

Talk to others (sharpen vision)

abstract (externalize ideas)

learn

experiment

Analyze / criticize (your own) solutions

9

28

SATURN 2017


1 - Observe


Responsibility for architecture is officially with the team (more eyes) Architectural awareness within the iteration – Not only implementation, but also a conceptual step back Tests for quality attributes (from architecture vision) show problems or the decline of effectiveness Recurring evaluation workshops for feedback and communication purposes (sync)

29

SATURN 2017


1. Look at the big picture

§  Were there any changes? §  In which part were architecture efforts? §  Any new risks?

30

SATURN 2017


2. Look at the tasks and requirements

§  Which done tasks have impact on others?

§  Worked on any quality aspects? §  Any requirement changes that

have cross-cutting impact?

31

SATURN 2017


3. Prioritize gathered architectural topics

32

SATURN 2017


Multifaceted presentations – focused but specific

33

SATURN 2017


Discussion

§  How was the topic handled? è Relevant tac3cs or candidate decisions

§  Where/are there any problems or inconvenient constraints? è Impeding architectural approaches / organiza3onal hurdles, technical debt

§  Do you understand the solu3ons and ideas presented? è Comprehensability and focus

§  Are all aspects of the problem tackled, is something overlooked? è addi3onal architectural approaches, open points, risks

§  Do you see nega3ve implica3ons of the concepts/ideas presented? è Trade-‐Offs, risiks

Ques3ons for the most informed (presenta3on)

Ques3ons for the other par3cipants (Explora3on)

34

SATURN 2017



2 - Orient

Problem-driven assignment of tasks to small group or individuals (no design by committee) Architectural requirements are broken down to quality scenarios (often are held in the backlog) Ad-hoc Design Workshops with colleagues to find options and get context Install mentors for architecture or important technical topics (role-options we discuss later)

35

SATURN 2017


Quality requirements (NFRs)

§  Are not easily op3mizable in retrospect (expensive)

§  Influence high level structure and granularity

§  Are oNen cross-‐func3onal in nature (and therefore relevant for many project members)

è Quality requirements are the most important requirements for architectural work

36

SATURN 2017


Quality scenarios

37

SATURN 2017


Some examples

§  The algorithm for calculating an articles popularity is easily adaptable and exchangeable.

§  A user interacts with the platform as the assigned server fails. The problem isn’t apparent to him, even when he tries to navigate back to previous user masks or continues a complex interaction.

§  It is easy to find personnel for system maintenance or extension.

38

SATURN 2017


Work with architecture requirements

39

SATURN 2017


Maturity model for Quality-based Software Architecture

Scenario-‐ driven 4

3

2

1 Acciden(al architecture, Quality aPributes are not known

Rough Quality statements guide the architectural design

Decisions are evaluated qualita(vely and regularly. (With aPendance of the most important stakeholders)

Scenarios are gathered during design of the system and guide the architectural and technical decision making.

Evaluated regularly

quality-‐oriented

unstructured

40

SATURN 2017


3 - Decide

Focus on communication of architectural drivers, ideas, principles and candidate technologies (Architecture vision, evaluations, blogs, communities, …) Build consensus around architectural decisions by possibly involving every developer (responsibility should be felt)


41

SATURN 2017


Consensus

"Consensus is a term which describes general agreement among members of a group or community. The cooperaAve spirit of consensus is different from the compeAAve spirit which is brought to a point in majority voAng."

(Wikipedia)

A defini3on of consensus

42

SATURN 2017


Consensus focuses on opposition

Veto

OK Consensus

Best option in his opinion

43

SATURN 2017


Systemic process for consensus

Goal: Support a crea3ve process that allows to discover and combine the advantages of different op3ons and eventually leads to a decision with the lowest possible opposi3on.

Idea: Measure opposi3on on a scale of 0-‐10

Result: Op3on with the lowest combined opposi3on is chosen

44

SATURN 2017


Tips

§ Use Dummy Solu(on: Everything stays the same

§ Define a Veto-‐Value: everything above 7 counts as Veto

§ Simplifica(on: “Thumb-‐Vo3ng”

Cool! OK… Veto!

45

SATURN 2017


Alternative: Fist of Five

Quan3fica3on of rejec3on and approval

Consensus Rejection

Never! This can’t

work…

Opposed Modifications necessary…

Reservations Let’s discuss Some issues

Yeah, OK I won’t fight

this…

Good Idea I’ll support

and promote

Love it! Full and active

support

46

SATURN 2017


4 - Act

… actual implementation is easily distributed … more manpower, no bottlenecks, no NIH-Syndrome, …


47

SATURN 2017


5 The problem of scale

48

SATURN 2017


Scaling OODA





EASIER EASIER

HARDER HARDER

49

SATURN 2017


Architecture Owner

50

SATURN 2017


Architecture Owner

§  Keeping an overview §  Supporting by raising questions or co-design §  Proposing principles to speed up design and make it more effective §  Organizing necessary community activities §  Supporting communication on architecture

51

SATURN 2017


§  Seperate Responsibilities for Architectural Concerns to different project members (AO per topic)

§  For example by layers: UI-, Service-, Backend-, Integration-architects §  Or by qualitative Aspects: Security-, Performance-, Scalability-,

Maintainability-Marshalls

Architecture marshalls

52

SATURN 2017


Factors for choosing a role-concept

Decision making stays with teams

53

SATURN 2017


Software Architecture in jeopardy?

§  Lacking Conceptual Integrity

§  Wasteful process with low efficiency

§  Getting a useful initial design

§  Distributing the ongoing architectural activities

2 Challenges 2 Risks

54

SATURN 2017


6 Conceptual Integrity

55

SATURN 2017


Modes for conceptual integrity

§  Classic approach

§  You do architectural work incl. prototypes or spikes until you are “sure enough”. Then you prescribe the concept or idea

§  Integrity is there from the start (the prescription).

§  Hard governance

Standards first

§  Evolutionary approach

§  You do architectural work to make development more effective. Gathering good practices, abstracting ideas.

§  Integrity is there when good ideas and concepts prevail.

§  Lower Viscosity for concepts with broader use or benefits

Eventual integrity

56

SATURN 2017


Low Viscosity

An alternative for rules and prescriptions that §  scales pretty well §  works in complex environments

“When faced with a change, engineers usually find more than one way to make the change. Some of the ways preserve the design, others do not (i.e. they are hacks.) When the design preserving methods are harder to employ than the hacks, then the viscosity of the design is high. It is easy to do the wrong thing, but hard to do the right thing. ” (Robert C. Mar3n)

57

SATURN 2017


The tradeoff between speed and standardization

58

SATURN 2017


7 The waste within crowd-sourcing architectures

59

SATURN 2017


Is Crowd-Sourcing wasteful?

§  In theory distributing a interdependent topic is more expensive

§  In practice some aspects shift that: §  Delivery speed as an important goal §  New technology and innovation as an important factor §  Complex systems idea where planning is less effective

Icons: 3 of 8 wastes by Lean Six Sigma https://goleansixsigma.com/

60

SATURN 2017


Cynefin

Chaos Interven3on

Novel Praci3ce

Complex Experiments

Emergent Prac3ce

Obvious „Best Prac3ce“

Checklists

Complicated „Good Prac3ce“

Experts

? Projects have all four of these problem domains!

Is your business domain understood or new/shiNing?

Is your system/architecture blueprint-‐based or innova3ve?

61

SATURN 2017


Thank You.!Questions are welcome!

[email protected]

@st_toth

Download SLIDES: hPp://www.embarc.de/blog/

crowdsourcing software architecture: the distributed architect · architectural awareness within...

Documents