Software Architecture, Processes, Organization—and Humans

Slide 1

Slide 1 text

Architecture, Organization, Processes – and Humans Stefan Tilkov, @stilkov stefan.tilkov@innoq.com YOW! 18 August 2020

Slide 2

Slide 2 text

Architecture & Organization

Slide 3

Slide 3 text

@stilkov Conway’s Law: Organization → Architecture “Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations.” – M.E. Conway

Slide 4

Slide 4 text

@stilkov Conway’s Law Illustrated

Slide 5

Slide 5 text

@stilkov Conway Reversal 1: Organization ← Architecture Any particular architecture approach constraints organizational options – i.e. makes some organizational models simple and others hard to implement.

Slide 6

Slide 6 text

@stilkov Choosing a particular architecture can be a means of optimizing for a desired organizational structure. Conway Reversal 2: Organization ← Architecture

Slide 7

Slide 7 text

@stilkov The “Tilkov wants a law, too” slide The quality of a system’s architecture is inversely proportional to the number of bottlenecks limiting its evolution, development, and operations

Slide 8

Slide 8 text

@stilkov The “Tilkov wants a law, too” slide* In a digital company, architecture, organization & processes can only evolve together *Attempt #2 in case the 1st one doesn’t catch on

Slide 9

Slide 9 text

@stilkov Let’s talk about patterns

Slide 10

Slide 10 text

@stilkov Pattern: Description Approach Consequences … … …

Slide 11

Slide 11 text

@stilkov Pattern: Microservices Description Approach Consequences Design modules as separate deployment and operation units, with large degrees of freedom for their implementation Former technical detail (deployment architecture) as first class architectural design principle Network communication as hard-to-cross boundary, enforcing encapsulation Isolation Autonomy Scalability Resilience Speed Experimentation Rapid Feedback Flexibility Replaceability

Slide 12

Slide 12 text

@stilkov Antipattern: Description Reasons Consequences … … …

Slide 13

Slide 13 text

@stilkov Antipattern: Microservices Description Reasons Consequences System made up of arbitrarily sized, tightly coupled modules communicating over network interfaces Hype-driven architecture Conference-driven development Missing focus on business domain Infrastructure over- engineering “Ripple” effect of changes Complex environment Massive network overhead Performance issues Wild mix of technologies, products & frameworks Hard to understand & maintain (a.k.a. “Distributed Monolith“)

Slide 14

Slide 14 text

Antipatterns

Slide 15

Slide 15 text

Antipattern: Conference-driven Architecture

Slide 16

Slide 16 text

@stilkov Antipattern: Conference-driven Architecture Description Reasons Consequences Hypes are accepted as gospel, and applied to problems regardless of whether they match requirements or not • Hot and shiny toys! • Community respect • Search for guidance • Occasional successes • Motivated developers • Half-time of solutions matches conference cycle time • Acceptance of architecture directly related to # of conference visits

Slide 17

Slide 17 text

@stilkov Antipattern: Decoupling Illusion Stakeholder Stakeholder Stakeholder Platform Person

Slide 18

Slide 18 text

@stilkov Antipattern: Decoupling Illusion Description Reasons Consequences Technical separation into subsystems/services does not match business domain separation • Technical drivers prioritized over business drivers • Lack of awareness for stakeholder needs • Reuse driver furthers single platform approach • Microservices hype • Technical complexity • Conflicting stakeholder needs require coordination • Organizational bottlenecks due to centralized components with highly concurrent requests

Slide 19

Slide 19 text

@stilkov Antipattern: Half-hearted Modularization Dev Ops

Slide 20

Slide 20 text

@stilkov Antipattern: Half-hearted Modularization Description Reasons Consequences Modularization is performed in one aspect of the lifecycle only • Resistance of one group to participate • Lack of understanding of lifecycle aspects by initiators • Added complexity, limited value • Delivery inhibited by existing processes • New approach might be “burned” for future attempts

Slide 21

Slide 21 text

@stilkov Antipattern: Solution Centrism Stakeholder Stakeholder Stakeholder Solution

Slide 22

Slide 22 text

@stilkov Antipattern: Solution Centrism Description Reasons Consequences Implementation solution as unifying factor • Vendor influence • Experience drives selection of technology • Sunk cost fallacy • Inefficiency due to hammer/nail problem • Bottleneck by definition • Technology, not domain as unifying factor • Developer frustration • Skills shortage in market • Hard to motivate people to train in proprietary tech

