Architecture War Stories – E-Post 2014-02-14

Transcript

1. Stefan Tilkov | @stilkov | innoQ Architecture War Stories Deutsche Post E-Post Development 02/24/2014 Monday 24 February 14
2. Ground Rules No offense – just lessons learned Most systems are in production Still, many {managers | users | admins} are happy Monday 24 February 14
3. Less can be more Monday 24 February 14
4. Context Customer care, accounting & billing Large-scale big-bang replacement effort > 150 developers > 20 architects/framework devs Java, Swing, CORBA, Oracle Custom persistence framework Monday 24 February 14
5. Server Client DB Monday 24 February 14
6. Server Identity Map 1 7 3 9 Tx1 Tx2 Transaction Map 1 9 1 2 - Monday 24 February 14
7. Client DB Server Monday 24 February 14
8. Server Server Object Warehouse Object Warehouse Monday 24 February 14
9. Global synchronization? 2 PC? Cache notifications? Events? Transaction locality? Client Affinity? Monday 24 February 14
10. Server Server Object Warehouse Object Warehouse Monday 24 February 14
11. Server Server Cache Cache DB Cache Monday 24 February 14
12. 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 Monday 24 February 14
13. Data Complications Monday 24 February 14
14. Context Insurance system Maintenance 1000 person months/year Smalltalk, COBOL, C, IMS, DB2 Homegrown COBOL OO system Monday 24 February 14
15. Client (Smalltalk) Broker Gateway Transaction Manager Server (COBOL) Monday 24 February 14
16. Online Transactions Online DB Access Layer Interface DB Batch External Module External Module External Module Tables Foreign Keys Indexes OR/M Events Deltas Blobs Monday 24 February 14
17. Migration Monday 24 February 14
18. Monday 24 February 14
19. Lessons learned Data should be free of code dependencies The longer you store it, the simpler it needs to be Beware of smelly blobs Monday 24 February 14
20. Evaluating Yourself to Death Monday 24 February 14
21. Context Strategic health care platform Architecture team 20+10 people Build foundation for 800+ person year effort Monday 24 February 14
22. 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 Monday 24 February 14
23. 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 Monday 24 February 14
24. Lessons learned Just do it Better ask for forgiveness than permission Monday 24 February 14
25. Your system WILL be dynamic Monday 24 February 14
26. Context Large-scale insurance system Model-driven development > 100 developers 2 Releases/year Monday 24 February 14
27. 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 Monday 24 February 14
28. 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 … Monday 24 February 14
29. Lessons learned Centralized responsibility hurts Faced with too much rigidity, a way around the rules will be found Just because you’re used too it doesn’t mean it’s acceptable Monday 24 February 14
30. Formalism and Common Sense as Orthogonal Concepts Monday 24 February 14
31. Context Telecommunications OSS platform Support new devices without code changes > 100 developers > 3 countries Monday 24 February 14
32. 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 Monday 24 February 14
33. 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» Monday 24 February 14
34. 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” Monday 24 February 14
35. The Perils of Being Smart Monday 24 February 14
36. Context Complex enterprise-wide SOA effort Custom-built “lightweight” middleware Monday 24 February 14
37. Consumer/Provider Middleware Lib Transport Abstraction Messaging API Business Logic Configuration Service Registry Service Monday 24 February 14
38. Consumer/Provider Middleware Lib Transport Abstraction Messaging API Business Logic XML Obj Consumer/Provider Middleware Lib Transport Abstraction Messaging API Business Logic Message XML Monday 24 February 14
39. “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 Monday 24 February 14
40. Monday 24 February 14
41. “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 Monday 24 February 14
42. Lessons learned Fight the madness Tunneling is the root of all evil Don’t be too smart Monday 24 February 14
43. Non-extensible Extensibility Monday 24 February 14
44. Context E-Commerce (retail) provider Global customer base Catalog/CMS/Shop/Fulfillment Multi-tenant Highly customizable Monday 24 February 14
45. Large customers (“strategic”) Small customers (“long tail”) Specific General High Low (Acceptable) Cost Customization (Need) The Solution Monday 24 February 14
46. Lessons learned Don’t be all things to all people Sometimes specific code is preferable Saying “no” might help Monday 24 February 14
47. Over-Generalization Drive Monday 24 February 14
48. Phases in a Developer’s Life Monday 24 February 14
49. 1. The Enthusiastic Developer “This stuff is cool - let’s build programs! For real people!” Monday 24 February 14
50. Boring, boring, boring. Create Customer Find Customer List Customers Edit Customer Delete Customer Create Order Find Order List Orders Edit Order Delete Order Create Product Find Product List Products Edit Product Delete Product Monday 24 February 14
51. 2. The Disillusioned Developer “Oh. Real people have boring problems.” Monday 24 February 14
52. Create Customer Find Customer List Customers Edit Customer Delete Customer Create Order Find Order List Orders Edit Order Delete Order Create Product Find Product List Products Edit Product Delete Product Monday 24 February 14
53. Create Thing Find Thing List Thing Edit Thing Delete Thing Monday 24 February 14
54. 3. The Enthusiastic Architect “Generic solutions! Cool!” Create Thing Find Thing List Thing Edit Thing Delete Thing Monday 24 February 14
55. ‘ ‘Some architects, when faced with a problem, think “Hey, I’ll use a generic solution.” Now they have problem and a GenericProblemFactoryFacade. (with apologies to jwz) Monday 24 February 14
56. Application (100%) Configuration 10% The Generic Thing Machine 90% Monday 24 February 14
57. 80% 20% Functionality: 320% 80% Time/Effort: Monday 24 February 14
58. Configuration The Generic Thing Machine Customer Developer Monday 24 February 14
59. 4. The Disillusioned Architect KISS YAGNI Lean Minimable viable product Story focus Monday 24 February 14
60. 5. The “Wise” Architect Answer: It depends. Question: * Monday 24 February 14
61. Summary Monday 24 February 14
62. Never-ending supply of {war stories | catastrophes | disasters} seems guaranteed Monday 24 February 14
63. Advice: Monday 24 February 14
64. 1. Give Feedback Monday 24 February 14
65. 2. Reflect Monday 24 February 14
66. 3. Iterate Monday 24 February 14
67. Q&A Stefan Tilkov, @stilkov stefan.tilkov@innoq.com Phone: +49 170 471 2625 innoQ Deutschland GmbH Krischerstr. 100 40789 Monheim am Rhein Germany Phone: +49 2173 3366-0 innoQ Schweiz GmbH info@innoq.com 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 Telefon +49 (0) 89 741185-270 Monday 24 February 14