Download to read offline
Uploaded byOmar Bashir
Technology Agility
The document discusses technological agility and its importance in driving value through agile transformations within organizations. It emphasizes the need for flexible technology that adapts to business changes and highlights concepts such as domain-driven design and non-functional requirements. The text also warns against over-engineering, advocating for simplicity and strategic focus on core domains to enhance agility.
Technology Agility
- 1.
- 2.
- 4.
- 5. In fact, inan agile project, technical excellence is measured by both capacity to deliver customer value today and create an adaptable product for tomorrow. Jim Highsmith
- 6. Agile Transformation forDisruption Organisation Talent Process Culture Process Engineering
- 7. Technology and BusinessChange ● Technology optimises business processes. ● Business change necessitates technology change. ● Not all technology facilitates business change. – Shorter the time to realise a business opportunity more challenging is the corresponding technical change.
- 8. Inflexible Technology ● Eachchange adds complexity. ● Complexity leads to brittleness. ● Brittleness leads to further inflexibility.
- 9. I very frequentlyget the question: ‘What’s going to change in the next 10 years?’ And that is a very interesting question; it’s a very common one. I almost never get the question: ‘What’s not going to change in the next 10 years?’ And I submit to you that that second question is actually the more important of the two—because you can build a business strategy around the things that are stable in time… Jeff Bezos
- 10. Disruption 101 ● Fundamentalneeds don’t change. ● How these needs are delivered is the differentiator. ● Leading and managing disruption, – A strategic focus on the domain. – Decoupling the domain from delivery mechanisms. – Enabling extensibility in the domain and flexibility in delivery.
- 11. Strategic Focus onDomain ● Domain Driven Design (DDD), – Focuses on core domain, – Explores models for creative collaboration between domain practitioners and software developers. – Encourages separation of concerns. ● Facilitates, – Strategic definition of sub-domains and interactions between them. – Definition of the domain information models.
- 13. Domain Model ● Foundationfor defining the strategic representation and deriving infrastructure data models. ● Consists of – Entities, – Value objects – Events – Aggregates – Abstractions ● Factories ● Repositories ● Services
- 14. Bounded Contexts ● Incrementalconstruction of the domain by domain decomposition. – Helps identify generic sub-domains with commoditised implementations. – Sub-domains logically separated by bounded contexts.
- 15. Event Storming ● Rapid,lightweight group modeling technique. – Capturing domain events without implementation specifics. ● Using the Ubiquitous Language, – Capture domain events on a timeline. – Add triggers, ● Commands causing the events. – Identify sources of triggers. – Describe data for every command event pair. – Identify policies, reactive logic after an event that triggers other events.
- 16. Software development isa learning process; working code is a side effect. Alberto Brandolini
- 17. Bounded Contexts FromEvent Model ● Pivotal Events – Indicate major changes in the domain. – Often form boundaries between sub-domains. ● Swim Lanes – Event series in overlapped timelines. ● Aggregates – Logically related entities and value objects. ● E.g., orders and order lines. – Emerge from grouping of events and commands.
- 18.
- 19. Impact of NFRs ●NFRs (Non-functional Requirements) define architectural styles on which the functional design is implemented. ● NFRs also steer infrastructure choices. ● NFRs vary over the life of an application. – May necessitate adopting different architectural styles or technologies. ● Tight coupling between functional code and infrastructure leads to inflexible technology. ● Relegating NFRs in a development cycle leads to inefficient systems.
- 20. Reducing Coupling andLeakage Account Management Credentials Management LDAP Access Management Database API
- 21. Reducing Coupling andLeakage Account Management Credentials Management LDAP Access Management Database API Generic Sub-domains Core Domain Infrastructure
- 22. Independence ● Reducing dependenciesto the minimum. – Lower app binary footprint. – Reduce risks. – Simplify testing. ● Isolating dependencies from functional logic. – Functional logic need not change when replacing dependencies. – Hexagonal architecture
- 23.
- 24. Agility vs OverEngineering ● Over engineered applications – Cater for all possible eventualities. – Are prematurely and speculatively optimised. – Inflexible due to increased complexity. ● Agile applications are – Flexible and extensible. – Scalable to increase performance on demand.
- 25. DIPSy A Framework forTechnological Agility
- 26.