ServiceNow Deployment Pipeline - Part 2: First Steps and Considerations

Introduction

As already explained in my first article of that series, I can’t share the complete solution of my Deployment Pipeline application. However, I’m excited to provide valuable insights into its creation process and shed light on some key technical and architectural topics. With that second article, I'd like to start with showcasing how I tackle challenges like this and what “architectural thinking” means to me. This involves breaking down complex problems, designing with long-term strategy in mind, and balancing technical feasibility with business needs.

First, craft your idea

“A journey of a thousand miles begins with a single step.” (Chinese saying)

If you have no idea what your first step could be, draw a picture. And make it so that any non-technical user can understand it. As an experienced architect, you will be tempted to demonstrate your excellent skills in one of the standard modeling languages, such as BPMN, UML, ArchiMate, and so on. But try to resist this temptation at the beginning of your journey and instead capture all your thoughts in simple but expressive pictures. The translation into standard notations can be done later when it comes to technical design.

And don’t overcomplicate the search for the perfect tool - what matters most is getting your ideas down quickly and clearly. There are plenty of free tools on the Internet and even a standard office computer will have one or two (PowerPoint, Visio, Paint, etc.) that you can use to sketch out your idea. Furthermore, there are many internet archives with free icons or images that will help you to visualize your ideas and thoughts in an expressive way.

This first idea might look simple, however it already carries many conceptional ideas:

• A "Deployment" is a process (symbolized by an arrow) with a start and with end.

• A "Release" is a larger thing and a bundle which needs to be transported.

• The release transportation starts at a source instance and ends at the target instance.

The image above intentionally leaves many questions unanswered, such as:

• Who are the involved stakeholders?

• What types of artifacts can be shipped?

• Are any external CI/CD tools involved?

• What does the customer app include and where exactly does it run? On the source instance, on the target instance or on both?

Avoid the common pitfall of trying to answer every possible question in your first draft - this often leads to information overload and a lack of clear focus. Instead, start by clearly defining your target audience and understanding the level of detail they truly need to make informed decisions. Consider factors like their role, their familiarity with the subject, and what specific insights or outcomes they expect. This will help you tailor your message and avoid unnecessary complexity. After all, every step in this process is about decision-making: for example a sponsor’s decision on whether to fund your idea, or the reader’s decision to keep engaging with your article because the topic resonates with them.

Second, define the personas involved

“Usability is about people and how they understand and use things, not about technology.” (Steve Krug)

When you think back to your last software projects, you’ll likely recall the kind of input they often started with: that’s right - an Excel document filled with hundreds of vague, feature-focused requirements. Statements like “the system must be able to export table views to an Excel format” are common, but they regularly miss a crucial element: the future user. From the customer’s perspective, this is understandable - during the RFP phase, requirements need to be structured and analyzed efficiently, often leaving little room to address the individual needs and challenges of end users.

This disconnect becomes even more pronounced when pricing takes center stage in the bid process and the winning bid is often driven by economic and political factors, prioritizing cost over usability. Yet, once the contract is awarded, the true measure of success lies elsewhere. As the responsible architect, your focus must shift to the people who will actually use the product. It’s their acceptance - far more than the number of implemented features - that ultimately determines the project’s success or failure. That’s why my next step in any project journey is always the identification and description of the key personas involved.

For a high-level perspective, a persona is a fictional character that represents a specific user type for a product or system. Personas are crafted based on user research and are used to understand user needs, experiences, behaviors, and goals. They help bridge the gap between the technical development team and the end-users by providing a relatable and detailed representation of the target audience. In practice, you might want to create the personas as individual pages in your project wiki and invite other project members to work on them in the spirit of collaboration. The following content can be used as a guide, without claiming to be exhaustive:

Demographic Information / Bio

• Name, age, gender, education, and occupation.

• Background information such as work experience, job responsibilities, and personal interests.

Behavior Patterns

• Typical activities & tasks related to the product.

• Usage patterns, preferences, and motivations.

Goals and Needs

• Important goals related to the use of the product.

