FAQ

ADES has the overarching idea of an integrated view of process and technology. This is not seen in other frameworks so far, although it represents a widespread mindset among people working with microservices approaches or in the DevOps community. ADES doesn’t invent any buzzwords (except ‘ADES’, which is technically not a buzzword, but a buzz-acronym), ADES just puts important pieces together and tries to show progress while working on improvements.

SAFe, LESS, Nexus or DaD are agile scaling frameworks with more or less detailed ideas about the organization and methodology you should use to deliver a product. ADES, on the other hand, describes which goals you should focus on, what you should be able to do when working with these frameworks (or any other methodology for that matter). You should be able to get high quality, timely feedback to developers, you should steadily work on improvements in small, low risk experiments, a.s.o. Your ‘agile transition’ isn’t finished when you adopted an agile scaling framework, your agile transition is working when you continuously improve. ADES gives you an idea where you can improve and where you stand at the moment.

Yes, actually microservices have a vertical mindset. They bind developers around a topic and try to isolate them technically from others. This empowers innovation and responsibility. But microservices also have a rather fine granularity that isn’t always necessary when working in more settled sectors. Vertical approaches therefore also include the idea of more coarse grained self contained systems (SCS), that have one ‘vertical’ or ‘SCS’ per bounded context, or softer variants with a certain degree of technical coupling. Primarily important for verticality is, that the domain is the leading force behind top-level structuring efforts, not the technology or layering ideas. Layers are introduced one level down inside the verticals if necessary.

The reason why the evolutionary view of systems and agile transformation activities shouldn’t be separated is because they benefit and complement each other. For example ‘responsibility’ for a product can’t be effectively assigned to a team or individual if there are no technical choices they can make inside a tight architectural corset. Architectural emergence and soft standards are necessary. It also helps if technical excellence is lived inside the teams and responsibilities are not weakened by many parties working on aspects of the same domain. Verticality tries to avoid that. Feedback (another quintessential part of the right ADES side) is also more meaningful and easier to digest if a technical problem is easily associated with a part of the system (landscape) and in turn with ONE team. The links between the right and left side of ADES are manifold.