Goal: Produce a presentation for ARC and SLF on what it means to do Loose Coupling Architecture
Purpose: Inform and Educate the audience on the rapid elasticity capability of cloud technologies and the compromise of increased data management complexity (e.g. micro services) for a greater autonomy to IT Products / Teams
This idea's background: After peer reviewing the Target IT Solution Delivery Model, hearing the interoperability team struggle in convincing others to move towards APIs and use of containers, I get the impression that loose coupling is misunderstood or simply not believed in. E.g. "I get loose coupling, but no IT product can be independent from each other. You will always have dependencies.". This may be true in a legacy environment that is Monolith in nature and cannot rapidly scale but in with cloud technologies and proper data management capabilities (e.g. event based messaging, caching, synchronization) it can be.
Topics to cover in the presentation:
Demystify Loose Coupling. IT Products can run independently in production. Even if those IT Products get their data from a other source (e.g. PeopleSoft get their data from Phoenix. When Phoenix goes down, PeopleSodt keeps running).
Accept greater data management complexity. Data will be duplicated and distributed. This tradeoff to allow more autonomy and speed for change.
Rapid Elasticity of cloud allows IT products to scale, on demand, to supply requests in a timely manner
Caching capabilities are expected to reduce latency
Needs Contributions from:
Solutions Architecture team (member of ARC)
Interopery team (member of ARC, and QA for APIs to be published on the GC API store)
Cloud CoE (for support and credibility if we talk Cloud)
Goal: Produce a presentation for ARC and SLF on what it means to do Loose Coupling Architecture
Purpose: Inform and Educate the audience on the rapid elasticity capability of cloud technologies and the compromise of increased data management complexity (e.g. micro services) for a greater autonomy to IT Products / Teams
This idea's background: After peer reviewing the Target IT Solution Delivery Model, hearing the interoperability team struggle in convincing others to move towards APIs and use of containers, I get the impression that loose coupling is misunderstood or simply not believed in. E.g. "I get loose coupling, but no IT product can be independent from each other. You will always have dependencies.". This may be true in a legacy environment that is Monolith in nature and cannot rapidly scale but in with cloud technologies and proper data management capabilities (e.g. event based messaging, caching, synchronization) it can be.
Topics to cover in the presentation:
Needs Contributions from: