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.
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
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
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
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)
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?
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)
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
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
64. NoSQL
• Augments the data store solution space
• Different sweet spots than RDBMS
• Key-Value Store – Wide Column Store – Document Store
• Graph Database
70. Docker
• Build, ship, run on container-basis
• Process-level isolation
• Declarative communication path configuration
• Cambrian explosion of ecosystem at the moment
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
76. µServices
• Conway’s law
• Built for replacement
• Aligned with business capabilities
• Bounded Context (Domain-Driven Design)
• Separate UI and service
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)
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
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
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
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