Architecture Instances Integrations Data Flow Plan

Plan your architecture, instances,
integrations, and data flows

Plan your architecture, instances, integrations, and data
flows
The development of your architecture, instance strategy, and data strategy for the Now Platform ® need to be considered through a technical lens and to be driven by your business
context and objectives for transformation. Decisions you make with respect to key architecture question— like whether to pursue a multi- or single-instance approach—require
consideration first by relevant business considerations, both in terms of your current situation and future considerations that may affect your Now Platform expansion.
For the purpose of this document, “architecture” includes your Now Platform instance configuration and management, data architecture and configuration management, and integration
strategy, design, and management.
Insight: Plan your architecture, instances, integrations, and data flows

Start your technical planning with a clear view into your transformation objectives for the Now Platform and how these will shape key architecture decisions. Three questions are
essential to your technical planning and management:
1. What architectural/technical requirements need to be reflected in your planning so you can deliver on your business objectives for the Now Platform and/or the needs specific to
your organization.
2. What data requirements can be derived from your business objectives and/or organizational requirements? How should these be reflected in the design of your CMDB and
integration strategy?
3. How do you plan for expanding your Now Platform capabilities without disrupting effective management of your architecture?
Key implementation steps

Start Improve Optimize
5. Plan for expansion and
1. Develop a clear understanding 2. Define your instance and data 3. Define your integration 4. Manage your ServiceNow
development on the Now
of architectural needs architecture architecture architecture
Platform
2 © 2022 ServiceNow, Inc. All Rights Reserved.

Step 1a: Understand the out-of-the-box Now Platform
architecture
The Now Platform is designed as an enterprise cloud platform, providing the scalability, security, and availability needed for mission-critical applications. It helps create a single system
of record that maximizes the value of your enterprise data and enables custom application development. Before defining requirements, ensure that your core and extended technical teams
understand the architecture and functionality of the Now Platform.
Understand the Now Platform infrastructure Understand the Now Platform’s core features and functionality
 Learn about Now Platform’s cloud infrastructure. Ensure your teams:  Ensure your teams develop an understanding of the following features and functionality of the Now
 Review the overview of the ServiceNow ® Platform:
Advanced High Availability (AHA) architecture.  Capabilities – For example, Service Portal, Configuration Management Database (CMDB), Compliance,
 Build a deep understanding of the ServiceNow infrastructure, including etc.
its capabilities to scale horizontally, load balance, and failover when  Products – For example, IT Service Management, IT Operations Management, Security Operations,
necessary. Customer Service Management, HR Service Delivery, etc.
 Certified applications – Explore the ServiceNow Store.
 Learn how data is stored and managed in your ServiceNow instance.
 ServiceNow Store integration hub apps – For example, preconfigured integrations with Box and Splunk,
Refer to product documentation (of your instance release version) for and Okta.
an overview of how applications use tables and records to manage data
and processes on the Now Platform.  Ensure your teams are familiar with the Now Platform user interface including:
 Forms – Display information from one record in a data table.
 Lists – Display a set of records from a table.
 Available options to configure lists and forms.
Practitioner insight: The best way your team can build up its expertise on the  Ensure your teams know how business processes are triggered and completed on the Now Platform,
Now Platform’s core features and functionality is to start by taking the including:
ServiceNow Foundations eLearning course and then review  Business rules – Server-side scripts that runs when a record is displayed, inserted, updated, or deleted, or
ServiceNow Training and Certification courses for training and certification when a table is queried
opportunities.  Flow Designer – A Now Platform feature for automating processes, including integrations, in a single
design environment without coding
1. Develop a clear understanding 2. Define your instance and data 3. Define your integration 4. Manage your ServiceNow 5. Plan for expansion and
Steps
of architectural needs architecture architecture architecture development on the Now Platform

Step 1b: Identify the extended technical team you need
to work with
Your internal ServiceNow platform support team will be the primary team responsible for implementing, maintaining, and extending ServiceNow as a strategic business platform.
However, you’ll need to identify and work with enterprise IT teams that manage the systems and infrastructure environment in which your Now Platform will operate.
Identify the enterprise IT teams you’ll need to partner with to support the Now Provide an overview of Now Platform architecture and functionality to your
Platform enterprise IT partners, to find questions and requirements that may affect your
 Enterprise architecture (EA) – EA performs the analysis of business structure architectural decisions
and processes. EA may have been involved in evaluating the Now Platform and  You may conduct this as a planning workshop—be sure to include your
will help determine how it fits into your business and systems architecture. implementation partners. (Note: This may already be planned or conducted as part of
 Data architecture and technical integration – These teams define how different your onboarding process with ServiceNow.)
data entities and IT systems will store, consume, integrate, and manage data.  In addition to finding potential questions and requirements, you can use this workshop
They'll be an important resource as you integrate the Now Platform with other to identify points-of-contact within the teams listed previously, who can collectively
enterprise systems. act as your “extended” ServiceNow team. This should provide the basis for a RACI
 Security – Security is responsible for defining security requirements and protocols chart that defines “ownership” for key decisions and responsibilities between the core
