Software Architecture Anti-patterns

Slide 1

Slide 1 text

SOFTWARE ARCHITECTURE ANTI-PATTERNS Image source: https://www.flickr.com/photos/britfatcat/9066456506/

Slide 2

Slide 2 text

JAKUB GADKOWSKI [email protected] @JAKUBGA DIMITRIOS PSARROU [email protected] ABOUT US

Slide 3

Slide 3 text

A SHORT INTRODUCTION

Slide 4

Slide 4 text

A SHORT INTRODUCTION PATTERN Describes a problem encountered on a regular basis, followed by abstracted solution. ANTI PATTERN Describes a broken solution and then proposes refactored, fixed solution.

Slide 5

Slide 5 text

WHY ANTI-PATTERNS? ‣ Way to communicate. ‣ Avoid broken solutions.

Slide 6

Slide 6 text

TYPES OF ANTI-PATTERNS ‣ Development anti-patterns ‣ Architectural anti-patterns ‣ Managerial anti-patterns

Slide 7

Slide 7 text

BIG BALL OF MUD

Slide 8

Slide 8 text

Image source: https://smilekiddo.wordpress.com/2011/05/13/chore-supports/

Slide 9

Slide 9 text

BIG BALL OF MUD ANTI-PATTERN TYPICAL SYMPTOMS AND CAUSES ‣ Bad management decisions. ‣ Change of requirements. ‣ Inexperienced developers.

Slide 10

Slide 10 text

‣ Small step refactoring. ‣ Just tear it down. BIG BALL OF MUD ANTI-PATTERN SOLUTION Image source: http://gizmodo.com/10-mesmerizing-gifs-of-giant-buildings-being-demolished-611490671

Slide 11

Slide 11 text

STOVEPIPE ARCHITECTURE

Slide 12

Slide 12 text

Image source: https://www.flickr.com/photos/egarc2/2432270195/

Slide 13

Slide 13 text

STOVEPIPE ANTI-PATTERN TYPICAL SYMPTOMS AND CAUSES ‣ Lack of an system strategy. ‣ Lack of communication. ‣ Lack of abstraction.

Slide 14

Slide 14 text

STOVEPIPE ANTI-PATTERN SOLUTION ‣ Coordination between systems. ‣ Architecture management. ‣ Composition and delegation.

Slide 15

Slide 15 text

THE NEW TOYS

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

THE NEW TOYS ANTI-PATTERN SYMPTOMS AND CAUSES ‣ Introducing new technology because it’s new. ‣ Picking technology that looks good on CV. ‣ Putting technology before user’s needs.

Slide 18

Slide 18 text

THE NEW TOYS ANTI-PATTERN SOLUTION ‣ Does it solve end user problems? ‣ Does it make the system more complex? ‣ Is it proven technology for this solution? ‣ Is it compatible with the team skill set?

Slide 19

Slide 19 text

GOLD PLATING

Slide 20

Slide 20 text

src: https://pbs.twimg.com/media/CPiJMG2WwAAdwAe.png

Slide 21

Slide 21 text

GOLD PLATING ➤ The additional eﬀort does not add value ➤ Also found in management • PMBoK • Prince 2 ➤ Introduces new risks • testing • documentation • costs • timelines src: http://www.stellman-greene.com/blog/wp-content/uploads/2007/06/silverware.png

Slide 22

Slide 22 text

GOLD PLATING - PREMATURE OPTIMIZATION src: http://www.cihataltuntas.com/wp-content/PrematureOptimization_D748/premature6.jpg

Slide 23

Slide 23 text

GOLD PLATING - PREMATURE/ACCIDENTAL COMPLEXITY src: http://s2.quickmeme.com/img/aa/aab05dd5de57f6aa638348aa48cd80d5b522f8c70a35d58044c03b56dfdc5391.jpg

Slide 24

Slide 24 text

GOLD PLATING - SOLUTION src: https://imgflip.com/memegenerator/61458110/Not-Today

Slide 25

Slide 25 text

THE GRAND OLD DUKE OF YORK https://s-media-cache-ak0.pinimg.com/236x/62/41/fc/6241fc95fd6b999fe0aa2d3606d682db.jpg

