Issues with Agile include scaling and not having a detailed design which considers all aspects of security, interoperability and networking.  OOAD and Domain Driven Design can help alleviate these issues.


Agile is not only a delivery method of course, but an approach to project management and deployment. Agile stresses Proof of Concepts, sometimes called ‘Minimum Viable Product’ or MVP, which are hands-on attempts to assess technologies, concepts and first designs.  The design process is never ‘skipped’ in Agile, it is just not as formalized and sequential as the Waterfall theology.  MVPs or POCs are practical attempts to see what works, and what does not. They are not the theoretical models of Waterfall liturgy, but rational attempts to investigate if the chosen technologies, platforms, or services, do actually work in real life.


In any IT project, even a migration, you cannot escape Design. The main issue is how to build the design. You can employ the ‘big detailed design up front’, as demanded by Waterfall theologians.  Or, you can do it incrementally as real-world Agile projects reveal.  This means using a High Level Design to initiate Agile development processes, and over time, as you come to understand the technologies, services, existing platforms and target platforms; an End-to-End design.

Why Waterfall design fails

Waterfall emphasises the complete End to End design of any system before a stage-gate is signed off, and before any development resources are deployed.  The following are problems with this approach:

Your design always changes as you do more hands-on. You will find that the original high-level design is imperfect and needs to change.  You will discover that certain technologies are not a good fit.  Iterative hands-on POC/MVP work is the only way to discover this. In general, the Waterfall cult, impelled by barely IT literate Project Management, will construct a ‘big’ End to End design that has little connection with reality.

Design Issues with Agile

A key problem within many Agile projects is that the deep thinking about design can be ignored to produce more features. Time and budget pressures usually coerce engineers into adding features or functionality and discourages the important aspect of overall system design, including issues around security and interoperability.  In this environment, engineers do not give full consideration to data, behaviour or integration issues.  The code and related databases become the focus of attention.  Business logic, business processes, domain requirements are ignored in the rush to produce an MVP to impress management.

Common design issues in Agile include:

Domain Driven Design (DDD)can help

DDD can help alleviate some of Agile’s design weaknesses.  DDD encourages an iterative process of collaboration to explore a model and develop a shared language between development teams and domain experts.  Business Logic or ‘Domain Logic’, is embedded into the process at its inception, where processes, workflows, functionality and entity relationships are determined. This domain driven approach is not top-down, abstract, nor does it ignore iterative POCs. It does however force the separation of logical layers and ensures that the Business Logic, not the UI, is the key aspect of development.

Key aspects of DDD:

Building a proper design is not easy. The above assumes a proper budget, resourcing and coherent management structure.  A management structure to scale Agile over 3-4 project teams (20+) people, takes thought and skill.  Each team needs to be self-contained, cross-functional and be trained in Agile, dev-ops concepts and associated technologies (eg. Jira, CI/CD etc).  This is not trivial.


DDD comes out of OOAD (object oriented analysis and design). DDD breaks systems within a bounded Domain, into components, objects, and functional services.  It leads to micro-service architectures, including containerisation. Agile led DDD will give you a better, more coherent and detailed design, premised on Domain Business Logic. Events, services, technologies and target platforms will be assessed and discovered in an iterative fashion, recursively modifying the original design.  Key architectural principles including security, decoupling and redundancy will be deployed throughout the design.  Lastly, the use of MVPs and POCs will lead to a great improvement in finishing the project on time and on budget.