Slide 23

Slide 23 text

@stilkov Antipattern: Domain-last Approach Biz Unit 1 Ops Stakeholder Stakeholder Stakeholder Biz Unit 2 Biz Unit 3 DB Tech 1 Tech 2 Dev

Slide 24

Slide 24 text

@stilkov Antipattern: Domain-last Approach Description Reasons Consequences Major driver for organizational structure is roles and technical capabilities, not business domain • Matches classical company structure • Division of labor in divisions, department, teams • Projects as exceptions to change something that works • Inter-departmental politics over business needs • Conflicting project and disciplinary hierarchies and stakeholders • Blameshifting

Slide 25

Slide 25 text

Antipattern: Uncreative Chaos

Slide 26

Slide 26 text

@stilkov Antipattern: Uncreative Chaos Description Reasons Consequences Lack of architectural structure & repeatable process for architectural decisions • No (effective) centralized governance • Non-technical senior management • Focus on unnecessary standardization • Strong business leaders, weak tech leaders • Redundancy in all aspects • Frequent technology discussions between teams • High integration costs and technical debt • Slow delivery capability due to complexity • Complex and expensive

Slide 27

Slide 27 text

@stilkov Antipattern: Authoritarian Regime

Slide 28

Slide 28 text

@stilkov Antipattern: Authoritarian Regime Description Reasons Consequences Centralized decision making, strong standardization, homogeneous environment • Unpopular decisions (cost savings, product standardization, …) • (Perceived or real) lack of skills in “lower levels” • Possibly due to company culture • Frustration and developer exodus • Lack of innovation & speed because of bottlenecks • Technology paralysis

Slide 29

Slide 29 text

Patterns

Slide 30

Slide 30 text

Pattern: Developer Self-Service

Slide 31

Slide 31 text

@stilkov Pattern: Developer Self-service Description Approach Consequences Project developers can access allocate resources without asking for permission • API-based access to resources (computation, storage, network, services) • Fine-grained security controls • Rate-limiting • Public, private or hybrid cloud-based • Shorter delivery/ deployment cycles • Support for experimentation • Easier test setup

Slide 32

Slide 32 text

Pattern: Regulated Market

Slide 33

Slide 33 text

@stilkov Awesome Shop CMS Archive General Ledger Print Shop HR

Slide 34

Slide 34 text

@stilkov Awesome Shop CMS Archive General Ledger Print Shop HR Context

Slide 35

Slide 35 text

@stilkov Awesome Shop CMS Archive General Ledger Print Shop HR Invoicing Accounting Auth Catalog Checkout & Order Search

Slide 36

Slide 36 text

@stilkov Awesome Shop CMS Archive General Ledger Print Shop HR Invoicing Accounting Auth Catalog Checkout & Order Search Domain Architecture

Slide 37

Slide 37 text

@stilkov Invoicing Accounting Auth Catalog Checkout & Order Search

Slide 38

Slide 38 text

@stilkov

Slide 39

Slide 39 text

@stilkov Macro Architecture

Slide 40

Slide 40 text

@stilkov Ruby on Rails MySQL Java Spring Boot OSS Product COTS Java Spring Boot NodeJS ElasticSearch

Slide 41

Slide 41 text

@stilkov Ruby on Rails MySQL Java Spring Boot OSS Product COTS Java Spring Boot NodeJS ElasticSearch Micro Architecture

Slide 42

Slide 42 text

@stilkov Invoicing Accounting Auth Catalog Checkout & Order Search

Slide 43

Slide 43 text

@stilkov number of developers strength of decoupling methods modules components μservices systems

Slide 44

Slide 44 text

@stilkov Macro Architecture

Slide 45

Slide 45 text

@stilkov Pattern: Regulated Market Description Approach Consequences Let “the free market of ideas” decide what works best, but provide a framework of rules for interoperability • Separate micro & macro architecture • Strictly enforced rules for macro architecture • Loose, minimal governance for micro architecture • Motivated developers • Experimentation with different micro architecture approaches possible • Best-of-breed approach • Local optima

Slide 46

Slide 46 text

@stilkov Pattern: Autonomous Cells Stakeholder Stakeholder Stakeholder Biz Dev Ops Biz Dev Ops Biz Dev Ops

