What makes a good ServiceNow architect? And what makes “architect” a misnomer?
“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.
