Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Architecture War Stories @ BuildStuff Vilnius

Stefan Tilkov
November 20, 2014

Architecture War Stories @ BuildStuff Vilnius

In this session, I will talk about entertaining examples of architectural disasters in software projects. We will see how excellent ideas can turn into nightmares, how one can slowly but thoroughly introduce incredible complexity, and how a merge between organizational and technical failures can grind productivity to a halt. Names and irrelevant details have been changed to protect the somewhat innocent, but everything is based on actual things I had to experience – and sometimes helped create – in the real world.

Stefan Tilkov

November 20, 2014
Tweet

More Decks by Stefan Tilkov

Other Decks in Technology

Transcript

  1. Ground Rules No offense – just lessons learned Most systems

    are in production Still, many {managers | users | admins} are happy
  2. Context Customer care, accounting & billing Large-scale big-bang replacement effort

    > 150 developers > 20 architects/framework devs Java, Swing, CORBA, Oracle Custom persistence framework
  3. Server Identity Map 1 7 3 9 Tx 1 Tx2

    Transaction Map 1 9 1 2 -
  4. Lessons learned Don’t cache the cache In distributed systems, application

    state is your enemy If it’s “sophisticated”, you probably shouldn’t be doing it Development ≠ production
  5. Online Transactions Online DB Access Layer Interface DB Batch External

    Module External Module External Module Tables Foreign Keys Indexes OR/M Events Deltas Blobs
  6. Lessons learned Data should be free of code dependencies The

    longer you store it, the simpler it needs to be Beware of smelly blobs
  7. Vendor Selection Collect and agree on requirements Week 0 Conduct

    market research Week 8 Send out RFP to selected vendors Week 10 Evaluate responses, create shortlist, start PoC Week 14 Evaluate PoC results, recommend vendor X Week 20 Accept your CEO picked vendor Y Week 26
  8. Vendor Selection Collect and agree on requirements Week 0 Conduct

    market research Week 8 Send out RFP to selected vendors Week 10 Evaluate responses, create shortlist, start PoC Week 14 Evaluate PoC results, recommend vendor X Week 20 Shutdown company Week 26
  9. Modeling Business Concept 0 3 6 4 5 2 1

    Technical Concept Implementation Module Test Integration Test Rollout Vision What if you miss your slot? Modeling
  10. Policy Holder Clause - id - value - dueDate -

    name - address - status - text - validity - taxClass * * regionCode Model Name New Name (Meaning) Description Release Introduced taxClass regionCode … 10.3 …
  11. Lessons learned Centralized responsibility hurts Faced with too much rigidity,

    a way around the rules will be found Just because you’re used to it doesn’t mean it’s acceptable
  12. Warning ((Meta) meta) models) are a perfect means to waste

    time, on a highly inspiring intellectual level, without any results for years Highly complex methodology, tool support, agreement processes Consultants with exclusive pricing strategies
  13. Upload «servlet» DB Model XML XML XML XML XML Transformation

    «slsb» .pl .sh Schema .sql Interface .idl Call «ant task» Quartz Transformer «servlet» Objects «entity» Generic CRUD UI Access «slsb»
  14. Lessons learned If it makes you want to scratch your

    eyes out, you might not want to do it Sometimes constraints need to be fought Beware all things “meta”
  15. Consumer/Provider Middleware Lib Transport Abstraction Messaging API Business Logic XML

    Obj Consumer/Provider Middleware Lib Transport Abstraction Messaging API Business Logic Message XML
  16. “The Product” Consumer/Provider Middleware Lib Transport Abstraction Messaging API Business

    Logic XML Obj OO Mapper Obj XML Transport Abstraction HTTP CORBA JMS Object API
  17. “The Product” Transport Abstraction OO Mapper Obj XML Object API

    Messaging API Interceptor Interceptor SOAP Message Header Body XML Message XML Obj null SOAP Message Header Body XML
  18. Lessons learned Don’t be all things to all people Sometimes

    specific code is preferable Saying “no” might help
  19. Q&A Stefan Tilkov, @stilkov [email protected] Phone: +49 170 471 2625

    innoQ Deutschland GmbH Krischerstr. 100 40789 Monheim am Rhein Germany Phone: +49 2173 3366-0 innoQ Schweiz GmbH [email protected] Gewerbestr. 11 CH-6330 Cham Switzerland Phone: +41 41 743 0116 www.innoq.com Ohlauer Straße 43 10999 Berlin Germany Phone: +49 2173 3366-0 Robert-Bosch-Straße 7 64293 Darmstadt Germany Phone: +49 2173 3366-0 Radlkoferstraße 2 D-81373 München Germany Telefon +49 (0) 89 741185-270