• Specific needs that the product must fulfill.

Pain Points and Challenges

• Issues or challenges faced while using similar products.

• Frustrations and obstacles that hinder achieving their goals.

Environment and Context

• The physical, social, and technological context in which the persona operates.

• Tools and devices commonly used by the persona.

Quotes and Stories

• Direct quotes from interviews or surveys that capture the persona's voice.

• Short narratives depicting typical interactions with the product/system.

As the project progressed, these persona pages proved very useful for enriching with additional technical and organizational information, such as:

• In which user group (in ServiceNow) can users be found?

• Which ServiceNow roles are assigned to these groups?

• Are users of that persona consuming licenses or not?

• How can an ServiceNow account with that persona be ordered (for example, in a company-internal role shop)?

• What is the test user for the persona that can be used for impersonating?

• Which ATF test suite is dedicated to that persona?

Coming back to the Deployment Pipeline application, the following personas have been identified by me:

• Deployment Pipeline Administrator: Responsible for configuring and maintaining the Deployment Pipeline application, managing users, and ensuring the system’s reliability and security.

• Deployment Pipeline User: Assembles a deployment, executes it (if approval is not required) or submits the corresponding deployment requests. Furthermore that persona monitors deployments as well as tracks the progress and results of deployment activities.

• Other users (including those with the "admin" role): Regular ServiceNow users or administrators who may be impacted by deployments but don’t directly interact with the deployment pipeline’s execution or configuration.

Third, define the high-level goals

“Goals are a stakeholder’s description of the benefit intended in the context of the system... Requirements are statements about the desired system.” (Karol Frühauf in re-magazine.ireb.org)

In software development, distinguishing between goals and requirements is fundamental to project success. Goals represent the overarching aspirations or desired outcomes of a project, providing strategic direction and purpose. They answer the question of "why" a project is undertaken, such as enhancing user satisfaction or increasing operational efficiency. Requirements, on the other hand, are the specific, actionable conditions or capabilities that a system must possess to fulfill these goals. They address the "what" and "how," detailing functionalities like "the system must support user authentication" or "data must be encrypted during transmission."

Clearly articulating and consistently communicating goals throughout the development process is crucial. When teams have a shared understanding of the project's objectives, they can make informed decisions that align with the desired outcomes. This alignment ensures that the requirements are relevant and contribute directly to achieving the goals. Moreover, well-communicated goals facilitate stakeholder engagement, as all parties comprehend the project's purpose and value. This shared vision fosters collaboration, minimizes misunderstandings, and increases the likelihood of delivering a product that meets or exceeds expectations, reducing the risk of failure - something that unfortunately happens all too often in software projects.

For my Deployment Pipeline application in ServiceNow, I defined a set of high-level goals that address both technical efficiency and business value:

1. Streamlined Deployment Control: Enable deployments to be launched and managed directly from the DEV instance, eliminating the need to enter the target instance.

2. Full Automation of Deployment Processes: Achieve 100% automation across the entire deployment lifecycle, covering all artifact types and associated activities, reducing manual effort and the risk of human error.

3. Complete Transparency and Traceability: Ensure full visibility into upcoming and completed deployments, including clear approval processes and detailed deployment histories for auditing and compliance.

4. Real-Time Deployment Insights: Provide live status updates, progress tracking, and immediate issue identification to enable quick resolution and minimize deployment disruptions.

5. Robust Security and Access Control: Guarantee that only authorized users can initiate deployments on target instances, safeguarding the integrity and security of the platform.

6. Future-Proof Design and Maintainability: Avoid customization-driven technical debt by implementing a robust, scalable, and easily extensible software architecture, ensuring long-term maintainability and adaptability.

Wrapping up

Thank you for taking the time to read this! I’d love to hear your thoughts, opinions, and experiences - feel free to share them in the comments. If you’d like to dive deeper into any of the topics I’ve covered, don’t hesitate to reach out to me directly.

In my next article, I’ll take a more conceptual approach and provide an in-depth overview of the solution design - stay tuned!