In part one, we discussed what an architect is within the ServiceNow and the larger IT ecosystems. Now, we’ll delve into design documentation – a key part of an architect’s deliverables, and some of the behaviors of folks who may have the title architect but whose actions belie the title.

Documenting designs and implementations

A good architect understands the value of documentation, and both creates and enforces documentation. My rules of thumb for documentation are:

• Any custom development that includes creating new tables needs design documentation. This does not include Import Set tables, but does include tables meant for custom lookup functionality, extensions to existing functionality, and new task-based applications.
• Any development that spans multiple Agile stories likely requires design and implementation documentation. What I mean by this is if the solution being implemented is complex enough to require multiple stories, there should be a centralized design for the solution that can be referenced by Story developers and post-implementation maintainers.
• Any development whose essential nature cannot be found in existing ServiceNow documentation likely requires documenting. This is typically custom development.
• Any development that would not be obvious to an experienced ServiceNow admin or developer who walks in “off the street” likely requires documenting. In other words, if an experienced ServiceNow person wouldn’t be able to understand the design of the solution simply by looking at what’s in the platform, then the architect “owes” them design documentation so they can see the thinking behind the design. (I can’t say how many times I’ve come into a situation like this and my only tact is to start reverse engineering code. I find this unacceptable.)

My standard “as-built” documentation for these scenarios includes:

• The picture of what was designed (aka “Visio”)
• The narrative of what was designed, and why
• The elements of what was implemented, and where
• The narrative of how the solution is to be maintained

For the sake of illustration, a Salesforce integrated application design document make look something like this:

Design Diagram

Design Narration:

The solution uses a custom request application to align with the Salesforce model, and uses Web Service Import Sets to stage the Salesforce data. Within ServiceNow, the same request can be initiated through a Record Producer in the Service Catalog… continue to describe the diagram and how the pieces fit together.

Implemented Elements:

Maintenance Notes:

In order to extend the data schema on both systems, add fields to the ServiceNow request and import set tables, and use the transform map functionality to populate the field(s). Extend the custom mapping table to Salesforce so the outbound REST message will pick up the new field from ServiceNow… continue to describe the maintenance and extension of functionality

The goal is not documentation for documentation’s sake. The documentation should be clear and straightforward – think of the person who is seeing the solution for the first time. If it were you, what would you want to see to understand what was built?

You should be able to give the document to an experienced ServiceNow admin or developer and they understand the solution and can maintain it without having to comb through the system and/or reverse engineer it to learn it. And if I’m being perfectly honest, there are plenty of times I have to do this with new ServiceNow created applications or solutions.

Architect Failings, aka When It’s a Misnomer

It’s also helpful to list things that aren’t architecture, or at least don’t fall under the heading of “what makes a (good) architect”. I posit that when someone who has the title of “Architect” does these things, they are not truly an architect.

• Treating all requirements development as a one-off. In other words, as requirements come in, the named architect only considers the requirement within the scope of itself, and solutions inside of that box. Doing so results in many unrelated one-off solutions within the platform, without a cohesive platform strategy to tie them together. This leads to maintenance challenges, as each change requires modifying a particular element. For example, I was working with a customer who had several hundred catalog items, each with their own workflow. We made a platform change at the Task level that required the modification of the same few lines of code across hundreds of workflows. A good architect somewhere in that development journey should (would) have stopped these one-off developments and designed a solution where the code existed in one place and was called where needed by the workflows. (I would argue a good architect would also consolidate the workflows, but I hope you see my general point.)
• Implementing all requirements with code. I also refer to this as “write code until it works”. I’ve written about developing solutions that leverage the elements of the platform and maximize configuration over code. An architect understands how this is done, and avoids the common trap of overcoding. Just as important, he or she assures that the development team doesn’t do this either by providing design guidance as I’ve described previously.
• Pushing products over solutions. There is a balance that must be struck between defaulting to a ServiceNow product as a solution, and developing a custom solution that may more perfectly align directly with business requirements. An architect understands each, and the tradeoffs, can articulate the advantages and disadvantages of each, and guides customers to the correct implementation for their business needs. In my view, those who do not make this distinction, but default to a ServiceNow product based on a few keywords heard in requirements sessions, are better termed as Sales or Solution Architects and not Technical Architects.
• Limiting solution scope to ServiceNow. When reviewing business needs, if an architect does not consider all possible solutions in the enterprise, but limits their scope to only ServiceNow, they are not performing the duties of a true architect.

Conclusion

A good ServiceNow architect always starts with understanding the business’s short and long term needs, and recommending a solution that aligns with both, regardless of the technology. He or she understands enough about the ServiceNow platform to recommend the correct application or platform technology to meet the need when ServiceNow is the correct solution. And the good architect provides design oversight so that all parties involved in the solution are working toward the correct goal in the correct ways. In short, the best ServiceNow architects have knowledge of, and can work in, all spheres of the ServiceNow and Enterprise IT scopes:

Lastly, when the architect doesn’t have the required experience in a particular area, they know enough to seek expertise in that area (rather than “faking it until they make it”). If knowledge is power, knowing what you don’t know is wisdom.

