The following set of rules is aimed to provide a maintainable, extendable and understandable architecture for any solution within service now. They are kept as short as possible to allow for a one page document. Please share your thoughts and feedback, as well as your critique.

1 Script Includes are the brain

Your brain consists of multiple areas, each with distinct functions. Same should be true for your Script includes. Differentiate them. Distinguish between data manipulation and data interaction. Your brain does do it all, but not all in one place. Make code true to yourself, learn from nature. It has been working well for ages.

2 Business Rules are the passthrough

Remember the human part? Business Rules are the spinal cord to the brain. They don’t think. They don’t do. For a matter of fact, they just don’t.

Therefore, make Script Includes the brain to your Business Rules and use the Business Rules to rapidly pass information to the brain.

3 Client scripts are for displaying data

What do they display? Data! Where do they get it from? Queries! Do they think? No! Do they do? No! But what are they there for? To display data.

That’s it.

4 Workflows are a succession of Business Rules

Follow the same principles! Workflows are “just” the spinal cord as well. They “just” don’t. Make Script Includes the brain to your Workflows.

But what about macros, widgets and pages?

Remember Client Scripts? Yeah, they are what Workflows are to Business Rules.

5 What’s with UI Actions?

Think of them as doorbells. You can hit a door bell. Does the door open cause of the doorbell? Not necessarily. Will the door open without it? Certainly not.

Use them as doorbells. Trigger actions without doing anything. Nothing to think about either.

6 Object Orientation – It’s a charm

Beauty of the cloud? You are not hosting the database. Loads of tables and relations take up too much space? None of your business. Utilize object orientation.

7 Object Orientation without Object Calisthenics

Try it. It’s like Buddhism but without the use of mediation. It works fine, but it is inefficient. And usually it prevents from achieving the cool stuff.

8 Draw a painting – visualize structures

If you cannot draw your architecture, don’t bother trying to explain it. Can’t explain your architecture? Well, overly complicated things for 500, please.

9 Read code – a lot

Things to learn from your past code and the code of other people:

• Better ways to do it
• How not to do it

Both important to improve. On a side note: Iterate your architecture. Rework it. The best way to improve is to learn from the past. Best way to do this is to solve issues from past projects.

10 It’s art – opinion is subjective and there is no definite best solution

Two key points here:

1. Don’t let this prevent you from searching for the best possible solution.
2. Even art can be objectively shit.