A review that cannot say which layer an element is on is not yet a review of the model. It is a negotiation about the drawing. A function appears on the operational layer. A physical node is drawn before anyone has agreed the logical components. A screen layout, a vendor name, or a hardware part number shows up in Operational Analysis or System Analysis. Logical and physical content share a single diagram because the layer question was never asked. Numeric performance claims attach to elements that have not been placed yet. Transitions are treated as if they empty the layer you left, so the operational story is “done” and can be forgotten.
OA, SA, LA, PA, and EPBS are easy to mix. They are also official. The five Arcadia layers, as Capella implements them, are Operational Analysis, System Analysis, Logical Architecture, Physical Architecture, and EPBS. EPBS is part of the method, not optional folklore. Each layer answers a different question. If you cannot say which question an element is answering, the diagram can look finished and still not be ready for review.
The Arcadia Layer Pocket Guide (for Eclipse Capella) is a 6-page pocket guide and a one-page printable poster for deciding which Arcadia layer an element belongs on, and what should transition down versus stay. It is written for Eclipse Capella 7.1 and the Arcadia layers as Capella implements them. The kit does not include the Capella application, a .capella project, or an official sample model. It is a reference you keep at the desk, not a model you import.
What goes wrong when the layer question is never asked?
The problems are specific, and they have a habit of arriving together.
Review meetings stall because no one can say which layer an element is on. Time that should be spent reading the architecture is spent untangling the drawing.
Screen layouts, vendor names, or hardware part numbers appear in OA or SA, where they cannot yet earn their keep. A software interface that exists only because of a technology choice sits in OA as if it were an operational need.
Transitions are treated as if they empty the layer you left. They do not. Transitions carry selected content down. OA remains the operational story after you have a System Analysis. If you find yourself editing OA to record a software interface, you are on the wrong layer.
Logical and physical content get mixed in a single diagram. A physical node name replaces a logical component because you already know the vendor. The logical justification disappears, and with it the ability to change a realization without rewriting the need.
Numeric performance claims attach to elements that have not been placed yet. A number with no home is not a constraint. It is a rumor about a later layer.
Why do layers matter in the first place?
Three older crafts made the same bet: different questions get different drawings, and mixing them is how a review becomes an argument.
Geological stratigraphy, the science William Smith made practical in his early-nineteenth-century map of England and Wales, depends on not mixing layers. A fossil from one bed is not evidence about another. If you cannot say which stratum you are in, you are not yet interpreting the section. You are holding a bag of rocks.
Architectural drawing conventions make a related demand. A plan, a section, and a detail are not three decorations of the same idea. They answer different questions about the same building. A door swing does not belong on the structural section just because the sheet had room. If you cannot say which kind of drawing you are looking at, you cannot say whether the information is in the right place.
The OSI model, published in the early 1980s, made the same move for networks: seven layers, each with a job, each able to be reasoned about without pretending that a physical connector is a session protocol. You can argue about whether a given design got a boundary right. You cannot usefully argue about the design if the boundary was never named.
An Arcadia model is in the same position. A healthy model can be walked: an operational activity is supported by a system function, allocated to a logical component, realized on a physical component, and, when you reach EPBS, sits in an end product you can point to. That walk only works if each step still answers its own layer’s question.
What question does each of the five layers answer?
The wording below is a pocket phrasing of official Arcadia distinctions — the engineering data model, the user guide, and the Capella/Arcadia public method pages — so you can apply them at the desk. It is not a replacement for the method documents, and it is not a new method.
Operational Analysis answers: what does the operational world need to carry out, and who carries it out? You are looking at missions, operational entities and actors, capabilities, activities, processes, and scenarios — the stakeholder story.
System Analysis answers: what must the system as a whole do for that operational need? You are looking at system capabilities and functions, functional exchanges, the system boundary and actors at the system boundary, and system scenarios.
Logical Architecture answers: how is that system need structured into logical components, independent of a specific technology choice? You are looking at logical components, their functions and exchanges, logical interfaces, and allocations from the system functions.
Physical Architecture answers: how is that logical design realized in the physical and behavioral components you will actually field? You are looking at physical components in the method’s behavioral and host/node sense, deployments, physical interfaces, and the realization of the logical design.
EPBS, the end-product breakdown structure, or building strategy, answers: how does the physical design break into the end products you will build, buy, or integrate, and contract against? You are looking at a product breakdown of end-product components, used in support of component requirements, integration, and IVVQ. It is a later perspective, not a Day-1 OA concern. It is still one of the five official layers.
Read the layers top-down when you are discovering need, and use them as a set when you are reviewing.
What belongs, what transitions, and what stays?
This is the part of the kit the poster is built to keep in front of you during a review.
On Operational Analysis, what belongs is the operational need: entities, actors, missions, capabilities, activities, interactions, processes, scenarios, and operational constraints you can attach to those elements. What transitions toward SA is the need that the system will support — activities and capabilities that the system is expected to contribute to. What stays is the operational story itself; actors who remain actors in the environment; activities the organization performs whether or not any particular system exists.
On System Analysis, what belongs is the system as a black box at its boundary: system capabilities, system functions, functional exchanges, actors at the system boundary, system-level scenarios, and the first allocation of system function to operational need. What transitions toward LA are the functions and exchanges that logical components will have to take on. What stays is the system-level need statement. Do not start decomposing technology here.
On Logical Architecture, what belongs is a notional, typically technology-independent structure: logical components, allocated functions, logical interfaces and exchanges. What transitions toward PA is the logical structure to be realized. What stays is the logical justification of the architecture. A physical node name should not replace a logical component just because you already know the vendor.
On Physical Architecture, what belongs is the realization: physical components in the method’s behavioral and host/resource sense, their interfaces, and the way logical components are realized. What transitions toward EPBS is the design you will break into end products. What stays is the architectural realization itself, including behavior you still need to reason about at design level.
On EPBS, what belongs is the end-product breakdown: the items you build, buy, or integrate, and the contracts and IVVQ view that go with them. What stays behind on earlier layers is operational need, system need, and the logical and physical design you are breaking down. Skip this layer on a Day-1 OA increment.
How do you decide which layer you are on?
The pocket guide includes a decision table for the borderline cases that actually stall a session.
If you are thinking about who does this work today, in the organization or the environment, start on OA. If you are thinking about what mission or operational capability this supports, before any system boundary is drawn, start on OA. If you are thinking about what the system, as a whole, must do so that operational activity can still happen, or about what crosses the system boundary in system-function terms, start on SA. If you are thinking about how to structure the system into components without choosing a platform or product line yet, or about which logical component owns this function, start on LA. If you are thinking about how that logical component is realized on a host, a device, a process, or a deployed behavior, start on PA. If you are thinking about what you will actually procure, build, or integrate as an end item, start on EPBS.
Two borderline rows are worth keeping in your head. A software interface detail that only exists because of a technology choice is not OA, and usually not SA; start at LA or PA depending on whether the choice is still logical or already physical. A numeric performance claim about hardware you have not yet placed should not invent a number; if you have a real constraint, attach it at the layer where the element that carries the constraint lives.
A short review pass follows from the same table. Pick one operational capability and walk it down, as far as the model currently goes. At each layer, ask whether the element you are looking at still answers that layer’s question. If you cannot say which layer an element belongs to, it is not ready for a review, regardless of how finished the diagram looks.
The guide also includes a short fictional pointer, using the Northshore Ferry Dock story only as a reading aid, not as a complete model. OA is the dock crew announcing a weather hold to passengers. SA is the dock-operations support system providing a hold-indication function at the system boundary so that announcement can be timely and consistent. LA is a logical “hold management” component that owns that function, still without a vendor or a screen design. PA is the realization of that component on the dock-side equipment and operator stations you actually intend to field. EPBS is the end item you will buy or build for that station. If you find the screen layout in OA, the layering has already slipped.
What, exactly, is in the kit, and how do you use it in the first hour?
The zip is a 6-page pocket guide, a one-page printable poster, and a README. The guide covers the five layers, the decision table, a short review pass, and that fictional one-story walk down the layers. The poster puts the five layers, the question each answers, what belongs, and the goes-down / stays line on a single page you can keep open during a review.
Read the pocket guide through the five-layer table and the decision table. Print or keep open the poster. Pick one operational capability in a model you already have — or in the Day-1 increment from the Operational Analysis Day-1 Project — and walk it down the layers as far as the model currently goes. Remember the rule the poster states: transitions carry selected content down; they do not empty the layer you left.
How is this different from the Operational Analysis Day-1 Project?
Day-1 Project is how you scope, write, and build a first OA increment in Capella 7.1. This pocket guide is how you keep every element on the correct layer, including after that increment exists. They pair well. They are not the same product. Buying this guide does not also give you the Day-1 OA worksheets.
Capella is a trademark of Eclipse Foundation AISBL. Arcadia is the method Capella supports. This is an independent tool for people who use Eclipse Capella and the Arcadia method. It is not an official Eclipse, Capella, or Arcadia product, and it does not include the Capella application.
A reference you can actually put on the desk
You get the five official Arcadia layers, the question each one answers, a decision table for borderline cases, and a poster you can put on the desk during a review. That is a different job from building a first OA increment. If you have been asking “is this OA or SA?” in the middle of a session, this is the reference that question needs.
Read the pocket guide, keep the poster open in a review, and walk one capability down the layers. Get the Arcadia Layer Pocket Guide (for Eclipse Capella) and name the layer before you argue about the element.
The Arcadia Layer Pocket Guide is listed on our Tools for Eclipse Capella page, alongside the rest of the tools in that line. You can browse every Organa Obscura tool on the Products page.
Leave a Reply