Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Conway's law revisited - Architectures for an effective IT

4,893 views

Published on

This session is sort of a journey from the change drivers that affect today's IT to ways to respond to them in the architecture.

It starts with the business and technological drivers that force IT into change. After briefly sketching the big picture for IT as a whole, it focuses on the drivers and requirements that can be derived for architecture from the IT change drivers.

After carving out the architectural requirements, those are mapped to some trending topics. Based on the mapping results, it becomes obvious that there is no silver bullet (we all know that but this doesn't keep us from hoping that there still is one).

It is required to combine some ideas and concepts to a joint architectural style that becomes more than just the sum of its parts - and that's the last part of the story: Describing an architectural style that helps addressing the IT change drivers shown in the first part.

As a side note, at the end an idea is shown how EAM could fit into the picture laid out by the slides.

As always, many details are only on the voice track - and as always, sorry about that! But I hope that the slides still contain some ideas which are valuable for you.

Published in: Technology

Conway's law revisited - Architectures for an effective IT

  1. 1. Conway’s law revisited Architectures for an effective IT Uwe Friedrichsen, codecentric AG, 2012-2015
  2. 2. @ufried Uwe Friedrichsen | uwe.friedrichsen@codecentric.de | http://slideshare.net/ufried | http://ufried.tumblr.com
  3. 3. Why should we change?
  4. 4. Formal part of value creation Solution: machine Dynamic part of value creation Solution: man sluggishness/low dynamic high dynamichigh dynamic The historical course of market dynamics and the recent rise of highly dynamic and complex markets The dominance of high dynamics and complexity is neither good nor bad. It‘s a historical fact. t1970/80 today Age of crafts manu- facturing Age of tayloristic industry Age of global markets 1850/1900 Spacious markets, little competition Local markets, high customi- zation Outperformers exercise market pressure over conventional companies We call the graph shown here the “Taylor Bathtub”. The “bathtub” curve Source: BetaCodex Network Associates, “Organize for complexity”, BetaCodex Network White Paper 12 & 13
  5. 5. Economic Darwinism
  6. 6. Economic Darwinism Everyone is affected by Economic Darwinism •  All sectors •  Growing globalization on all levels •  Internet business •  More competitors per customer •  Higher customer expectations •  Lower customer loyalty à In the long run only those will survive who meet the customer needs and demands best
  7. 7. Nice, but how does this relate to IT?
  8. 8. IT is the nervous system IT is vital •  All companies •  IT is not just supporter or „cost center“ … •  … but it is the central nervous system •  Even short IT outages considered critical •  No business change without IT •  No new products without IT à IT limits the maximum possible
 adaption rate of a company
  9. 9. IT is a key success factor for belonging to the survivors of the economic darwinism
  10. 10. What business needs from IT …
  11. 11. Responsiveness Reliability Throughput Flexibility
  12. 12. How IT serves business …
  13. 13. What’s wrong with IT?
  14. 14. 1960 1970 1980 1990 2000 2010 2020 Complicated (Business functions) Complex (Business processes) Highly complex (Business nervous system) Software crisis Software engineering PC LAN Internet Business Support of IT Selective Holistic Complicated Complex “Moore’s law” Mobile IoT
  15. 15. 1960 1970 1980 1990 2000 2010 2020 Complicated (Business functions) Complex (business processes) Highly complex (Business nervous system) Software crisis Software engineering PC LAN Internet Business Support of IT Selective Holistic Complicated Complex “Moore’s law” Mobile IoT We are here …
  16. 16. 1960 1970 1980 1990 2000 2010 2020 Complicated (Business functions) Complex (business processes) Highly complex (Business nervous system) Software crisis Software engineering PC LAN Internet Business Support of IT Selective Holistic Complicated Complex “Moore’s law” Mobile IoT … but we still base most of our decisions on that We are here …
  17. 17. Formal part of value creation Solution: machine Dynamic part of value creation Solution: man sluggishness/low dynamic high dynamichigh dynamic The historical course of market dynamics and the recent rise of highly dynamic and complex markets The dominance of high dynamics and complexity is neither good nor bad. It‘s a historical fact. t1970/80 today Age of crafts manu- facturing Age of tayloristic industry Age of global markets 1850/1900 Spacious markets, little competition Local markets, high customi- zation Outperformers exercise market pressure over conventional companies We call the graph shown here the “Taylor Bathtub”. Remember the bathtub curve? This adds an additional twist …
  18. 18. 1960 1970 1980 1990 2000 2010 2020 Complicated (Business functions) Complex (business processes) Highly complex (Business nervous system) Software crisis Software engineering PC LAN Internet Business Support of IT Selective Holistic Complicated Complex “Moore’s law” Mobile IoT … but we still base most of our decisions on that We are here … Business is very different today … … than it was back then
  19. 19. We need to rethink IT!
  20. 20. Economic Darwinism Business-related Change Drivers IT Technology-related Change Drivers
  21. 21. But there is more …
  22. 22. Lean Enterprise Product
 shaping/optimization Innovation Measure & analyze Accelerating OODA loop Quick customer feedback cycles
  23. 23. Economic Darwinism Business-related Change Drivers Lean Enterprise IT Technology-related Change Drivers
  24. 24. IT as a Product (“Digitization”) Virtualization of products IT-centric business models Disruptive new business models
  25. 25. Economic Darwinism Business-related Change Drivers Lean Enterprise IT as a Product IT Technology-related Change Drivers
  26. 26. Pay-per-Use Business Case Self-Service Cloud Elasticity Unreliable
 COTS Hardware Provisioning Speed
  27. 27. Economic Darwinism Business-related Change Drivers Lean Enterprise IT as a Product Cloud IT Technology-related Change Drivers
  28. 28. Zero Downtime Peer Multiplication Mobile & IoT Deep Process Integration Unreliable
 Communication Unpredictable Load Patterns
  29. 29. Economic Darwinism Business-related Change Drivers Lean Enterprise IT as a Product Cloud IoT Mobile IT Technology-related Change Drivers
  30. 30. … and more Big Data Analysis Amplifiers Social
  31. 31. Economic Darwinism Business-related Change Drivers Lean Enterprise IT as a Product Cloud IoT Mobile IT Big Data Analytics Social Technology-related Change Drivers
  32. 32. We really need to rethink IT!
  33. 33. Process People Organization Governance Agile Lean DevOps Flow Decentralization Autonomy End2End Responsibility Craftsmanship Mastery Curiosity Beyond Budgeting (BetaCodex) Systemic Optimization
  34. 34. It would be fascinating to discuss them all and to see how they fit into each other …
  35. 35. … but right now we want to focus on architecture
  36. 36. So, what does that mean for architecture?
  37. 37. Architectural drivers •  Need for quick change and extension •  Replace over reuse •  Need for quick releases •  Unpredictable load patterns •  Distributed, highly interconnected systems •  Extreme high service availability •  Diverse front-ends and devices •  Cost efficiency
  38. 38. Architectural requirements •  Easy to understand •  Easy to extend •  Easy to change •  Easy to replace •  Easy to deploy •  Easy to scale •  Easy to recover •  Easy to connect •  Easy to afford
  39. 39. Architectural requirements •  Easy to understand à Understandability •  Easy to extend à Extensibility •  Easy to change à Changeability •  Easy to replace à Replaceability •  Easy to deploy à Deployability •  Easy to scale à Scalability •  Easy to recover à Resilience •  Easy to connect à Uniform interface •  Easy to afford à Cost-efficiency
 (for development & operations)
  40. 40. Hey, what about Conway’s law?
  41. 41. Conway’s law: Organizations which design systems [...] are constrained to produce designs which are copies of the communication structures of these organizations
  42. 42. Conway’s law reversed: You won’t be able to successfully establish an efficient organization
 structure that is not supported by your system design (architecture)
  43. 43. Monolith Example: Multiple teams working on a monolith usually end up in tightly coupled teams with excessive communication overhead
  44. 44. But what kind of organizational structure does our architecture need to support?
  45. 45. Process People Organization Governance Agile Lean DevOps Flow Decentralization Autonomy End2End Responsibility Craftsmanship Mastery Curiosity Beyond Budgeting (BetaCodex) Systemic Optimization
  46. 46. Our architecture needs to support decentralized, autonomous* teams * Autonomy in this context means to have the teams working as autonomous as possible, yet making sure they share
 * the same overall vision. This means a certain amount of communication between the teams is always needed but it
 * should be made sure that it happens as efficient as possible.
  47. 47. Architectural requirements •  Easy to separate à Autonomy •  Easy to understand à Understandability •  Easy to extend à Extensibility •  Easy to change à Changeability •  Easy to replace à Replaceability •  Easy to deploy à Deployability •  Easy to scale à Scalability •  Easy to recover à Resilience •  Easy to connect à Uniform interface •  Easy to afford à Cost-efficiency
 (for development & operations)
  48. 48. What are the appropriate solutions?
  49. 49. Let’s check a few trending topics …
  50. 50. µServices •  Built for replacement (not reuse) •  Self-dependent, loosely coupled services •  Should be aligned with business capability •  Size should not exceed what one brain can grasp
  51. 51. µServices Cost-efficiency UniformInterface Resilience Scalability Deployability Replaceability Changeability Extensibility Understandability Autonomy
  52. 52. REST •  Uniform access interface to resources •  Closely related to the HTTP protocol •  HATEOAS (Hypermedia as the engine of application state)
  53. 53. REST Cost-efficiency UniformInterface Resilience Scalability Deployability Replaceability Changeability Extensibility Understandability Autonomy
  54. 54. Event/Message-driven •  Asynchronous communication paradigm •  Technical decoupling of communication peers (isolation) •  Location transparency in conjunction with MOM •  Call-stack paradigm replaced by (complex) message networks
  55. 55. Event/Message-driven Cost-efficiency UniformInterface Resilience Scalability Deployability Replaceability Changeability Extensibility Understandability Autonomy
  56. 56. CQRS •  Command Query Responsibility Segregation •  Separate read and write interfaces including underlying models •  Separation can be extended up to the data store(s) •  Allows for optimized data representations and access logic READ WRITE
  57. 57. CQRS Cost-efficiency UniformInterface Resilience Scalability Deployability Replaceability Changeability Extensibility Understandability READ WRITE Autonomy
  58. 58. Reactive •  Message-driven – asynchronous and non-blocking •  Scalable – scaling out and embracing the network •  Resilient – isolation, loose coupling and hierarchical structure •  Responsive – latency control and graceful degradation of service
  59. 59. Reactive Cost-efficiency UniformInterface Resilience Scalability Deployability Replaceability Changeability Extensibility Understandability Autonomy
  60. 60. Functional Programming •  Alternative programming paradigm •  Functional languages (Erlang, Haskell, Clojure, …) •  Hybrid languages (Scala, …) •  Languages with functional extensions (Python, JavaScript, Java, …)
  61. 61. Functional Programming Cost-efficiency UniformInterface Resilience Scalability Deployability Replaceability Changeability Extensibility Understandability Autonomy
  62. 62. NoSQL •  Augments the data store solution space •  Different sweet spots than RDBMS •  Key-Value Store – Wide Column Store – Document Store •  Graph Database
  63. 63. NoSQL Cost-efficiency UniformInterface Resilience Scalability Deployability Replaceability Changeability Extensibility Understandability Autonomy
  64. 64. Continuous Delivery •  Automate the software delivery chain •  Build – Continuous Integration, … •  Test – Test Automation, … •  Deploy – Infrastructure as Code, …
  65. 65. Continuous Delivery Cost-efficiency UniformInterface Resilience Scalability Deployability Replaceability Changeability Extensibility Understandability Autonomy
  66. 66. Cloud provisioning model •  On-demand provisioning and de-provisioning •  Instant availability •  Self-service •  Pay-per-use
  67. 67. Cloud provisioning model Cost-efficiency UniformInterface Resilience Scalability Deployability Replaceability Changeability Extensibility Understandability Autonomy
  68. 68. Docker •  Build, ship, run on container-basis •  Process-level isolation •  Declarative communication path configuration •  Cambrian explosion of ecosystem at the moment
  69. 69. Docker Cost-efficiency UniformInterface Resilience Scalability Deployability Replaceability Changeability Extensibility Understandability Autonomy
  70. 70. … and there are many more
  71. 71. What can we learn from this?
  72. 72. Findings •  There is not a simple solution and no “one size fits all” •  Some of the topics evaluated bear a high potential •  Some of the topics evaluated are more of a side note •  A mutually reinforcing combination of concepts is needed
  73. 73. How could an architectural style look like?
  74. 74. µServices •  Conway’s law •  Built for replacement •  Aligned with business capabilities •  Bounded Context (Domain-Driven Design) •  Separate UI and service
  75. 75. Bounded Context Bounded Context Bounded Context µS µS µS µS µS µS µS µS µS µS µS µS µS µS µS UI e.g., B2C-Portal UI e.g., embedded in Partner-Portal UI e.g., Mobile App UI e.g., Clerk Desktop
  76. 76. REST interfaces •  Use as API gateway for client access •  Encapsulate dynamics and complexity of service landscape •  Provide client-driven, coarse-grained service calls
 behind a uniform API based on a proven protocol •  Should be provided on bounded context level •  Decouple speed of evolvement (services vs. API)
  77. 77. Bounded Context µS µS µS µS µS REST API Gateway µS Bounded Context Other Client User Interface Bounded Context Message-based API also okay,
 but requires clear and stable, client-oriented contract
  78. 78. Event-driven communication •  Use for inter-service communication •  Decoupling and isolation •  Vertical slicing of functionality •  Easier evolution of flows and processes •  Configuration-visualization-monitoring support required
  79. 79. µS Request/Response : Horizontal slicing Flow / Process µS µS µS µS µS µS Event-driven : Vertical slicing µS µS µS µS µS Flow / Process
  80. 80. Resilient (reactive) software design •  Resilience and responsiveness are mandatory •  Elastic design for scalability •  Start with isolation and latency control •  Separate control and data flow •  Many new challenges for developers
  81. 81. Event/data flow Event/data flow Resource access Error flow Control flow µS Isolation
  82. 82. Cloud/container provisioning model •  Basis for elasticity at runtime •  Basis for speed and flexibility at development time •  Private, hybrid or public •  Should be combined with container approaches (e.g., Docker) •  “Natural” infrastructure for µService architecture
  83. 83. Container Manager µS µS µS µS µS µS µS µS µS µS µS µS µS µS µS Container Explicitly declared communication paths µService
  84. 84. Production-readiness •  Configuration •  Discovery, Routing •  Choreography, Orchestration •  Observability •  Monitoring, Measuring, Logging
  85. 85. Configuration •  Netflix Archaius Orchestration •  Apache Aurora on Apache Mesos •  Marathon •  Kubernetes •  Fleet Discovery •  Netflix Eureka •  Apache ZooKeeper •  Kubernetes •  Etcd Routing •  Netflix Zuul & Ribbon •  Twitter Finagle Monitoring •  Hystrix •  Twitter Zipkin (Distributed Tracing) Measuring •  Dropwizard Metrics Logging •  ELK •  Graylog2 •  Splunk
  86. 86. Automation •  Automate everything •  Build, test & deployment (Continuous Delivery) •  Resource provisioning (Cloud API) •  Restart, failover, error handling (Resilience) •  Starting and tearing down instances (Scalability)
  87. 87. 5 + 2 style •  µServices •  REST interfaces •  Event-driven communication •  Resilient (reactive) software design •  Cloud/container provisioning model •  Production-readiness •  Automation
  88. 88. One more thing …
  89. 89. Side note Enterprise architecture management •  Should not impact team autonomy •  No interference with team responsibilities •  Focus on shared vision •  Provide common vision for all teams •  Makes communication efficient •  To follow common vision teams need to communicate •  Minimal set of joint technical collaboration standards required for efficient communication •  Not a separate team •  Use representatives from the teams •  Add a person in charge if required à Very different from traditional EAM
  90. 90. Wrap-up •  Business & technological driven change •  IT as a whole must respond to the drivers •  Architecture must support the drivers •  Architecture must support the organization •  The new architectures are different •  New challenges for developers (& ops)
  91. 91. We need to rethink IT Join the most disruptive and exciting change we have seen in IT for many years
  92. 92. @ufried Uwe Friedrichsen | uwe.friedrichsen@codecentric.de | http://slideshare.net/ufried | http://ufried.tumblr.com

×