Slide 26

Slide 26 text

THE GRAND OLD DUKE OF YORK Abstractionists versus Implementationists src: http://www.cliffedgemarketing.com/assets/img/blog/Thinker%20vs.%20doer%20final.jpg

Slide 27

Slide 27 text

THE GRAND OLD DUKE OF YORK - CAUSES AND CONSEQUENCES Software usability and system maintenance are impacted Excessive complexity Abstractions are compromised Abstractionists are outvoted Software design disasters that make the system difficult to develop could have been prevented by using effective abstraction principles

Slide 28

Slide 28 text

THE GRAND OLD DUKE OF YORK Specialisations: ➤ Architects ➤ Component Developers ➤ Application Developers

Slide 29

Slide 29 text

THE ARMCHAIR ARCHITECT

Slide 30

Slide 30 text

THE ARMCHAIR ARCHITECT ➤ Can solve all the software world's problems from his armchair ➤ Implementation is out of scope ➤ Avoids testing his great ideas with reality ➤ Dismisses everything that anyone else has done Popular quotes ➤ User interfaces are all worthless ➤ All web browsers, including the Web itself, are worthless ➤ Everything will change within 5-10 years, due to me personally ➤ Programmers are all unethical idiots working for evil corporations

Slide 31

Slide 31 text

[Insert photo of Jay and Dimi here]

Slide 32

Slide 32 text

THE ARMCHAIR ARCHITECT Causes ➤ Whiteboard sketches are handed oﬀ as ﬁnal architecture ➤ Architects don’t code ➤ Architects play golf ➤ Blame the implementers src: https://allthingslearning.files.wordpress.com/2012/06/ivory-tower-tg-version.png

Slide 33

Slide 33 text

THE ARMCHAIR ARCHITECT - SOLUTION ➤ Be involved with the project ➤ Eat your own dog food ➤ Lead by example ➤ Pair programming ➤ Code reviewing ➤ Shared understanding src: http://www.informit.com/content/images/chap3_9780321247131/elementLinks/03fig01.jpg

Slide 34

Slide 34 text

COVER YOUR ASSETS

Slide 35

Slide 35 text

Covering your assets - providing excessive amount of documents and options without actually making any decision. Image source: Fallout 4, copyright Bethesda 2016

Slide 36

Slide 36 text

COVER YOUR ASSETS ANTI-PATTERN TYPICAL SYMPTOMS AND CAUSES ‣ Document Driven Development syndrome. ‣ Safeguarding from (all) potential failures.

Slide 37

Slide 37 text

COVER YOUR ASSETS ANTI-PATTERN SOLUTION ‣ Propose options, explain and recommend the best solution. ‣ Introduce Architecture Blueprints.

Slide 38

Slide 38 text

COVER YOUR ASSETS ANTI-PATTERN SOLUTION

Slide 39

Slide 39 text

DESIGN BY COMMITTEE

Slide 40

Slide 40 text

No content

Slide 41

Slide 41 text

DESIGN BY COMMITTEE ANTI-PATTERN TYPICAL SYMPTOMS AND CAUSES ‣ Conflicting interpretations of the design. ‣ Politics affects the design. ‣ Unproductive, slow process of meetings and improvements.

Slide 42

Slide 42 text

DESIGN BY COMMITTEE ANTI-PATTERN SOLUTION ‣ Small teams of experts. ‣ Establish roles and responsibilities. ‣ Improve committee meetings. ‣ Improve decision process: ATAM, LAAAM.

Slide 43

Slide 43 text

REINVENT THE WHEEL

Slide 44

Slide 44 text

Image source: “MythBusters”, episode “Square Wheels”, 2012 Discovery

Slide 45

Slide 45 text

REINVENT THE WHEEL ANTI-PATTERN TYPICAL SYMPTOMS AND CAUSES ‣ Closed system architecture. ‣ Lack of knowledge. ‣ Jealousy. ‣ Detrimental enterprise culture.

Slide 46

Slide 46 text

REINVENT THE WHEEL ANTI-PATTERN SOLUTION ‣ Improve (internal) communication. ‣ Research on existing solutions. ‣ Influence company culture.