ServiceNow team and enterprise IT functions.
for your environment.
 Network administration – This resource will help enable Now Platform access to
users (e.g., opening a network port for access, single sign-on, etc.) and help to
ensure appropriate network support. Practitioner insight: Technical planning needs to be coordinated with the development of
governance (e.g., for the establishment of documented technical standards). Work with the
 IT support – This resource supports the platform on a daily basis. IT support also ServiceNow governance lead and/or executive sponsor to coordinate governance policy
coordinates and supports patches, upgrades, defects, and enhancements. development with your ServiceNow architecture design process.
Practitioner insight: Your extended ServiceNow team may also include non-technical teams within your organization such as vendor management, legal, and procurement to assist with business-
related processes (e.g., purchasing instances, terms and conditions related to software licensing, etc.) involving the Now Platform.
Steps

Step 1c: Assess the impact of business
objectives/strategy on architecture requirements
Your business objectives and strategy—both for ServiceNow, as well as outside ServiceNow — may shape your architecture direction and planning process. For example, a business
strategy focused on mergers and acquisitions for growth may mean that your architecture will need to accommodate the integration of substantial new user bases (and/or data) during
the year, which may impact the choices you make about architecture and instance strategy.
Assess the potential impact your business objectives/strategy will have on Now Platform architecture requirements
Complete the following:
 Document business objectives and strategy considerations (both for ServiceNow and outside the scope of your ServiceNow implementation) that may impact your architecture
for the coming year (Note: You can do this as part of the planning workshop recommended in 1b). Ensure you review this with your executive sponsor to validate your
assumptions.
 For each objective/consideration, define potential implications or decisions that you may need to raise with enterprise architecture and other stakeholders. For example, a
corporate merger and acquisition strategy should prompt you to ask stakeholders whether your architecture will need to accommodate rapid integration of new user populations,
or whether the intent is to onboard new populations gradually.
 Validate these implications and decisions with your enterprise architecture team and strategic governance function for ServiceNow. Make sure that you make decisions on a
defined timeline so you’re able to advance the development of the requirements in your architecture planning.
Practitioner insight: Choosing an architecture is an important decision that sets the foundation for your implementation’s success. Refer to the Success Insight
A comparison of four complex ServiceNow architectural models for guidance.
Steps

Step 2a: Design your instance configuration and
management strategy
ServiceNow customers have access to their own instance with one or more separate application nodes and a database. As part of planning for your ServiceNow architecture,
determine where you want to host your ServiceNow instance(s), how many you will require based on your organizational need to separate data and processes, and how you will
protect your instances.
Identify requirements that will guide your cloud architecture*
 Work with your enterprise IT team (see step 1) to address the following questions:
 Will data sovereignty considerations influence your use of ServiceNow’s cloud infrastructure?
 What additional data security constraints will influence your use of ServiceNow’s cloud infrastructure?
 What regulatory guidelines do you have to follow that affect data storage and access?
 Do you need to provide one virtual view that shows tasks that reside in multiple instances?
 Identify specific requirements and constraints for cloud hosting with your ServiceNow implementation partner, based on the questions above
 Identify whether you will require any on-premises server infrastructure to run your ServiceNow instance(s). Note: We highly recommend using cloud infrastructure as your
preferred option, as maintaining on-premises infrastructure can be costly and does NOT include advanced features that ServiceNow has implemented to manage cloud
infrastructure.
Practitioner insight: You can choose to have a multi-instance strategy for your dev and test environment as well. Work with your technology development teams to understand their
development and testing processes to design a sub-production instance architecture.
*Refer to our Plan your platform architecture page on the Customer Success Center for more resources .
1. Develop a clear understanding of 2. Define your instance and data 3. Define your integration 4. Manage your ServiceNow 5. Plan for expansion and
Steps
architectural needs architecture architecture architecture development on the Now Platform

management strategy (Continued)
Identify requirements for process and data separation
 Your architecture and instance strategy will be strongly influenced by requirements for process and data separation. Identify requirements to separate data, administrative tasks,
processes, or reporting across different entities, customers, or sub-organizations within your organization. Work with your executive sponsor, enterprise IT, legal/compliance
functions, and key business stakeholders to answer the following questions:
 Do you need to enforce data separation between different entities within your organization due to regulation, data protection policies, or other business requirements?
 Do you need to preserve business process and user interface differentiation across business entities/
 Do you need to define policies to govern instance configuration and management (e.g., policies that govern how upgrades are done, how to right-size environments, replicate instances
correctly, develop a security access control model, and ensure proper maintenance)? If so, do the same policies apply to all instances? Or are separate policies needed for separate
instances?
 Do you anticipate variation in speed of process change/evolution across different functions or entities in your organization?
 Do you need a single virtual view that consolidates tasks from multiples instances in one view?
 Based on the answers to the above questions, work with your ServiceNow implementation partner to determine whether requirements should drive:
 Domain separation – This allows you to separate data, processes, and administrative tasks into logical groupings called domains. You can then control several aspects of this separation,
including which users can see and access data.
 A multi- vs. single-instance architecture – A separate instance provides complete and total separation of all system properties. Consider separate instances only if you don’t require global
