Only permanence is change! How to drive key technical decisions while implementing composable digital experience platforms in a constant state of flux.
Only permanence is change! How to drive key technical decisions while implementing composable digital experience platforms in a constant state of flux.
Tassos Koutlas (tassos)
Over the last few years the average Drupal project has changed significantly. From sizeable web builds we are now landing contracts for multi-million dollar composable digital experience platforms with decoupled front-ends, elaborate system architectures and multiple third party integrations. The infrastructure needs also have changed. From a few servers with simple go-to market mechanisms, we are now looking to containerised public clouds, distributed file systems, high availability databases, multivariate cache implementations and a multitude of autoscaling environments to cater for development, integration and deployment pipelines.
Our ways of working have shifted also. From a couple of photoshop files completed before development started, we are now taking for granted multidisciplinary agile teams working in tandem with iterative component based design, decoupled JS front-end frameworks, third-party component libraries and automated testing in many parts of the code.
Digital does not have an end date – it's in product-mode. We are not really working on projects anymore, are we? Our work often is not governed by a beginning, a middle and an end. We are working on products, platforms or services, with fluid scope, flexible timelines and adjustable budgets. Our work often needs refinement, refactoring, adaptation. We are solving problems, providing solutions and consulting with our clients on an ongoing basis.
We are in a constant state of flux. And that comes with a whole set of challenges.
How do you make the best technical decisions in such a dynamic environment? How can you know if something is good enough for now and manage scope? How do you quantify and manage the technical debt introduced? How do you document those decisions so they can be revisited later on? How do you give voice to everyone who has something valuable to contribute? How do you create consensus within your team?
To manage all these challenges, we created a decision-making framework to help teams make key technical decisions (KTDs) in complex/dynamic projects. We call this framework The KTD process.
In this session, FFW will present a battle-tested, heuristic methodology for driving key technical decisions when implementing composable digital experience platforms and digital products for international clients. Topics will include:
- A innovative and complex technical architecture of a reference composable digital experience platform built by FFW.
- What are/were the architectural/technical problems experienced by the delivery teams when implementing such complex DXP projects,
- The KTD process and how we use it to guide architectural decisions at a platform level.
- How Tech Connect meetings (part of the KTD process) guide technical implementation details which then inform user story delivery.
- How KTD processes run alongside standard agile practices.
- Benefits of the approach (governance, audit, alignment, consensus, trust).
- Lessons learnt running the KTD process for this particular project.
The audience will:
- gain a perspective on how key technical decisions, which are by nature disruptive, can be made during the lifecycle of the project (beginning and during).
- understand how the KTD process can be used to create alignment, consensus and trust within the organisation.
- understand how the KTD process can be used to create a living documentation of the project key decisions, like a time machine that can go back in time.
- understand how decisions can be changed and revisited during the lifecycle of the project without making.
Session (45 minutes)
Experience level of the audience
Intermediate