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