architecture-instances-integrations-data-flow-plan.pptx

Plan your architecture, instances,
integrations, and data flows

2 © 2022 ServiceNow, Inc. All Rights Reserved.
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?
Plan your architecture, instances, integrations, and data flows
Key implementation steps
Start Improve Optimize
1. Develop a clear understanding of
architectural needs
2. Define your instance and data
architecture
3. Define your integration
architecture
4. Manage your ServiceNow
architecture
5. Plan for expansion and
development on the Now Platform

Understand the Now Platform infrastructure
 Learn about Now Platform’s cloud infrastructure. Ensure your teams:
 Review the overview of the ServiceNow® Advanced High Availability
(AHA) architecture.
 Build a deep understanding of the ServiceNow infrastructure, including
its capabilities to scale horizontally, load balance, and failover when
necessary.
 Learn how data is stored and managed in your ServiceNow instance.
Refer to product documentation (of your instance release version) for
an overview of how applications use tables and records to manage data
and processes on the Now Platform.
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.
Step 1a: Understand the out-of-the-box Now Platform
architecture
Understand the Now Platform’s core features and functionality
 Ensure your teams develop an understanding of the following features and functionality of the Now
Platform:
 Capabilities – For example, Service Portal, Configuration Management Database (CMDB), Compliance, etc.
 Products – For example, IT Service Management, IT Operations Management, Security Operations,
Customer Service Management, HR Service Delivery, etc.
 Certified applications – Explore the ServiceNow Store.
 ServiceNow Store integration hub apps – For example, preconfigured integrations with Box and Splunk, and
Okta.
 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.
 Ensure your teams know how business processes are triggered and completed on the Now Platform,
including:
 Business rules – Server-side scripts that runs when a record is displayed, inserted, updated, or deleted, or
when a table is queried
 Flow Designer – A Now Platform feature for automating processes, including integrations, in a single design
environment without coding
Practitioner insight: The best way your team can build up its expertise on the
Now Platform’s core features and functionality is to start by taking the
ServiceNow Foundations eLearning course and then review ServiceNow Training
and Certification courses for training and certification opportunities.
architectural needs
architecture
architecture
architecture
Steps

Identify the enterprise IT teams you’ll need to partner with to support the Now Platform
 Enterprise architecture (EA) – EA performs the analysis of business structure and
processes. EA may have been involved in evaluating the Now Platform and will help
determine how it fits into your business and systems architecture.
 Data architecture and technical integration – These teams define how different data
entities and IT systems will store, consume, integrate, and manage data. They'll be
an important resource as you integrate the Now Platform with other enterprise
systems.
 Security – Security is responsible for defining security requirements and protocols
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.
 IT support – This resource supports the platform on a daily basis. IT support also
coordinates and supports patches, upgrades, defects, and enhancements.
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.
Step 1b: Identify the extended technical team you need to
work with
Provide an overview of Now Platform architecture and functionality to your enterprise IT
partners, to find questions and requirements that may affect your architectural decisions
 You may conduct this as a planning workshop—be sure to include your
implementation partners. (Note: This may already be planned or conducted as part of
your onboarding process with ServiceNow.)
 In addition to finding potential questions and requirements, you can use this workshop
to identify points-of-contact within the teams listed previously, who can collectively
act as your “extended” ServiceNow team. This should provide the basis for a RACI
chart that defines “ownership” for key decisions and responsibilities between the core
ServiceNow team and enterprise IT functions.
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
ServiceNow governance lead and/or executive sponsor to coordinate governance policy
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.
architectural needs
architecture
architecture
architecture
Steps

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.
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.
Step 1c: Assess the impact of business objectives/strategy on
architecture requirements
architectural needs
architecture
architecture
architecture
Steps
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.

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.
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.
Step 2a: Design your instance configuration and
management strategy
1. Develop a clear understanding
of architectural needs
architecture
architecture
architecture
Steps
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.