Slide 47

Slide 47 text

VENDOR LOCK-IN

Slide 48

Slide 48 text

src: https://imgflip.com/memegenerator/Overly-Attached-Girlfriend

Slide 49

Slide 49 text

VENDOR LOCK-IN Aka Bondage and Submission ➤ Complete dependency on vendor implementation ➤ Lack of control ➤ Quantiﬁable ➤ Exceptions • When the majority of functionality needed is made by a speciﬁc vendor

Slide 50

Slide 50 text

VENDOR LOCK-IN Vendor lock in is everywhere ➤ Business lock in ➤ Technology lock in ➤ Cloud lock in src: http://www.mspmentor.net/wp-content/uploads/2012/11/cloud-lock-in-300x225.jpeg

Slide 51

Slide 51 text

VENDOR LOCK-IN - SOLUTION: ISOLATION LAYER src: http://antipatterns.com/vendorlockin.htm

Slide 52

Slide 52 text

VENDOR LOCK-IN - TAKEAWAYS ➤ Vendor lock in is quantiﬁable ➤ Business lock in is the hardest to escape ➤ There is no real elimination of lock in. Only mitigation of the costs ➤ Pay the switching costs when the lock in becomes an impediment to your objectives ➤ Always prepare your exit strategy

Slide 53

Slide 53 text

SPIDERWEB ARCHITECTURE Spider webs are beautiful..

Slide 54

Slide 54 text

YOUR WEB SERVICES ARE NOT src: http://techblog.netflix.com/2013_01_01_archive.html

Slide 55

Slide 55 text

SPIDERWEB ARCHITECTURE ➤ Aka a million services all in a row ➤ Creating large number of services, because you can. ➤ Problems • Confusion • Maintenance cost ‣ Solution • Let the requirements drive what needs to be exposed

Slide 56

Slide 56 text

POINT TO POINT WEB SERVICES

Slide 57

Slide 57 text

src: https://zato.io/docs/intro/esb-soa.html

Slide 58

Slide 58 text

src: https://zato.io/docs/intro/esb-soa.html

Slide 59

Slide 59 text

POINT TO POINT SERVICES - SOLUTION ➤ Gateways ➤ Brokering

Slide 60

Slide 60 text

ONE MODEL TO RULE THEM ALL

Slide 61

Slide 61 text

src: https://imgflip.com/memegenerator/28416787/the-one-ring

Slide 62

Slide 62 text

ONE MODEL TO RULE THEM ALL ➤ Single domain fallacy ➤ There are no bounded contexts ➤ Complexity and integration issues

Slide 63

Slide 63 text

ONE MODEL TO RULE THEM ALL - SOLUTION ➤ DDD ➤ Bounded contexts ➤ CQRS src: http://martinfowler.com/bliki/CQRS.html

Slide 64

Slide 64 text

THANK YOU! PLEASE RATE US: HTTPS://JOIND.IN/TALK/5884E

Slide 65

Slide 65 text

QUESTIONS? We will answer any question as long as you can solve this within 30secs

Slide 66

Slide 66 text

REFERENCES ➤ Antipatterns, Refactoring Software, Architectures, Projects in Crisis, William J. Brown Raphael C. Malveau Hays W. McCormick III Thomas J. Mowbray John Wiley & Sons, Inc. 1998 ➤ Adrian Cockcroft - OpenStack Silicon Valley 2015 - Web Services and Microservices: The Eﬀect on Vendor Lock In ➤ Domain Driven Design - Eric Evans, 2004 ➤ Implementing DDD - Vaugh Vernon 2013 ➤ Building Microservices - Sam Newman 2015 ➤ Daniel Bryant - The seven deadly sins of micro services - Devox UK, 2016 ➤ https://sourcemaking.com/antipatterns ➤ http://c2.com/cgi/wiki ➤ http://nealford.com/ ➤ http://martinfowler.com/ ➤ https://www.nginx.com/blog/building-microservices-inter-process-communication/ ➤ https://www.infoq.com/articles/SOA-anti-patterns ➤ http://richard.dallaway.com/architecture/