Engineering / Before and beyond code
Design it. Build it. Make the parts work together.
We take a practical need from the first conversation through design, prototyping, development, testing and deployment.
Conceptual design study / 01
02 / Conceptual engineering study
From a practical need to a working system.
See how a team’s needs become a system design that people can use, support and improve.
01 / Recognize
We need a new system.
Start with the work people need to do. A new application needs to fit the people, processes and systems already in place.
02 / Connect
Disconnected requirements become gaps in the design.
A missed handoff, an unclear data owner, or an unsupported interface can leave people doing the connecting by hand.
Understand the need
Requirements / choose a topic
The questions behind the need.
new system.
Selected context / Users
Who needs to act?
Who does the work? Understand their decisions, access needs, and the situations in which they use the system.
Design the system
Architecture / select a responsibility
Define the parts and how they connect.
These needs shape different parts of the design. Access and support affect the whole system; the diagram shows related responsibilities, not a sequence of steps.
Application
Define what the application should do.
Application rules determine how requests are handled, how data is used and when other systems are contacted.
Connections / compare the exchange
Same need.
Different engineering choices.
An existing business system must exchange information with a new application. The right connection depends on what the applications need to do and which interfaces they support.
API integration
Sample update U-204 includes request R-204, its review status and the person responsible for the next step. The application sends it to the existing system and handles either its response or an unavailable service.
- Application request
- Defined API
- System response
- Useful when
- One application needs an immediate response from another, and a suitable API is available.
- Considerations
- Agree on the request and response format, access permissions and what happens if the service is unavailable or too slow. The sending application depends on that service for a response.
Deliver and evolve
A design conversation, illustrated. This example brings requirements, system design, integration and support together. It illustrates an approach rather than a real client’s system.
Delivered client work
A public-sector system in operation.
iBi Nexus designed and deployed the Washington State Department of Commerce Solicitation Management System to support solicitations and requests for proposals and other information.
Explore the Commerce project →A project of our own
See how we built this website with AI.
We built this website with AI assistance and hands-on engineering. Our team shaped the design, reviewed the code and tested the interactive examples before deploying it to production.
See how this website was built →05 / Through implementation and beyond
Deployment opens the next chapter.
Engineering continues after deployment. What people learn from using the system helps guide the next improvement.
- 01
Discover
Understand the users, tasks, information and limits.
- 02
Architect
Design the system and its connections, including access and support.
- 03
Prototype
Prototype the uncertain interface or exchange before full implementation.
- 04
Build
Implement the application, rules, data and integrations.
- 05
Validate
Test how the system works and prepare it for deployment and handover.
- 06
Operate / Evolve
Observe real use and guide the next change.
Continue the design
Tell us what needs to change and what it needs to work with.
Start with the work you want to change, the systems it touches, and the constraints it must respect.
Discuss your project