Conway's law revisited - Architectures for an effective IT
•
24 j'aime•5,741 vues
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.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à Conway's law revisited - Architectures for an effective IT
Similaire à Conway's law revisited - Architectures for an effective IT (20)
Plus de Uwe Friedrichsen
Plus de Uwe Friedrichsen (10)
Dernier
Dernier (20)
Conway's law revisited - Architectures for an effective IT
- 1. Conway’s law revisited Architectures for an effective IT Uwe Friedrichsen, codecentric AG, 2012-2015
- 2. @ufried Uwe Friedrichsen | uwe.friedrichsen@codecentric.de | http://slideshare.net/ufried | http://ufried.tumblr.com
- 3. Why should we change?
- 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
- 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. Nice, but how does this relate to IT?
- 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. IT is a key success factor for belonging to the survivors of the economic darwinism
- 10. What business needs from IT …
- 13. How IT serves business …
- 15. What’s wrong with IT?
- 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
- 17. 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 …
- 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 …
- 19. 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 …
- 20. 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
- 21. We need to rethink IT!
- 23. But there is more …
- 24. Lean Enterprise Product shaping/optimization Innovation Measure & analyze Accelerating OODA loop Quick customer feedback cycles
- 26. IT as a Product (“Digitization”) Virtualization of products IT-centric business models Disruptive new business models
- 27. Economic Darwinism Business-related Change Drivers Lean Enterprise IT as a Product IT Technology-related Change Drivers
- 28. Pay-per-Use Business Case Self-Service Cloud Elasticity Unreliable COTS Hardware Provisioning Speed
- 29. Economic Darwinism Business-related Change Drivers Lean Enterprise IT as a Product Cloud IT Technology-related Change Drivers
- 30. Zero Downtime Peer Multiplication Mobile & IoT Deep Process Integration Unreliable Communication Unpredictable Load Patterns
- 31. Economic Darwinism Business-related Change Drivers Lean Enterprise IT as a Product Cloud IoT Mobile IT Technology-related Change Drivers
- 32. … and more Big Data Analysis Amplifiers Social
- 33. Economic Darwinism Business-related Change Drivers Lean Enterprise IT as a Product Cloud IoT Mobile IT Big Data Analytics Social Technology-related Change Drivers
- 34. We really need to rethink IT!
- 35. Process People Organization Governance Agile Lean DevOps Flow Decentralization Autonomy End2End Responsibility Craftsmanship Mastery Curiosity Beyond Budgeting (BetaCodex) Systemic Optimization
- 36. It would be fascinating to discuss them all and to see how they fit into each other …
- 37. … but right now we want to focus on architecture
- 38. So, what does that mean for architecture?
- 39. 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
- 40. 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
- 41. 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)
- 42. Hey, what about Conway’s law?
- 43. Conway’s law: Organizations which design systems [...] are constrained to produce designs which are copies of the communication structures of these organizations
- 44. 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)
- 45. Monolith Example: Multiple teams working on a monolith usually end up in tightly coupled teams with excessive communication overhead
- 46. But what kind of organizational structure does our architecture need to support?
- 47. Process People Organization Governance Agile Lean DevOps Flow Decentralization Autonomy End2End Responsibility Craftsmanship Mastery Curiosity Beyond Budgeting (BetaCodex) Systemic Optimization
- 48. 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.
- 49. 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)
- 50. What are the appropriate solutions?
- 51. Let’s check a few trending topics …
- 52. µ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
- 54. REST • Uniform access interface to resources • Closely related to the HTTP protocol • HATEOAS (Hypermedia as the engine of application state)
- 56. 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
- 58. 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
- 60. 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
- 62. Functional Programming • Alternative programming paradigm • Functional languages (Erlang, Haskell, Clojure, …) • Hybrid languages (Scala, …) • Languages with functional extensions (Python, JavaScript, Java, …)
- 64. NoSQL • Augments the data store solution space • Different sweet spots than RDBMS • Key-Value Store – Wide Column Store – Document Store • Graph Database
- 66. Continuous Delivery • Automate the software delivery chain • Build – Continuous Integration, … • Test – Test Automation, … • Deploy – Infrastructure as Code, …
- 68. Cloud provisioning model • On-demand provisioning and de-provisioning • Instant availability • Self-service • Pay-per-use
- 70. Docker • Build, ship, run on container-basis • Process-level isolation • Declarative communication path configuration • Cambrian explosion of ecosystem at the moment
- 72. … and there are many more
- 73. What can we learn from this?
- 74. 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
- 75. How could an architectural style look like?
- 76. µServices • Conway’s law • Built for replacement • Aligned with business capabilities • Bounded Context (Domain-Driven Design) • Separate UI and service
- 77. 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
- 78. 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)
- 79. 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
- 80. 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
- 81. µS Request/Response : Horizontal slicing Flow / Process µS µS µS µS µS µS Event-driven : Vertical slicing µS µS µS µS µS Flow / Process
- 82. 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
- 83. Event/data flow Event/data flow Resource access Error flow Control flow µS Isolation
- 84. 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
- 85. Container Manager µS µS µS µS µS µS µS µS µS µS µS µS µS µS µS Container Explicitly declared communication paths µService
- 86. Production-readiness • Configuration • Discovery, Routing • Choreography, Orchestration • Observability • Monitoring, Measuring, Logging
- 87. 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
- 88. Automation • Automate everything • Build, test & deployment (Continuous Delivery) • Resource provisioning (Cloud API) • Restart, failover, error handling (Resilience) • Starting and tearing down instances (Scalability)
- 89. 5 + 2 style • µServices • REST interfaces • Event-driven communication • Resilient (reactive) software design • Cloud/container provisioning model • Production-readiness • Automation
- 90. One more thing …
- 91. 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
- 92. 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)
- 93. We need to rethink IT Join the most disruptive and exciting change we have seen in IT for many years
- 94. @ufried Uwe Friedrichsen | uwe.friedrichsen@codecentric.de | http://slideshare.net/ufried | http://ufried.tumblr.com