Looking to Learn How Architects Think About ServiceNow Solutions

[pgvaishnav]

Hey everyone!

I’m reaching out to all the ServiceNow Architects, Solution Architects, and Solution Designers in the community. I’d really love to learn from your experience and understand something that I feel is often missed when we’re focused mainly on development.

As developers, we usually get a Jira story or requirement that says "Build this" or "Configure that" — and then we start thinking about how to implement it in ServiceNow.

But what I’m really curious about is… how did we get to that solution in the first place? 🤔

For example, imagine a business comes to you with a problem. How do you:

• Understand the actual business problem behind the requirement?
• Identify what the business really needs versus what they're asking for?
• Decide whether ServiceNow is the right solution?
• Explore different approaches and choose the best one?
• Decide between OOTB functionality, configuration, customization, or integration?
• Design the overall solution?
• And finally, how does that solution get broken down into epics, stories, and tasks for developers?

I would love to hear some real-world examples from your experience.

For example, you could share a business problem you encountered, how you approached it, what solution you designed in ServiceNow, what challenges you faced, and how the final solution was broken down for the development team (without sharing any confidential information, of course).

If you could go back to when you had 3–5 years of ServiceNow experience, what would you tell your younger self to learn or focus on to become a better solution architect?

Would really appreciate any experiences, examples, advice, or even resources you can share. I’m genuinely trying to learn how to think beyond the Jira story and understand the bigger picture of solution design.

Thanks in advance! 🙌

[Tanushree Maiti]

Hi @pgvaishnav 

As an seasoned Architect, I do not evaluate requirements based only on whether they can be implemented. I evaluate whether they should be implemented based on business value, platform best practices, and long-term sustainability.

1. Understand the Real Business Problem

• Ask probing questions to identify the actual pain point rather than accepting the requested solution.
• Determine whether the objective is to reduce manual effort, improve user experience, meet a compliance requirement, or solve another underlying business challenge.
• Quantify the expected business value in terms of time savings, productivity, risk reduction, cost savings, or customer impact.

Guiding question: What business problem are we trying to solve?

2. Validate Business Value

• Assess how many users, business units, or processes will benefit.
• Compare the implementation effort against the expected return.
• If the requirement benefits only a single user or addresses an isolated preference without measurable business value, it is generally not recommended and may be rejected during the feasibility assessment.

Guiding question: Does the benefit justify the investment?

3. Prefer Out-of-the-Box (OOB) Capabilities

• Always explore whether the requirement can be fulfilled using standard ServiceNow capabilities before considering customization.
• Use standard tables, workflows, UI components, and platform features wherever possible.
• Minimize customizations to reduce technical debt, simplify upgrades, and improve maintainability.

Principle: Configure before you customize.

4. Evaluate Multiple Solution Options

For every significant requirement, brainstorm at least two or three possible approaches and evaluate each based on:

• Implementation speed
• Development complexity
• Licensing impact
• Total cost of ownership
• Long-term maintenance
• Scalability
• Upgrade compatibility

Select the option that provides the best balance between business value and technical sustainability.

5. Use Integrations Instead of Data Duplication

• Identify the system that owns the data.
• If another enterprise application is the source of truth, integrate with it rather than duplicating data inside ServiceNow.
• Prefer IntegrationHub, certified spokes, REST APIs, or event-driven integrations over custom point-to-point solutions.

Principle: Keep data where it belongs.

6. Assess the Impact on the Existing Platform

Before approving any solution, evaluate its impact on:

• Existing business processes
• Current customizations
• Performance
• Security
• Compliance
• Reporting and analytics
• Integrations
• Upgradeability
• User experience

Perform an impact analysis to ensure the new requirement does not introduce regressions or unnecessary complexity.

7. Think Beyond Today's Requirement

Every implementation should support future growth.
Consider:

• Reusability
• Extensibility
• Scalability
• Governance
• Operational support
• Documentation

Avoid solving today's problem in a way that creates tomorrow's technical debt.