Stop generating static diagrams. Start coding your architecture.
Elan8 is the first Architecture-as-Code environment built for the unique challenges of hardware-software integration. Define your system in code, manage it in Git, and keep your documentation, interfaces and constraints in sync automatically.
Built by a system architect
ICD generated from the model, not from Word
Engineer-first, not process-heavy
More than a drawing tool
Elan8 is a logic engine that understands what an interface is. Define components, connections, and constraints — validation is built in.
// Elan8 — autonomous rover (excerpt from demo)
interface LidarScanIF logical { role publisher; role subscriber }
part LidarSensor {
port ethernet_data: Ethernet
port power_5v: Power5V
port scan: LidarScanIF
bind scan to ethernet_data
}
part ComputeBoard {
port ethernet: Ethernet
port power_5v_in: Power5V
part mcu: SBC
part perception: PerceptionSW
part navigation: NavigationSW
bind perception.lidar_scan to mcu.ethernet
connect navigation.lidar_scan to perception.scan_out
deploy perception to mcu
deploy navigation to mcu
}
part autonomous_rover {
part lidar: LidarSensor
part compute_board: ComputeBoard
part power_supply: PowerSupply
connect power_supply.power_5v_out to compute_board.power_5v_in
connect power_supply.power_5v_out to lidar.power_5v
connect compute_board.ethernet to lidar.ethernet_data
}Auto-visualisation
Generate C4 or SysML-style diagrams directly from your commits.
Version control
Architecture in Git. Review changes like code and keep branches in sync with the rest of your repo.
Single source of truth
Your code is your documentation. No more outdated PDFs in SharePoint.
Is ‘Final_Architecture_v3_USE_THIS_ONE.pdf’ still the truth in your team? We didn’t think so.
Why system architecture breaks down in practice
Architecture lives in documents
Architecture diagrams sit in documents, separate from code. When engineers need to understand the system, they read code, not documents.
Interfaces are implicit
Contracts between components are often only in comments or not documented at all. That's why ICDs in Word or Excel quickly go out of date. When someone changes an interface, there's no way to know what breaks downstream.
Models become outdated
As products evolve, architecture documents fall behind. They become historical artifacts rather than living specifications.
Engineers stop trusting architecture
When documentation doesn't match reality, engineers stop consulting it. They rely on code reviews and tribal knowledge instead.
Make architecture explicit, versionable, and checkable
Architecture as Code makes your architecture the single source of truth. The ICD — and diagrams, ADD — are generated from it, so they stay in sync.
Architecture as Code (DSL)
Text-based, versioned in Git, and readable by both humans and tools. Architecture becomes part of your codebase.
Interfaces as first-class concepts
Explicitly define interfaces between components — so your ICD is always consistent. When interfaces change, you can see the impact immediately.
Multidisciplinary by design
Model software, electronics, and mechanical systems together. One architecture, multiple domains.
Git-based workflows
Architecture changes go through the same review process as code. Architecture evolves with the product.
Who It's For
Complex products
For teams building systems with multiple components, interfaces, and dependencies.
Multiple disciplines
When software, electronics, and mechanical engineering need to work together. Your ICD captures HW/SW interfaces in one place.
Long lifecycles
For products that evolve over years, where architecture must remain accurate and trusted.