reporting or global processes along with total separation of all system properties.
 Application scoping – Application scopes keep data separate, allowing for additional access controls and security. In addition, it offers delegated development.
 Access control list rules (ACL), business rules, or configurations – These let you vary your processes and preferences without separating data from the overall governance or
administrative tasks. Examples are custom views and form layout.
 Global queue – Using this queue helps you create a single virtual view of the tasks in multiple instances. This is also known as a mesh architecture.
Steps

management strategy (Continued)
Capture your instance security requirements
 Work with your global data and network security team, along with your ServiceNow implementation partner, to incorporate the following security considerations* in your
instance design. These considerations should be accounted for in each instance. For example, a developer may have admin access in a development instance but should not have
it in a production instance:
 Input validation – Minimize malformed data from entering the system in the form of input data, whether obtained from the user, infrastructure, external entities, or database systems.
 Access control – Define what functionality and data the user may access, ensuring the proper allocation of access rights after authentication is successful.
 Authorization – Allow resource access only to those permitted to use them.
 Authentication – Put in controls to verify that an individual, entity, or website is who it claims to be.
 Attachments – Many ServiceNow applications’ business processes allow for the upload of data/information. Include business logic to scan for files during the upload process and reject
those perceived as malicious. (Note: ServiceNow regularly checks the validity and security of text, but accepting files can introduce even more risk.)
 Session management – Put controls in place to govern the state of interactions between a user and a web-based application.
 Email security – Control which inbound messages are accepted and from whom, encrypt the transmission of outbound messages, and scan the contents of any attachments for malicious
content.
 Encryption – Configure your Edge Encryption for applications hosted in your environment, use platform encryption to manage how supported fields are encrypted and decrypted, and
implement database encryption at rest to protect your data even while not in use.
 System logs – Create a logging and auditing plan so you can identify and act on suspicious activity in a timely manner.
 ServiceNow Management, Instrumentation and Discovery (MID) Server security – MID server is a lightweight Java application that runs as a Windows service or UNIX daemon on
standard hardware, including virtual machines. Determine which of the servers located within your organization are used for this purpose and what security considerations you require to
govern it.
 Maintain an Instance Security Center to track compliance effectiveness of your instance security controls, monitor security event monitoring metrics, and configure and
maintain instance security settings.
*Refer to the Instance Hardening Guide for more information and guidance on making your
instance more secure and resistant to malicious intrusion.
Steps

Step 2b: Define your configuration management
strategy
The Configuration Management Database (CMDB) provides a single source of truth to support ServiceNow capabilities and provide data to support strategic, tactical, and
situational decisions. While ServiceNow recommends an early implementation of the CMDB capability, you should be careful to ensure that the CMDB is appropriately scoped to
support your business objectives and focuses on the data required to support those objectives. Also, consider a phased approach as trying to do a complete CMDB implementation
all at once can be overwhelming.
Determine your CMDB requirements*
 Identify a list of CMDB use cases that directly impact your organization’s key strategic initiatives. These use cases will help you make the case for effective configuration
management and get required funding and support for implementation. Below are examples of questions you could use to identify CMDB use cases:
 What level of understanding do we need of our infrastructure configuration to assess the impact of an incident on business services*?
 What level of understanding do we need of our infrastructure configuration to assess the potential risk of a component-level change?
 What level of detail of cloud services is needed to monitor the performance of our business services?
 What level of understanding do we need of our infrastructure assets for better financial tracking and management?
 Define clear configuration management goals, objectives, and outcomes. Document: Practitioner insight: Build your
 What you want to accomplish with configuration management, per the use cases outlined above. configuration management team and
data model early, to set the foundation
 How you will approach your implementation, as well as your assumptions and constraints. for configuration to support other
 What business outcomes this will support. applications long term. See
 How will you know if you’re doing it right, i.e., the measures of success you’re going to use. ServiceNow’s Success Playbook for
more information on
planning a successful CMDB deploymen
t
*Consider using CSDM (ServiceNow’s Common Services Data Model) to map your IT services. Following this model ensures that the .
data for your application maps correctly to the appropriate tables
Steps

strategy (Continued)
Determine your CMDB requirements (Continued) Design the CMDB
 Scope the requirements for your CMDB. Use the below  Work with your ServiceNow implementation partner and configuration manager to design a foundational
questions as a guide: CMDB based on your organizational needs. Complete the following tasks, using requirements derived from
 What environments will configuration management oversee the questions to the left as a guide:
(e.g., production, development, test, etc.)?  Design the CMDB data model – Class/sub-class structure, which are typically aligned to technology domains:
 Which CIs in the CMDB need to be managed at the server, network, database, application, storage, etc.
relationship level and which CIs require only inventory-level  Identify the required content for each class/sub-class – Attributes including class-level inheritance and required
management? relationships
 What IT services will be included?  Establish the configuration item (CI) naming conventions/standards
 Are there geographic considerations to account for?  Determine data ownership
 Are there regulatory or compliance requirements that must be  Define the data security requirements
