Your SlideShare is downloading. ×
0
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Why Enterprise Architecture Usually Sucks.
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Why Enterprise Architecture Usually Sucks.

10,811

Published on

Presented at ThoughtWorks Australia Team Hug 2010 …

Presented at ThoughtWorks Australia Team Hug 2010

Summary here: http://fragmental.tw/2010/09/12/thoughtworks-australia-teamhug-2010-why-enterprise-architectures-suck/

Published in: Technology
3 Comments
17 Likes
Statistics
Notes
No Downloads
Views
Total Views
10,811
On Slideshare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
213
Comments
3
Likes
17
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Why Enterprise Architecture Usually Sucks. Phillip Calçado ThoughtWorks http://fragmental.tw Saturday, 11 September 2010
  • 2. 1.Conway-Driven Architecture 2.Architecture-Driven Business Saturday, 11 September 2010
  • 3. 1. Conway-Driven Architecture “Any organisation that designs a system will inevitably produce a design whose structure is a copy of the organisation's communication structure.” -Melvin Conway Saturday, 11 September 2010
  • 4. Saturday, 11 September 2010
  • 5. team a team c team b Saturday, 11 September 2010
  • 6. system a system c system b Saturday, 11 September 2010
  • 7. system a doesn’t trust system c doesn’t trust doesn’t trust system b Saturday, 11 September 2010
  • 8. system a system c legacy billing database system y x inventory system z system b hr system w portal s Saturday, 11 September 2010
  • 9. can I have this feature? pretty please? Saturday, 11 September 2010
  • 10. LOL r u crazy? Saturday, 11 September 2010
  • 11. This “small” system a change means... system c legacy billing database system y x inventory system z system b hr system w portal s Saturday, 11 September 2010
  • 12. This “small” system a change means... system c legacy billing database system y x change inventory system z system b hr system w portal s Saturday, 11 September 2010
  • 13. This “small” system a change means... system c legacy billing database system y x change inventory system z system changeb hr system w portal s Saturday, 11 September 2010
  • 14. This “small” system a change means... system c legacy billing database system y x change inventory change system z system changeb hr system w portal s Saturday, 11 September 2010
  • 15. This “small” system a change means... change system c legacy billing database system y x change inventory change system z system changeb hr system w portal s Saturday, 11 September 2010
  • 16. This “small” system change a change means... change system c legacy billing database system y x change inventory change system z system changeb hr system w portal s Saturday, 11 September 2010
  • 17. This “small” system change a change means... change system c legacy billing database system y x change change inventory change system z system changeb hr system w portal s Saturday, 11 September 2010
  • 18. “I don’t understand why things are so hard around here!” “IT doesn’t deliver; we need more people. Get me some consultants!” “In-house is too complicated, let’s buy a package!” “We are too slow. We have to become agile! ” Saturday, 11 September 2010
  • 19. 2. Architecture-Driven Business “Developers have to translate for domain experts. Domain experts translate between developers and still other experts. Developers even translate for each other. The indirectness of communication conceals the formation of schisms. This leads to unreliable software that doesn't fit together.” -Eric Evans Saturday, 11 September 2010
  • 20. IT always wins. Saturday, 11 September 2010
  • 21. IT always wins. We need invoices to be available in our sales channel to our customers Saturday, 11 September 2010
  • 22. IT always wins. We need invoice.xsds to be available in our portlets to our contacts Saturday, 11 September 2010
  • 23. developer’s kingdom business’ nightmare Saturday, 11 September 2010
  • 24. business’ developer’s Oracle Invoice Server + Invoicing PDF Printing Service + SAP Identity Manager + Customer mapping CUS_SYS_01 Database + CRM CMS + E-Commerce Sale Server + Warehouse System Saturday, 11 September 2010
  • 25. “How did we end up with three CRMs again?” “These customers are in another database. We can create a service for that...” “This may be a simple change for the business but in our end it’s complicated!” Saturday, 11 September 2010
  • 26. Some Suggestions Saturday, 11 September 2010
  • 27. 1.Don’t try to break the law 2.Design principles are fractal 3.Domain-Driven Architecture Saturday, 11 September 2010
  • 28. 1.Don’t try to break the law 2.Design principles are fractal 3.Domain-Driven Architecture Saturday, 11 September 2010
  • 29. system a system c system b Saturday, 11 September 2010
  • 30. system a system c system the b governance group Saturday, 11 September 2010
  • 31. system a system c system the b governance group bottleneck Saturday, 11 September 2010
  • 32. create one project team with people from different departments Saturday, 11 September 2010
  • 33. 1.Don’t try to break the law 2.Design principles are fractal 3.Domain-Driven Architecture Saturday, 11 September 2010
  • 34. system a system c legacy billing database system y x inventory system z system b hr system w portal s Saturday, 11 September 2010
  • 35. system a Attribute Attribute Operation Operation system c Attribute Attribute Operation billing system y Operation legacy Attribute database Attribute x Operation Operation inventory system z Attribute system b Attribute Attribute Operation Attribute Operation Operation hr system w Operation Attribute Attribute Operation portal s Attribute Operation Attribute Operation Operation Saturday, 11 September 2010
  • 36. •Layers •Cohesion •Coupling •Dependency Injection •... still applies Saturday, 11 September 2010
  • 37. 1.Don’t try to break the law 2.Design principles are fractal 3.Domain-Driven Architecture Saturday, 11 September 2010
  • 38. big bang mapping Saturday, 11 September 2010
  • 39. Adopt Layers } Business Services } Services Infrastructure Saturday, 11 September 2010
  • 40. Adopt Layers Business Vocabulary } (and Business Logic) Business Services Technical Vocabulary (and no Business Logic) } Services Infrastructure Saturday, 11 September 2010
  • 41. Adopt Layers little mapping Saturday, 11 September 2010
  • 42. Good Architectures support and are driven by the business Bad Architectures require the business to change What’s easy to change in the business model should be easy to change in your architecture Saturday, 11 September 2010
  • 43. Good Architectures support and are driven by the business Bad Architectures require the business to change What’s easy to change in the business model should be easy to change in your architecture Saturday, 11 September 2010
  • 44. Good Architectures support and are driven by the business Bad Architectures require the business to change What’s easy to change in the business model should be easy to change in your architecture Saturday, 11 September 2010
  • 45. References •http://www.melconway.com/research/ committees.html •http://fragmental.tw/2009/02/24/what-is-a- service/ •http://fragmental.tw/2010/08/17/thoughts-on- abstractions-part-1-%E2%80%93-abstractions- everywhere/ •http://fragmental.tw/2010/09/06/thoughts-on- abstractions-part-2-abstractions-in-your-domain/ •http://fragmental.tw/2010/03/22/nevermind- domain-driven-design/ Saturday, 11 September 2010

×