Slide 47

Slide 47 text

@stilkov Pattern: Autonomous Cells Stakeholder Stakeholder Stakeholder Biz Dev Ops Biz Dev Ops Biz Dev Ops

Slide 48

Slide 48 text

@stilkov Pattern: Autonomous Cells Description Approach Consequences Decentralized, domain- focused cells with maximum authority over all aspects of a set of capabilities • Decisions are made locally on all aspects of a solution • Success is measured via customer-oriented KPIs • Cross-functional team with biz, dev, ops skills • Customer/end user focus • Decentralized delivery capability • Speed as #1 priority • “Full-stack” requirement for developers and other roles • Redundancy instead of centralization

Slide 49

Slide 49 text

@stilkov Invoicing Accounting Auth Catalog Checkout & Order Search

Slide 50

Slide 50 text

@stilkov Invoicing Accounting Auth Catalog Checkout & Order Search

Slide 51

Slide 51 text

@stilkov Invoicing Accounting Auth Catalog Checkout & Order Search

Slide 52

Slide 52 text

@stilkov Invoicing Accounting Auth Catalog Checkout & Order Search Team Architecture

Slide 53

Slide 53 text

Pattern: Evolutionary Architecture

Slide 54

Slide 54 text

@stilkov Pattern: Evolutionary Architecture Description Approach Consequences Architecture is constructed so it can evolve as much as possible over the course of (ideally indefinite) time • Separation of large domain into “islands of change” • Design for replacement, not for re-use • Minimization of shared dependencies • Cell metaphor: Renewal over time • Experimentation with different micro architecture approaches possible

Slide 55

Slide 55 text

@stilkov Pattern: Marketing-based Governance

Slide 56

Slide 56 text

@stilkov Pattern: Marketing-based Governance Description Approach Consequences Architectural approaches are evangelized instead of mandated • Disseminate information via blogs, brown-bag sessions, public talks • Architects as communicators • Integration with public/community work • More heterogeneity • Similarity to industry • Decisions made based on a solution’s merit • Bottom-up modernization

Slide 57

Slide 57 text

Recommendations

Slide 58

Slide 58 text

1. Acquire domain knowledge and focus on business value

Slide 59

Slide 59 text

2. Partner with business stakeholders

Slide 60

Slide 60 text

3. Create evolvable structures

Slide 61

Slide 61 text

4. Be aware of the interplay between architecture, processes, organization, and humans

Slide 62

Slide 62 text

5. Create value – or get out of the way of those who do as quickly as possible

Slide 63

Slide 63 text

Krischerstr. 100 40789 Monheim am Rhein Germany +49 2173 3366-0 Ohlauer Str. 43 10999 Berlin Germany +49 2173 3366-0 Ludwigstr. 180E 63067 Offenbach Germany +49 2173 3366-0 Kreuzstr. 16 80331 München Germany +49 2173 3366-0 Hermannstrasse 13 20095 Hamburg Germany +49 2173 3366-0 Gewerbestr. 11 CH-6330 Cham Switzerland +41 41 743 0116 innoQ Deutschland GmbH innoQ Schweiz GmbH www.innoq.com Thank you! Any questions? Stefan Tilkov @stilkov stefan.tilkov@innoq.com +49 170 471 2625

Slide 64

Slide 64 text

@stilkov www.innoq.com OFFICES Monheim Berlin Offenbach Munich Hamburg Zurich FACTS ~150 employees Privately owned Vendor-independent SERVICES Strategy & technology consulting Digital business models Software architecture & development Digital platforms & infrastructures Knowledge transfer, coaching & trainings CLIENTS Finance Telecommunications Logistics E-commerce Fortune 500 SMBs Startups

Slide 65

Slide 65 text

@stilkov Image Credit https://pixabay.com/en/marketing-customer-center-2483856/ https://pixabay.com/en/chaos-room-untidy-dirty-messy-627218/ https://commons.wikimedia.org/wiki/File:Wroclaw_Daily_Market.jpg https://pixabay.com/en/smartphone-face-man-old-baby-1790833/ http://maxpixel.freegreatpicture.com/Board-Arrow-Note-Garden-Shield-Wc-Self-Service-863157 https://commons.wikimedia.org/wiki/File:Chicago_Campus_Conference.JPG