Legal information

Copyright DB Netz AG, licensed under CC-BY SA 3.0 DE (see full text in CC-BY-SA-3.0-DE)

ARCH - Process FAQs

Does the ARCH process mean that we have to throw away everything we have done so far?

No - although we speak of "top-down" and "bottom-up", ARCH is designed so that you can take existing work and link it up halfway through the process, if you need to. From then on, your direction of travel is always downwards.

So material that is already created at a certain level can be reused and integrated with the overall top-down philosophy of ARCH. This can provide us with more confidence that the existing lower-level design/requirements are valid. But we must be prepared to change them, if we discover through this process that not all needs at higher levels are fulfilled.

ARCH is huge. I cannot possibly do all these things! Where do I start?

ARCH is designed so that individual steps can be done independently. Sometimes, it is necessary to do a couple of steps in parallel, because there is a lot of shared information between the activities. Where this is true, it is noted in the activity description.

Additionally, the intention is that you do not always do a particular step for the whole system of interest scope at once. Instead, you take the scope of a single capability, and walk it through the process, designing in only those bits you need to support that capability. As further capabilities go through the same process, the system design is built up in layers with functions being added only when they are needed. This allows us to progress fast through the layers of the architecture model without holding ourselves up waiting for earlier stages to be completed for every part of the scope (that would be a waterfall approach).

How do I manage the work in Jira?ARCH is designed so that each individual step has its own definition of done and can therefore be ticketed. Typically, an Epic in Jira should represent a single operational or system capability that we want to deliver. Then, the tickets under that epic would be the individual steps of ARCH for that capability, inheriting the definition of done from the description of the ARCH activity in Confluence.
Is ARCH going to slow everything down?

ARCH is designed to compromise between two opposing needs: the need to move quickly and agilely towards prototypes and first deployments, and the need to deliver a specification of sufficient maturity and quality to satisfy all stakeholders and comply with our legal obligations.

It is always possible to begin working, even prototyping, at later stages of ARCH. The later you start, the more risk you must accept. But ARCH does not stop you from trying things out.

Design reviews in ARCH have two levels. For rapid progress through the layers, the standard applied is Safe Enough To Try (SETT). For moving our needs into the specifications, that is, feeding ARCH's output into GEN, the standard applied is "Safe Enough To Fly (SETF)". If we are happy enough to board an aircraft whose safety is dependent on our design, then we can progress to issue this specification to suppliers for serious procurement.

Why do we have to work in such a regimented way? Can't we just develop in whatever way we like in an agile work mode?

Agile does not imply the absence of a process. It simply means that the process should be designed for rapid progress, piecewise completion, and other lean principles such as flow optimisation. ARCH has been designed with this in mind.

We are legally and ethically obliged to develop our specifications to a certain level of quality so that the system is safe, secure and reliable. We need to assure ourselves and our stakeholders of these facts. We do this by developing evidence that the system was designed in accordance with relevant legislation and standards. It is much quicker and easier to do this by following a standardised process, than by asking every one of our engineers to read and interpret those standards for themselves, then come to their own conclusions about how they are best implemented.

ARCH and the other process areas are designed for continuous improvement so if we find something is not working we will address it in our retro meetings and feed back to the process owner our proposals for improvement.

It is recognised that ARCH represents a significantly higher amount of internal regulation than might be seen on a typical software development project. This is to be expected. We cannot beta-test system of interest on paying customers the way many software companies beta-test their products on their users. The consequences of system failure are far more severe for system of interest and therefore we have to take more care that the products reaching the outside world are really of good quality.


Clarify the Review Applicant and Review Assistant roles?

Review Applicant: the role who owns the capability that is being reviewed - probably the system architect who owns the capability, but some of the steps could of course be delegated, as long as accountability stays with the person who is actually delivering this piece of the content.

Review Assistant: a secretarial role - I separated this so that you could assign it to someone like an intern or a junior engineer, rather than making the applicant do it all themself. Of course, the same individual could do Review Applicant and Review Assistant if you like.