Modern times - architectures for a Next Generation of IT

2,891 views

Published on

In this presentation I focus on the architectural aspect of the next generation of enterprise IT topic I already covered in some other presentations.

The slide deck starts with a quick motivation. It describes the external drivers that require traditional enterprise IT to change. Based on these drivers, the drivers and requirements for an architecture that supports the external drivers are derived.

The second major part of the slide deck then examines some of today's IT hype topics and evaluates them with respect to the architectural requirements derived before. Be aware that the evaluation partially is hard to understand without the voice track. Actually, at some places the explanations on the voice track are more important than the evaluations themselves. Thus, please do not take them too literally.

The last major part then tries to sketch a possible architectural style that suits the given requirements. Again, the rationale for picking the respective elements are on the voice track, and it is just one possible style. There are for sure more styles available that suit the needs.

Yet I think, the style described makes clear that the upcoming enterprise architectural styles are quite different from the styles that were predominant in the last 10 or 15 years and makes clear that we all have to face new challenges - not only on the architectural level.

Sorry again that the voice track is missing. Yet I think, that the presentation provides some helpful ideas even without the voice.

Published in: Technology
0 Comments
12 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,891
On SlideShare
0
From Embeds
0
Number of Embeds
48
Actions
Shares
0
Downloads
100
Comments
0
Likes
12
Embeds 0
No embeds

No notes for slide