“Architecture is not an inspirational business, it’s a rational procedure to do sensible and hopefully beautiful things; that’s all.” – Harry Seidler

If you’re here and reading this, you probably have a concept of what a ServiceNow architect is. (In this context, “architect” means a ServiceNow technical architect.) And you’ve likely worked with folks who have the title “architect”, whether on implementation projects or as part of a larger IT ecosystem. But what does this mean, and what should it mean? I’ll spend the rest of this article discussing this topic. Having the title Certified Master Architect doesn’t mean I have all the answers, but I’ll posit that having my experience and acumen means I can define it as well as anyone.

In part one, we’re going to discuss what an architect is within the ServiceNow and the larger IT ecosystems. In part two, we’ll delve into design documentation – a key part of an architect’s deliverables, and some of the behaviors of folks who may have the title architect but whose actions belie the title.

It’s helpful to start with two lists that will contextualize the discussion: The roles that are common to a medium to large-sized ServiceNow environment, and the spheres of influence the ServiceNow leaders oversee.

Common ServiceNow Roles

• System Administrator – hands on configuration and management of the platform
• Business Analyst – elucidating business requirements
• Developer – custom solution development
• Designer – intra and inter application solution design
• Architect

In many customer environments, folks fill more than one of these roles, and potentially one person wears all the hats in small platform implementations.

ServiceNow Decision Spheres

• Hands-on development
• Application design
• Platform strategy
• Enterprise strategy

These are the areas that require guidance to be provided and decisions to be made. Much like the roles, the people providing the guidance and making the decisions may cross spheres, but the spheres exist.

These spheres fit into a pyramid picture of ServiceNow within the IT ecosystem.

At its most narrow, it helps define development best practices, and at its broadest delineates where and how ServiceNow fits in the overall IT enterprise.

Defining the “Good” Architect

In my experience, and based on feedback from my customers, here’s what makes a good ServiceNow architect, and comparing it to what might be considered architecture but really isn’t:

Considering ServiceNow in the larger customer environment

This is traditionally the purview of the Enterprise Architect in larger organizations. The role takes into account short-term organizational and project needs, and longer-term strategic needs, and evaluates which technology tools are the correct ones to meet both needs. A ServiceNow architect should be able to converse intelligently about these customer needs and convey where ServiceNow can and should fit into meeting those needs. Just as importantly, he or she should also understand and be honest about where ServiceNow may not fit those needs. Between these two, the architect should be able to articulate what ServiceNow can do, the level of effort and cost to implement and maintain in ServiceNow, and help the customer make the correct decisions about using – and not using – ServiceNow.

Understanding the platform separately from products

A good ServiceNow architect understands the platform inherently – I’ve written about this previously. ServiceNow has increasingly moved from being a platform to being a series of products developed on that platform. While there is value in understanding these products, particularly from a business process perspective(*), a good architect can separate the chaff of product marketing from the value of the platform. And more importantly, can align this knowledge with customer requirements.

*For example, understanding how HR processes work, and how these processes are implemented in ServiceNow HR, has value.

Translating customer requirements into the correct platform solutions

Assuming an architect fundamentally understands the ServiceNow platform and understands when ServiceNow should or should not be used in the customer’s overall IT environment, he or she should be able to listen to business requirements and translate into the best way to achieve them in ServiceNow (assuming ServiceNow is the best place to achieve them). What this means is that the architect knows enough about the platform to determine if there is a pre-built solution that best serves the need, or if it is better served by extending platform capabilities to create a customized solution. He or she should also be able to articulate the reasons why to choose one over the other, and both speak to and document the advantages and disadvantages of both, including hard and soft costs.

Knowing and advising on best practices

The ideal architect is knowledgeable enough to not only design the correct solution, but advise on how to implement that solution. This includes advising on technical best practices. For example, when I serve as a technical architect on both projects and ongoing development in an Agile environment, my role and input includes documenting the technical approach on Stories. This is the detail of what and where to develop to satisfy the stated requirements, not necessarily the how. In other words, because there are often 3-4 ways to satisfy a requirement in ServiceNow, the architect should advise on the best way to do it based on their knowledge and experience. This is often beyond the knowledge of a developer or administrator, and beyond what can be found in ServiceNow documentation.

After reading this, you might think “but there’s too much crossover with the roles mentioned at the beginning”. And you may be right. What I’ve found in my ServiceNow journey is that it’s rare that an architect can only fulfill a pure architecture role. Most customer environments aren’t large enough to support this level of “purity” or responsibility delineation. In addition, I’ve found that you cannot provide the correct architecture decisions without some hands-on experience with the platform. Doing so leads to “book” answers without the benefit of real-work experience.

In addition to the more pure architecture I’ve listed, the best architects can also advise on practices for instance management: managing configuration and code updates through the SDLC and provide insight on how to build and maintain to simplify system upgrades (new releases). In short, the architect should be a trusted advisor to IT Management on minimizing cost and maximizing value with ServiceNow.

Coming up in part two, we’ll look at documentation and behaviors that belie the architect title.