met?
 Identify the data sources and determine the mechanism(s) you will use to import data into the CMDB
 Are there specific levels of control required for traceability (discovered, automated, and/or manual)
and auditability?
 Validate and get approval for your CMDB design from your key stakeholders including representatives
 What security issues must be addressed? from key functions who depend on CMDB data, the configuration management team, and data architects, if
 Are interfaces to internal and external service providers any.
required?
Practitioner insight: Just like any other new IT implementation, a successful configuration management
implementation requires cultural change. Consider creating a comprehensive communication plan for your CMDB
implementation, highlighting CMDB needs and value, in term of “what’s in it for me,” progress against key
milestones, and success stories. Coordinate this communication with any ongoing and/or
planned organizational change management efforts.
Steps

strategy (Continued)
Define the CMDB control structure
 Create a configuration management plan that accounts for the following activities to ensure proper controls are established.
 Define the process and procedures for creating new, modifying and retiring CIs. They should be retired rather than deleted to preserve any relationships that the CI has to other records in
the CMDB.
 Establish integration with the change management process.
 Define the process and procedures for Discovery reconciliation if used.
 Define the process and procedures for CMDB verification and audit.
 Identify the configuration management and CMDB key performance indicators (KPIs), and establish measurement procedures and a reporting schedule.
 Use the CMDB health dashboard to monitor and maintain your CMDB health.
 Create a roadmap for continual CMDB expansion and configuration management process improvement.
Practitioner insight: Your ability to deliver on many critical capabilities, such as incident management or change management, depends on having a robust single system of record. Instead of
delaying your CMDB implementation, aim for a minimum viable product that includes the “right” amount of configuration management. Avoid a big bang approach to configuration
management. Most organizations that try that approach get bogged down and may not ever manage to implement a CMDB.
Steps

Step 3a: Determine the requirements for effective
integrations
Many ServiceNow customers obtain additional value by integrating with third-party applications. The most common third-party integrations are with: CMDB, Incident
Management, Problem Management, Change Management, User Administration, and Single Sign-on. You can use a variety of methods, but be prepared to meticulously gather
requirements to design and develop effective integrations. See our Implement integrations with ServiceNow Success Checklist for additional information.
Tie your integration strategy to your business objectives

 Challenge your current practice. Do not simply replicate existing integrations. Review your updated business objectives to make sure integrations directly contribute to the success
of those objectives.
 Look for opportunities to improve or simplify existing processes. Look for unnecessary steps that can be eliminated.
 Revisit your integration strategy regularly to be more responsive to business needs and objectives. Embrace change by being lean and agile.
