Users act in Vista
Choose a function, fill in forms or work with tables; the browser only interacts with the workspace.
← Back to BENOVA
Early release package: Orbit · Vista · Aster
Modernize your backend one capability at a time.Preserve existing value. Create room for change.
NOVA aims to expand services on your existing backend, then transition individual capabilities when ready. Vista serves users, Orbit coordinates requests and is designed to work with many different existing systems, and Aster is an independent demonstration backend that does not use a running system; its implementation is being planned. Nexus, the build and operations toolkit, joins in a later phase.
- One unified workspace
- Gateways tailored to existing systems
- Build on existing backend value
- Adopt and evaluate step by step
Model overview
A clear path from the user to the backend.
Orbit adapts how application requests are received and is designed to work with many different existing systems. Vista provides the workspace for incremental modernization (Strangler Fig). Aster is an independent demonstration backend that does not use a running system. Nexus build and operations tools belong to a later phase.
Request flow
Four steps of a request.
How a request moves through the model.
The Gateway forwards securely
The server-side connection layer receives actions from Vista and forwards requests to Orbit under the agreed security configuration.
Orbit verifies and runs the flow
Validate the token, accept the request into a bounded queue and run the matching business flow.
The existing backend handles the work
Orbit passes the request to the existing backend (or to Aster in demos), receives and checks the result, then returns a screen or data to Vista.
Components
One responsibility per component
The early-release package has three components, each with its own role and able to change independently.
Vista — one unified workspace
Menus, tabs, tables and forms in one working interface, so users can move between business functions without relearning how to work.
Secure sign-in sessions
The design keeps connection credentials on the server, separate from the user interface. Authentication and session requirements are agreed during integration.
Orbit — customizable connection gateways
Customizable ingress gateways adapt to existing application calls and data formats. They share business orchestration, with the aim of limiting changes to connected systems.
Coordinated business flows
Flows coordinate business steps with time limits, cancellation and load control. Each change is tested against its backend and intended scope of use.
Aster — independent demo backend
An independent demonstration backend that lets the working flow be shown without using a running system. Aster is being planned for implementation.
Demonstrations apart from live systems
Lets the flow from Vista through Orbit be shown without touching a running system. Evaluation on a real backend still needs compatibility review and an agreed test scope.
Value and status
Intended value and current readiness.
VALUE
Modernize incrementally and preserve business value
NOVA aims to improve the user experience and expand services while establishing a path to transition individual capabilities. Each step needs verification of correctness, performance and operational requirements; the backend owns business permissions and rules.
- Change each layer independently
- Customize connection gateways to preserve existing integrations
- Clear boundaries between presentation, coordination and business logic
CURRENT STATUS
Being completed for release
Integration across NOVA components is being completed. NOVA is not yet a generally deployable release.
- Orbit: webservice runtime running; shared HTTP/JSON gateway in progress.
- Vista: application shell in use; sign-in and Orbit integration in progress.
- Aster: an independent demonstration backend; implementation is being planned.
Assessment scope depends on actual readiness. Nexus, Echelon and Aira are peer components in a later phase.
When it fits
Start with one business function.
Worth evaluating when the business wants to expand services on the existing backend and prepare an incremental modernization path.
ASSESSMENT SCOPE
Choose one business function and take it end to end.
Choose one function from the workspace to the backend. Compare it with the current system against agreed criteria before choosing the next step.
Common deployment questions- A modern, consistent workspace across several business functions
- Preserve existing application connections through customizable gateways
- Expand first, then transition selected capabilities based on verified results
- Session, timeout and load control in one coordination layer
Deployment questions
What needs to be clear before deployment.
Do we need to replace the entire backend at the outset?
You can begin by letting Orbit work with existing programs and data after checking compatibility. The direction is to expand services, then transition individual capabilities when ready; each change needs its own scope and testing.
Does Vista replace the current interface immediately?
Not necessarily. Start with one group of functions and run it alongside the current interface.
How is Orbit different from a typical API gateway?
Orbit combines customizable connection gateways with shared business orchestration, session management, timeouts and load control. A suitable gateway can preserve existing client calls and data formats; compatibility is verified before adoption.
What is Aster?
Orbit is designed to work with many different existing systems. A live system cannot always be used for demonstrations, so Aster was created as an independent demonstration backend. Aster is a separate item within NOVA and its implementation is being planned; having Orbit work with a real backend needs compatibility review and an agreed test scope before deployment.
Does the demo run on my real system?
The demo is intended to use a demonstration backend (Aster) to illustrate processing separately from your running system. Evaluation on a real backend requires compatibility review, a connection profile and an agreed test scope.
What happens when a transaction outcome is unclear?
The system stops and reports clearly; it does not replay the transaction automatically. Operations reconcile through the agreed process. A timeout does not mean the transaction was rolled back.
What is needed to deploy?
A compatible business backend, servers for Orbit and the Gateway inside the internal network, and acceptance criteria. Versions, security and capacity are agreed per deployment; Orbit is not exposed directly to the internet.
Where does Nexus fit in the model?
Nexus is a later-phase component. Its build, environment and test-data tools have been used in real environments on their own, and the integrated NOVA experience belongs to a later phase. Evaluating the early-release package does not depend on it.
Where does Echelon fit in the model?
Echelon is a peer component in a later phase. Vista connects to Orbit; Echelon adds orchestration when a flow needs task sharing across multiple agents, load balancing or per-step error handling.
Define an assessment scope with NOVA.
Share a capability to improve and the connections to preserve. Agree on a baseline, acceptance criteria and requirements for the next delivery step.