What an architect decides
The architect designs the shape of the solution: how entities and subsidiaries are structured, how the chart of accounts and segments carry analysis, how items and inventory are modeled, how integrations exchange data, and where custom development is justified. They also set standards for naming, documentation, and environments, so that the system remains understandable as it grows.
- Entity structure, currencies, and consolidation approach.
- Data model: accounts, segments, items, and customers.
- Integration architecture and data ownership.
- Boundaries between configuration, workflow, and code.
How the role differs from a consultant and an administrator
A functional consultant configures the system to the design, and an administrator keeps it running after go-live. The architect sets the design those people work within. On small projects one person may carry several of these roles, but the thinking differs: the architect looks at the whole and the long term, the consultant at the task in front of them, and the administrator at day-to-day operation.
Managed and advisory services →When a project needs an architect
Simple, single-entity implementations on standard processes may not need a dedicated architect, as the lead consultant can cover design. More complex projects benefit greatly: multiple entities or currencies, intricate inventory or revenue recognition, heavy integration, industry-specific needs, or a migration from a complex legacy system. Where mistakes would be expensive to unwind, the cost of an architect is small in comparison.
Skills and judgment
Technical depth in NetSuite is essential, but judgment matters more: knowing when to use standard features, when to extend, and when to say no. Good architects explain trade-offs in plain language, document decisions and their reasons, and listen to the business. They have seen projects succeed and fail and can recognize patterns early. Ask candidates to describe a design decision they got wrong and what they learned.
Our NetSuite ERP practice →Governance: how architecture stays intact
A design that is sound at go-live can erode over years of small changes. The architect or a successor should review significant changes against the design, keep documentation current, and maintain an inventory of customizations. An architecture review before major additions, such as a new subsidiary or integration, prevents accidental damage to the foundation.
Decisions to settle before you engage one
- Scope. Decide whether the architect covers design only or oversees delivery.
- Authority. Define their power to approve or reject design changes.
- Involvement over time. Plan how they remain involved after go-live for major changes.
- Documentation. Require that the design and its reasoning are written down.
A realistic first 90 days
- Days 1 to 30. Understand the business, gather requirements, and draft the high-level design with options and trade-offs.
- Days 31 to 60. Validate the design with stakeholders, define standards, and review early configuration.
- Days 61 to 90. Oversee integrations and data design, and confirm the design with a prototype of the critical flows.
Pitfalls to avoid
- Skipping architecture on complex projects. Late redesign is far more expensive than early thought.
- An architect without the business. A design that ignores how people actually work will fail in use.
- Undocumented decisions. Without a record, the reasoning is lost when people move on.
- Overengineering. Simple designs that meet the need are better than elaborate ones.