Create a list of potential integrations based on your current ServiceNow implementation
 Consider the following categories:

 Engagement channels (e.g., email, social media, collaboration)
 Foundational data (e.g., your customer's users or locations in another system so they can be referenced when the customer raises a ticket on your system)
 CMDB CI data (e.g., servers, applications, services, network equipment, cloud infrastructure)
 Application data (e.g., HR data from an HR system, vulnerability data from a security application)
 ServiceNow-to-ServiceNow integration across instances
Consult with your enterprise architecture and security teams to define integration requirements
 Document current integrations, integration tools, and organization standards.
 Coordinate integration and architecture requirements—tables, fields, and data relationships.
Steps

Step 3a: Determine the requirements for effective
integrations (Continued)
Understand ServiceNow integration technologies Gather additional must-have information about each proposed ServiceNow
integration to ensure an effective and accurate design
 Web services  REST and SOAP (REST is  How does this data support the process? Is the data truly necessary for the new
 File retrieval/import sets recommended) process in ServiceNow?
 JDBC connections  Excel, CSV, and email
 LDAP  MID Server – API and command line  How frequently should data be transferred?
integrations
 What is the volume? What are the estimated number of transactions and size of the
data?
Determine what data elements are needed to support ServiceNow business
processes  What are the triggers for the process?
 Identify foundational data from external systems that needs to be in place, both Capture remote system capabilities to understand integration design constraints
initially and ongoing.  What is the target system?
 Determine what data needs to be transferred to and from ServiceNow, and whether  What data is available? In what format? Can fields be mapped easily?
translation is required at either end.  Can you show a sample?
 Identify the system of truth for each data element.  What is the data quality like?
 What protocols are available?
Identify the process events that will trigger an exchange of data between systems
 Who is the owner? And who makes the decisions?
 This could be events—such as creating an incident or assigning it to a particular
group—when certain fields such as Priority are changed, when a work note is
added, etc.
Steps

Step 3b: Design effective integrations
Customers have many technologies and methods to manage integrations between ServiceNow and external systems. Always look for configuration options first, starting with
ServiceNow-supported integrations or those available on the ServiceNow Store. If you need custom integrations, contact your ServiceNow account team or build your own
integration using the platform’s integration capabilities. Check with your ServiceNow account representative about licensing.
Select the best ServiceNow integration from the options below, listed in order from the most supportable to those that provide the most flexibility/choice
 ServiceNow Store integrations – These integrations are built by ServiceNow or a partner that’s an expert in the external system. The seller of the integration will generally provide
implementation and ongoing support. There may be cost associated with the integration.
 IntegrationHub – IntegrationHub lets you integrate third-party APIs as part of a flow when a specific event happens in ServiceNow. These integrations, referred to as spokes, are
easy to configure with Flow Designer and help you quickly add powerful actions without writing a script. There may be a cost associated with the spokes and/or licensing of Flow
Designer in order to enable IntegrationHub.
 Note: Not all integrations on the ServiceNow Store will be spokes compatible with IntegrationHub. Use the IntegrationHub filter when in the ServiceNow Store to filter
integrations specifically designed for use with IntegrationHub.
 Custom – Custom integrations (REST, SOAP, IoT devices, file import and export abilities via CSV or XML, Flow Designer with IntegrationHub) meet a specific customer use
case, are designed from scratch, and are owned and maintained by the customer long term.
For custom interfaces, determine the following for each interface:
 Message structures, response formats, and exception actions (e.g., validation fails, message timeouts)
 Rules around ownership of records and what updates can be made by the non-owning party (Note: Allowing both sides of an integration to update any field at any point can cause
issues, so we normally advise that non-owners should only add journal fields, such as comments and work notes.)
Steps

Step 3b: Design effective integrations (Continued)
Follow these best practices when you create integrations:
Practitioner insight: Use as much out-of-the-box functionality as possible in the initial
 Integrations come in two halves—one for each system. Make sure your resources deployment, unless it’s absolutely critical to build a custom integration. Otherwise, avoid
have the necessary expertise to implement their half. customized integration until the platform is adopted and your process users trust it.
ServiceNow provides several interfaces that let you directly integrate with the platform.
 Define business rules to extract only relevant data from source systems and don’t These interfaces are considered part of the platform and are provided at no additional charge.
pull in more data than you need. Validate which data is transmitted with your You can find list of supported integration interfaces in the ServiceNow product
executive sponsor and business owners to make sure you’re capturing the data documentation.
necessary to achieve your end goal.
 Execute large integration loads after hours or during a non-peak time of day to
minimize performance impact to your systems.
Practitioner insight: Customers engaged in enterprise services transformation will see more
 Use out-of-the-box features and functions as the baseline, especially the demands for cross-platform integration, but this doesn’t necessarily have to lead to complex,
ServiceNow API. customized integration. ServiceNow’s IntegrationHub reduces the need for complex,
custom-coded integrations because you can execute third-party REST APIs as part of a
 Use IntegrationHub (requires a separate subscription) for designing custom workflow when a specific event occurs in ServiceNow. IntegrationHub supports three use
integrations. IntegrationHub extends the ServiceNow Flow Designer to incorporate cases, reducing the need for custom code:
integrations into automated processes. • Third-party REST API integrations – Customers can post messages and ServiceNow
incident, problem, and change record details to collaboration channels like HipChat,
 Work with a certified partner when you build custom integrations unless you have Slack, or Microsoft Teams.
strong, ServiceNow-specific integration expertise within your organization. The right • Integrations between ServiceNow instances – IntegrationHub provides an easy-to-
expertise can dramatically simplify work and even reduce total investment (by configure spoke allowing data synchronization across multiple ServiceNow instances.
reducing the need for rework). • Creating REST actions – IntegrationHub supports developing custom REST web service
actions to support API development for web-based applications.
 Consider our internal, customer, and partner learnings when you design your
integration.
Steps

Step 3c: Maintain CMDB integrity
While ServiceNow Discovery and Service Mapping are the preferred methods to populate the CMDB, they’re not the only methods. For various reasons, users may need to populate
the CMDB from a custom, external data source and want to populate it automatically. Fortunately, ServiceNow provides the facilities to do this:
CMDB Identification and Reconciliation. For a great explanation on how this works, check out the Community Forum article on populating related CIs into the ServiceNow CMDB
.
Use CMDB Identification and Reconciliation-enabled integration methods when creating CIs in the CMDB
 Create the integration in a scoped application. Identification engine APIs are accessible in scoped apps. Activate the Configuration Management for Scoped Apps (CMDB)
plugin.
 Always include the CI’s unique identifier.
 When inserting CIs with JavaScript code, use the internal ServiceNow function IdentificationEngineScriptableApi.createOrUpdateCI. This will confirm that any inserts or
updates use the Identification and Reconciliation Engine.
Steps

Step 4a: Develop a robust migration plan as you move
toward production
Proper management of your Now Platform architecture is key to good performance and helps ensure that required upgrades are implemented with little to no disruption to the
business. Ensuring top performance of your architecture will demonstrate to users that the Now Platform user experience is second to none.
As you implement (and upgrade) your Now Platform, ensure that configurations and data are migrated and promoted through your ServiceNow environments via our recommended
steps. During the development phase, keep a runbook to document the steps that need to be taken when migrating the data and promoting update sets. A runbook is a set of defined
procedures developed by the administrator for various tasks such as migration plans, daily procedures, and handling exceptional incidents or tasks.
Develop and maintain your runbook
 Document the following information:

 Update sets – Keep the number of items in an update set low. A low number of items makes it easier to manage and review. Update sets should also be ordered so that when they’re being
committed, you avoid any collisions. In larger development implementations, consider establishing a role to have the workstreams and update sets managed to avoid development collisions.
Conversely if update sets need to be backed out for some reason, it should be done in REVERSE order in which they were applied.
 Data migration – Any data that needs to be migrated can be done by using the system import functionality or by exporting/importing via XML. This is another opportunity to use your
runbook, making note of all data that needs to be migrated.
 Integrations – Ensure that all integrations work as expected in the other sub-production instance. Note: licensing may be an issue with some third-party integrations; if this is the case, make
sure that there is a test plan for the integration when it is implemented in the production instance.
 Instance promotion order – The recommended approach for an implementation is to begin in a development instance, then migrate to sub-production, and then to the production instance.
Steps

Step 4b: Develop an instance maintenance plan
Having a maintenance plan is key to making sure that system performance adheres to the desired service levels. The following tasks should be part of your maintenance plan, which
should be documented and reviewed with your technical governance team.
Create your instance maintenance plan
 Set a cadence for reviewing system logs. Reviewing system logs on a frequent basis is a proactive way to catch any performance issues.
 Set a cadence to test your instance. A system administrator should go through core system functionality to verify system usability and performance. Navigating through forms and
lists to check page load times, form rendering, field data entry, etc. will let you know if there are any potential issues with system configuration, internal network, or browser
performance. Consider engaging ServiceNow for a HealthScan to better understand the health of your instance.
 Ensure timely review of release notes. ServiceNow may release patches to address issues. It’s critical to review release notes for these regularly, as well as for planned upgrades.
 Ensure timely review of ServiceNow-scheduled maintenance notifications. There are periodic maintenance activities that ServiceNow executes on its systems (databases,
application infrastructure). Notifications are sent with all the details you need, including support details. It is important to review notifications and understand the support process
if any issues arise.
Steps

Step 4c: Develop an upgrade plan
Treat upgrading a ServiceNow environment as a major project that requires detailed planning, execution, and validation. Your upgrade plan should include the steps listed here.
Access our upgrade planning checklist for a comprehensive list of activities.
Gather relevant information about upcoming ServiceNow releases Gather relevant information about your ServiceNow environment
 Build awareness about new features and develop an understanding of how to  Confirm your instance hosting model, the instances in scope for upgrade, and the
incorporate these features into your environment. upgrade features you plan to enable or disable.
 Review updated product documentation which includes the new release notes by  Identify a core team of testers, power users, and key stakeholders to validate
version. functionality before and after you upgrade.
 Attend the new release broadcast (ask your account manager for details).  Create a comprehensive test plan, including test cases for all core instance
functionality and integrations, your testing scope and approach, your method for
 Attend ServiceNow Knowledge or Now at Work user conferences which provide tracking defects, and the availability and restrictions of the systems required for
release learning opportunities and insights into the product roadmap. integration testing.
 Join the ServiceNow Developer Program which provides resources to learn, build,  Develop a high-level implementation plan covering sequence and timing to
and deploy applications on the Now Platform and offers resources (e.g., technical upgrade production and non-production instances (including any change freeze
library, online training, developer community, etc.) to ensure a successful windows which may affect timing), instances to be cloned, and the instance to be
application-building experience. used for integration testing.
 Become a Now Creator and explore Now Learning to continue your education.  Define and document a process to review and update supporting documentation,
including training material and knowledge base articles.
Steps

Step 4d: Develop a standard process for cloning to
support upgrades and other changes
The System Clone application allows you to copy data from your production instance to your non-production instance to replicate your production environment as closely as
possible. By cloning, you can develop and test changes before implementing them into your production instance. For ServiceNow Express customers, System Clone becomes
available once the ServiceNow Express High Availability Cloning plugin is active; by default, Enterprise customers have the System Clone application available to them.
After a release cycle is complete, consider cloning your instances using your production environment. This ensures that the instances remain in sync from a data and functionality
perspective. We also strongly recommend that you never clone a production instance from a sub-production instance. If a circumstance arises where this is a consideration, contact
ServiceNow support for assistance.
Define a cloning schedule
 Determining when you clone and how often can be challenging simply because there may be overlapping activities occurring in your other instances. Typically, clones occur
after releases, however, if you are in a pre-go-live scenario you may not need to clone this often.
Define and document cloning prerequisites
 Setup target – Configure the target instance to accept clones. You will need to use an administrator account for the process.
 Data – Determine what data, if any, needs to be preserved on the target instance. For more details, visit this page on data preservers.
 Instance activities – Ensure that any activities occurring in that instance are completed, data is backed up or exported, and update sets are complete if any development is
ongoing. Consider creating a shared folder that users can save their exported items to.
 Integrations – Ensure that any integrations on the target instance are turned off or paused during the clone.
 Notifications – Notify all users of the instance and any stakeholders that a clone is taking place. After the clone has completed, send out another notification advising that users
are able to continue their work in the instance.
Steps

Step 5a: Define guidance for development
Your Now Platform can expand both through planned deployment of new capabilities as well as organically, through configuration and custom development. Provide clear guidance
for development to consistently extend the capabilities implemented on ServiceNow.
Define the process and requirements for developing on the Now Platform in accordance with your defined architecture and technical requirements
 Define a detailed plan describing the process developers should take to develop, maintain, and enhance capabilities on ServiceNow.
 Define an end-to-end software development lifecycle (SDLC) specific to ServiceNow (or adapt an SDLC currently in place in your organization to work for ServiceNow).
 Define how demand for new ServiceNow applications and functionality will be managed.
 Define requirements that specifically address what needs to happen during updates and release management involving the Now Platform.
 Define how to use application scoping, including when and where to use private scoped apps (referred to as scoped apps, where access to the apps’ data and code is restricted) vs. global
scoped apps (with shared resources that any developer can access and modify).
o Establish private scoped apps as the default for new applications whenever possible. This makes it easier to manage a larger number of apps on the platform without hindering
upgrades.
 Define the requirements for the development teams working on ServiceNow, including:
o Requirements for developers to make sure that set architecture, instance, integration, and data flow requirements are upheld
o Requirements to make sure that new development does not negatively impact the ability to upgrade
 Define requirements for testing processes, user acceptance testing (UAT), and managing ongoing changes for ServiceNow.
 Work with your executive sponsor to ensure that appropriate staff and resources are available to oversee development operations adherence.
Practitioner insight: Coordinate with your ServiceNow governance group and/or executive sponsor as you define development operations. Technical and/or portfolio governance policies may
already define some of the requirements you need to establish. If they do, take the opportunity to review set policies and suggested changes/additions to them as needed.

1. Develop a clear understanding of 2. Define your instance and data 3. Define your integration 4. Manage your ServiceNow
Steps development on the Now
architectural needs architecture architecture architecture
Platform

Step 5a: Define guidance for development (Continued)
Define how you will manage the portfolio of new applications, integrations, Define clear accountabilities for ownership of development
etc. that are developed on the Now Platform
 Define development ownership/accountabilities across ServiceNow support and internal
 Assign the Now Platform owner and application developer to review all development groups, including:
applications, integrations, etc. deployed on the Now Platform every six
months (with a focus on new additions). During this review, they should:  Assign the ServiceNow platform support team ownership and accountability (especially the
ServiceNow platform architect) for defining and updating development operations, as well as
 Build and update an inventory/portfolio of what is running on the Now educating relevant groups about these operational needs.
Platform (identifying new additions since the last review in the inventory).
 Assign the ServiceNow platform owner accountability for managing new releases and
 Audit the inventory to assess whether custom applications on the platform still updates on the Now Platform, including making sure that all ServiceNow development
provide value, still align with business needs (defined in your ServiceNow requirements are followed prior to deployment and coordinating any organizational change
vision and phased program plan), and align to current development operations management (OCM) needs.
needs and requirements (e.g., still works with established architecture, will
 Assign accountabilities for adhering to development processes for developers directly
function through any planned changes in architecture, etc.).
involved in developing and implementing new capabilities on the Now Platform (especially
 Identify where apps are not private scoped apps to assess if they need to be. ServiceNow application developers on the platform support team and within IT).
 Consider what can be removed from the platform (e.g., because it’s no longer  Define any needed development accountabilities for external resources (including partners,
used, not supportable by operations, or not adhering to current requirements). contractors, consultants, other vendors, etc.).
 Communicate findings to the developer groups that deployed the applications,
etc. (especially if you are recommending that their application be removed or
requires updates).
Practitioner insight: Make sure the developers working on ServiceNow attend training for
new releases and/or get early access to upcoming versions so they can better understand
requirements for developing on the Now Platform.

Platform

Step 5b: Extend development operations
ServiceNow application development may not be limited to developers in enterprise IT, especially as your ServiceNow footprint expands across the organization. Individuals across
the enterprise have clear knowledge of the discrete problems within their areas that need solving. It’s a good idea to take advantage of this expertise when planning how to manage
development on ServiceNow.
To do so, you need to plan for how to include delegated developers (users outside of IT and defined ServiceNow teams who can create new applications or functionalities within
applications) to enhance ServiceNow, including how you ensure that they adhere to your architecture by following consistent development guidelines.
Define and clearly communicate the organizational goals and priorities for ServiceNow deployment so that delegated developers are not pursuing contradictory strategies
 Work with the ServiceNow platform support team to define development goals that align with your ServiceNow vision.
 Define the technical functionality needed and requirements involved for planned projects so developers can understand what development is already in progress and/or planned for the
future.
 Define what development requirements should be applied to delegated developers who are developing on the Now Platform.
 Define the specific responsibilities/accountabilities that delegated developers need to fulfill or follow to be able to reliably contribute to Now Platform development.

Platform

Step 5b: Extend development operations (Continued)
Define and clearly communicate the organizational goals and priorities for ServiceNow deployment so that delegated developers are not pursuing contradictory strategies
(Continued)
 Write a document (can be formatted as a policy, announcement email, or even a newsletter) to clearly communicate these goals/priorities and responsibilities to delegated
developers.
 Capture the defined development goals in a document that can be shared with delegated developers across the organization.
 Include the delegated developer responsibilities/accountabilities defined above.
 Include a brief description of the development guidelines that delegated developers must follow (e.g., the defined ServiceNow SDLC).
 Invite delegated developers who read the document to connect with the ServiceNow platform support team to coordinate development.
 Work with the executive sponsor to spread the word—they can share the documented goals with leaders in other departments who can then share with the delegated developers
in their departments.
Practitioner insight: Consider providing a separate environment for delegated developers to test and safely implement code on ServiceNow. Since they are less likely to strictly follow your
development operations and requirements, this can help make sure that their contributions can’t directly disrupt your core environment.

Platform

Plan your architecture, instances, integrations, and data
flows
Key performance indicators Essential KPIs Nice-to-have KPIs
• % of security compliance metrics met for ServiceNow • # certified staff for key ServiceNow roles
instances • # of enterprise IT partners identified
• % of CMDB performance measures (e.g., throughput of • # of business objective considerations on architecture
change per week, month, year) delivered according to requirements validated with the architecture and
business expectations governance teams
• % of instances that have recommended sub-prod/prod • % custom apps that are scoped apps
architecture • # developers working on ServiceNow apps
• # of times instance maintenance is performed per month
• Number of releases behind current upgrade
• Mean time to resolve performance issues
Stakeholder map Responsible/accountable Consulted/informed

• Now Platform owner • Enterprise architecture
• ServiceNow system administrator • VP of IT infrastructure/operations
• Platform support team • Technical integration team
• Executive Sponsor • Configuration management process owner
• CISO
• CIO
• Development teams for ServiceNow (outside the
platform support team)

Customer Success Best Practices
ServiceNow’s Best Practice Center of Excellence provides prescriptive, actionable advice to help you
maximize the value of your ServiceNow investment.
Definitive guidance on a Created and vetted Proven to help you transform

breadth of topics by experts with confidence
Strategic
Best practice insights
from customers, partners,
Critical and ServiceNow teams
processes
Practical Actionable
Expert
Management insights Technical Based on thousands of
successful implementations
Common across the globe
pitfalls and
challenges
Tactical Distilled through a

rigorous process to enhance Value- Expert-
Designed for: your success added validated
Executive Platform Service

sponsors owners and process
and teams owners
Contact your ServiceNow team

Get started today. Visit Customer Success Center. 26
for personalized assistance.
© 2020 ServiceNow, Inc. All Rights Reserved.

Architecture Instances Integrations Data Flow Plan

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Architecture Instances Integrations Data Flow Plan

Uploaded by

Copyright:

Available Formats

Plan your architecture, instances,

integrations, and data flows

Insight: Plan your architecture, instances, integrations, and data flows

Key implementation steps

2 © 2022 ServiceNow, Inc. All Rights Reserved.

3 © 2022 ServiceNow, Inc. All Rights Reserved.

4 © 2022 ServiceNow, Inc. All Rights Reserved.

Complete the following:

5 © 2022 ServiceNow, Inc. All Rights Reserved.

Identify requirements that will guide your cloud architecture*

6 © 2022 ServiceNow, Inc. All Rights Reserved.

7 © 2022 ServiceNow, Inc. All Rights Reserved.

8 © 2022 ServiceNow, Inc. All Rights Reserved.

9 © 2022 ServiceNow, Inc. All Rights Reserved.

10 © 2022 ServiceNow, Inc. All Rights Reserved.

11 © 2022 ServiceNow, Inc. All Rights Reserved.

Tie your integration strategy to your business objectives

Create a list of potential integrations based on your current ServiceNow implementation

 Consider the following categories:

12 © 2022 ServiceNow, Inc. All Rights Reserved.

13 © 2022 ServiceNow, Inc. All Rights Reserved.

For custom interfaces, determine the following for each interface:

14 © 2022 ServiceNow, Inc. All Rights Reserved.

15 © 2022 ServiceNow, Inc. All Rights Reserved.

 Always include the CI’s unique identifier.

16 © 2022 ServiceNow, Inc. All Rights Reserved.

Develop and maintain your runbook

 Document the following information:

17 © 2022 ServiceNow, Inc. All Rights Reserved.

Create your instance maintenance plan

18 © 2022 ServiceNow, Inc. All Rights Reserved.

19 © 2022 ServiceNow, Inc. All Rights Reserved.

Define a cloning schedule

Define and document cloning prerequisites

20 © 2022 ServiceNow, Inc. All Rights Reserved.

5. Plan for expansion and

21 © 2022 ServiceNow, Inc. All Rights Reserved.

5. Plan for expansion and

22 © 2022 ServiceNow, Inc. All Rights Reserved.

5. Plan for expansion and

23 © 2022 ServiceNow, Inc. All Rights Reserved.

5. Plan for expansion and

24 © 2022 ServiceNow, Inc. All Rights Reserved.

Stakeholder map Responsible/accountable Consulted/informed

25 © 2022 ServiceNow, Inc. All Rights Reserved.

Definitive guidance on a Created and vetted Proven to help you transform

Tactical Distilled through a

Executive Platform Service

Contact your ServiceNow team

You might also like