Modern times - architectures for a Next Generation of IT

  1. 1. Modern Times Architectures for a Next Generation of IT Uwe Friedrichsen, codecentric AG, 2014-2015
  2. 2. @ufried Uwe Friedrichsen | uwe.friedrichsen@codecentric.de | http://slideshare.net/ufried | http://ufried.tumblr.com
  3. 3. Why do we need a “Next Generation IT”?
  4. 4. Economic Darwinism
  5. 5. 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
  6. 6. Nice, but how does this relate to IT?
  7. 7. 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
  8. 8. IT is a key success factor for belonging to the survivors of the economic darwinism
  9. 9. What business needs from IT …
  10. 10. How IT serves business …
  11. 11. Economic Darwinism Business-related Change Drivers IT Technology-related Change Drivers
  12. 12. But there is more …
  13. 13. Lean Enterprise Product
 shaping/optimization Innovation Measure & analyze Accelerating OODA loop Quick customer feedback cycles
  14. 14. Economic Darwinism Business-related Change Drivers Lean Enterprise IT Technology-related Change Drivers
  15. 15. IT as a Product Virtualization of products IT-centric business models Disruptive new business models
  16. 16. Economic Darwinism Business-related Change Drivers Lean Enterprise IT as a Product IT Technology-related Change Drivers
  17. 17. Pay-per-Use Business Case Self-Service Cloud Elasticity Unreliable
 COTS Hardware Provisioning Speed
  18. 18. Economic Darwinism Business-related Change Drivers Lean Enterprise IT as a Product Cloud IT Technology-related Change Drivers
  19. 19. Zero Downtime Peer Multiplication Mobile & IoT Deep Process Integration Unreliable
 Communication Unpredictable Load Patterns
  20. 20. Economic Darwinism Business-related Change Drivers Lean Enterprise IT as a Product Cloud IoT Mobile IT Technology-related Change Drivers
  21. 21. … and more Big Data Analysis Amplifiers Social
  22. 22. Economic Darwinism Business-related Change Drivers Lean Enterprise IT as a Product Cloud IoT Mobile IT Big Data Analytics Social Technology-related Change Drivers
  23. 23. Why does traditional IT usually fail
 to respond to those challenges?
  24. 24. Traditional IT bases its optimization efforts
 on the wrong goals and principles
  25. 25. Traditional IT goals/principles •  Fault avoidance at any cost
 a.k.a. “the root of all evil” •  Tayloristic organization •  Local optimization •  Process frenzy •  Central control •  Long-running projects •  Standardization •  Cost minimization à Not suitable to respond to new challenges
  26. 26. Then, what are the new goals?
  27. 27. Economic Darwinism Business-related Change Drivers Lean Enterprise IT as a Product Cloud IoT Mobile IT Big Data Analytics Social Technology-related Change Drivers
  28. 28. Short cycle times Continuous output High flexibility High reliability Equally Valued Goals Holistic consideration Goals of a Next Generation (of) IT
  29. 29. And what are the new principles?
  30. 30. Principles of a Next Generation (of) IT The Core Principles Maximizing innovation instead of minimizing costs Controlled experiments instead of fault avoidance at any cost Decentralized, self dependent teams instead of central control and goal sheets Flexible adaption instead of static planning Accepting complexity on all levels Based on Jeff Sussna's 21st Century IT Manifesto (http://blog.ingineering.it/post/39385342347/21st-century-it-manifesto) Refined in collaboration with Eberhard Wolff
  31. 31. Principles of a Next Generation (of) IT The Technical Principles Diversity & lightweight tools instead of monoculture & integrated solutions Resilience instead of stability (µ)Services instead of monoliths Elasticity instead of upfront capacity planning Consistent automation of routine tasks Based on Jeff Sussna's 21st Century IT Manifesto (http://blog.ingineering.it/post/39385342347/21st-century-it-manifesto) Refined in collaboration with Eberhard Wolff
  32. 32. Nice (again), but how does this
 relate to architecture?
  33. 33. Goals & Principles Architecture drives supports
  34. 34. What does that mean for architecture?
  35. 35. 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
  36. 36. 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
  37. 37. 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)
  38. 38. What are the appropriate solutions?
  39. 39. Let’s check a few hype topics …
  40. 40. µ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
  41. 41. µServices Cost-efficiency UniformInterface Resilience Scalability Deployability Replaceability Changeability Extensibility Understandability
  42. 42. REST •  Uniform access interface to resources •  Closely related to the HTTP protocol •  HATEOAS (Hypermedia as the engine of application state)
  43. 43. REST Cost-efficiency UniformInterface Resilience Scalability Deployability Replaceability Changeability Extensibility Understandability
  44. 44. Event-driven •  Asynchronous communication paradigm •  Technical decoupling of communication peers (isolation) •  Location transparency in conjunction with MOM •  Call-stack paradigm replaced by (complex) message networks
  45. 45. Event-driven Cost-efficiency UniformInterface Resilience Scalability Deployability Replaceability Changeability Extensibility Understandability
  46. 46. 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
  47. 47. CQRS Cost-efficiency UniformInterface Resilience Scalability Deployability Replaceability Changeability Extensibility Understandability READ WRITE
  48. 48. Reactive •  Event-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
  49. 49. Reactive Cost-efficiency UniformInterface Resilience Scalability Deployability Replaceability Changeability Extensibility Understandability
  50. 50. Functional Programming •  Alternative programming paradigm •  Functional languages (Erlang, Haskell, Clojure, …) •  Hybrid languages (Scala, …) •  Languages with functional extensions (Python, JavaScript, Java, …)
  51. 51. Functional Programming Cost-efficiency UniformInterface Resilience Scalability Deployability Replaceability Changeability Extensibility Understandability
  52. 52. NoSQL •  Augments the data store solution space •  Different sweet spots than RDBMS •  Key-Value Store – Wide Column Store – Document Store •  Graph Database
  53. 53. NoSQL Cost-efficiency UniformInterface Resilience Scalability Deployability Replaceability Changeability Extensibility Understandability
  54. 54. Continuous Delivery •  Automate the software delivery chain •  Build – Continuous Integration, … •  Test – Test Automation, … •  Deploy – Infrastructure as Code, …
  55. 55. Continuous Delivery Cost-efficiency UniformInterface Resilience Scalability Deployability Replaceability Changeability Extensibility Understandability
  56. 56. Cloud provisioning model •  On-demand provisioning and de-provisioning •  Instant availability •  Self-service •  Pay-per-use
  57. 57. Cloud provisioning model Cost-efficiency UniformInterface Resilience Scalability Deployability Replaceability Changeability Extensibility Understandability
  58. 58. Docker •  Build, ship, run on container-basis •  Process-level isolation •  Declarative communication path configuration •  Cambrian explosion of ecosystem at the moment
  59. 59. Docker Cost-efficiency UniformInterface Resilience Scalability Deployability Replaceability Changeability Extensibility Understandability
  60. 60. … and there are many more
  61. 61. What can we learn from this?
  62. 62. Findings •  There is not a simple solution and no “one size fits all” •  Some of the topics evaluated have a high potential •  Some of the topics evaluated do not help so much •  A combination of several approaches is needed
  63. 63. How would an architectural style look like?
  64. 64. µServices •  Conway’s law •  Built for replacement •  Aligned with business capabilities •  Bounded Context (Domain-Driven Design) •  Separate UI and service
  65. 65. 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
  66. 66. 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)
  67. 67. 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
  68. 68. 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
  69. 69. µS Request/Response : Horizontal slicing Flow / Process µS µS µS µS µS µS Event-driven : Vertical slicing µS µS µS µS µS Flow / Process
  70. 70. Resilient/reactive 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
  71. 71. Event/data flow Event/data flow Resource access Error flow Control flow µS Isolation
  72. 72. Cloud 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
  73. 73. Container Manager µS µS µS µS µS µS µS µS µS µS µS µS µS µS µS Container Explicitly declared communication paths µService
  74. 74. Automate •  Automate everything •  Build, test & deployment (Continuous Delivery) •  Resource provisioning (Cloud API) •  Restart, failover, error handling (Resilience) •  Starting and tearing down instances (Scalability)
  75. 75. Wrap-up •  IT is the nervous system of a company •  Delivery speed is the new benchmark •  Architecture must support the drivers •  The new architectures are different •  New challenges for developers (& ops)
  76. 76. It’s the most disruptive and exciting change
 we have seen in IT for many years Join the IT revolution!
  77. 77. @ufried Uwe Friedrichsen | uwe.friedrichsen@codecentric.de | http://slideshare.net/ufried | http://ufried.tumblr.com

×