management strategy (Continued)
architecture
architecture
architecture
Steps
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.

management strategy (Continued)
architecture
architecture
architecture
Steps
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.

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:
 What you want to accomplish with configuration management, per the use cases outlined above.
 How you will approach your implementation, as well as your assumptions and constraints.
 What business outcomes this will support.
 How will you know if you’re doing it right, i.e., the measures of success you’re going to use.
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.
Step 2b: Define your configuration management strategy
architecture
architecture
architecture
Steps
*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
Practitioner insight: Build your
configuration management team and
data model early, to set the foundation
for configuration to support other
applications long term. See ServiceNow’s
Success Playbook for more information
on planning a successful CMDB
deployment.

Determine your CMDB requirements (Continued)
 Scope the requirements for your CMDB. Use the below
questions as a guide:
 What environments will configuration management oversee
(e.g., production, development, test, etc.)?
 Which CIs in the CMDB need to be managed at the
relationship level and which CIs require only inventory-level
management?
 What IT services will be included?
 Are there geographic considerations to account for?
 Are there regulatory or compliance requirements that must be
met?
 Are there specific levels of control required for traceability and
auditability?
 What security issues must be addressed?
 Are interfaces to internal and external service providers
required?
(Continued)
architecture
architecture
architecture
Steps
Design the CMDB
 Work with your ServiceNow implementation partner and configuration manager to design a foundational
CMDB based on your organizational needs. Complete the following tasks, using requirements derived from
the questions to the left as a guide:
 Design the CMDB data model – Class/sub-class structure, which are typically aligned to technology domains:
server, network, database, application, storage, etc.
 Identify the required content for each class/sub-class – Attributes including class-level inheritance and required
relationships
 Establish the configuration item (CI) naming conventions/standards
 Determine data ownership
 Define the data security requirements
 Identify the data sources and determine the mechanism(s) you will use to import data into the CMDB
(discovered, automated, and/or manual)
 Validate and get approval for your CMDB design from your key stakeholders including representatives from
key functions who depend on CMDB data, the configuration management team, and data architects, if any.
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.

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.
(Continued)
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.
architecture
architecture
architecture
Steps

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.
Step 3a: Determine the requirements for effective
integrations
architecture
architecture
architecture
Steps
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.

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

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

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.
Step 3c: Maintain CMDB integrity
architecture
architecture
architecture
Steps
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.

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.
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.
Step 4a: Develop a robust migration plan as you move
toward production
architecture
architecture
architecture
Steps

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.
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.
Step 4b: Develop an instance maintenance plan
architecture
architecture
architecture
Steps

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

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.
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.
Step 4d: Develop a standard process for cloning to support
upgrades and other changes
architecture
architecture
architecture
Steps

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.
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.
Step 5a: Define guidance for development
architecture
architecture
architecture
Steps
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.

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

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.
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.
Step 5b: Extend development operations
architecture
architecture
architecture
Steps

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.
architecture
architecture
architecture
Steps
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.
Step 5b: Extend development operations (Continued)

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

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.
Get started today. Visit Customer Success Center. Contact your ServiceNow team
for personalized assistance.
Definitive guidance on a
breadth of topics
Management Technical
Tactical
Strategic
Critical
processes
Expert
insights
Common
pitfalls and
challenges
Created and vetted
by experts
Distilled through a
rigorous process to enhance
your success
Based on thousands of successful
implementations
across the globe
Best practiceinsights
from customers, partners,
and ServiceNow teams
Proven to help you transform with
confidence
Practical Actionable
Value-
added
Expert-validated
Designed for:
Executive
sponsors
Platform
owners
and teams
Service
and process
owners

architecture-instances-integrations-data-flow-plan.pptx

More Related Content

Similar to architecture-instances-integrations-data-flow-plan.pptx (20)

Recently uploaded (20)

architecture-instances-integrations-data-flow-plan.pptx

Editor's Notes