My Certified Technical Architect Series - Week 3

[Marcos Kassak]

There are two types of architects:

• Enterprise architect: He will care about the whole company;
• Domain architect: Specialized in a specific layer.

Without architectural standards in a company, employees will always find different ways to solve their day-to-day problems. This, in the long term, will make the adoption of a tool, integrations with in-house built apps, and so on, difficult. Governance becomes impossible, siloes quickly form between teams, and work is redone because there is no awareness of the plan or where the company is headed.

At the same time, the use of clear and standardized architecture artifacts is a good way to eliminate the communication barrier between technical teams and business stakeholders to make sure that everyone has a single vision of the transformational goals. Such an approach allows for creating a visual language where thinking at a platform scale is intuitive, and the change concept turns into the transformation reality. For the same reason, the standards make it possible to apply more consistently the established level of discipline and formality to architecture artifacts design and implementation, making it easier to analyze options and identify gaps.

This week was all about:

• Introduction to Architecture Standards;
• Architect Blueprints;
• Current and To-be Architecture.

The standards that we had to review in this case study were:

IT4IT: A framework AND methodology for enterprise architecture;

ArchiMate: A modeling notation that can be used with TOGAF;

TOGAF: A reference architecture to IT operations management.

To be honest, I haven't seen IT4IT applied completely in a ServiceNow project. I was surprised by John Wang approach to this week's presentation; he did an outstanding job. Go Inferno Squad!

Some notes of my notes from the VCS:

• Most implementation partners focus on capability maps and architectural design, but what about the implementation roadmap? This includes the current architecture involving the customer's existing applications and how that ties into your ServiceNow architectural design to improve their services.
• A set of documents that an architect should maintain: Business Capability Map, ServiceNow Capability Map, Service Alignment Map, Integration Architecture, and Instance Structure - I’ll create separate articles for those documents with downloadable templates 🙂
• How is your ServiceNow Capability Map linked to the CSDM phases (Crawl, Walk, Run, Fly)? Does the current design support this kind of approach?
• Try to leverage an MVP on your first deployment; whenever you deliver value quickly, you can start expanding to other modules and implement the full potential.
• Make sure to align your customer goals with the implementation of your TO BE architecture - it could be increased adoption, improved performance, cost reduction, and so on.
• Demonstrate the value that each implementation brings to the goals. Avoid being the person who only says ‘We haven’t bought these subscriptions’ or ‘That’s Pro and we only have the Std version’.
• Make sure to start the conversation with InfoSec teams early in the project. Create an HLD document that aligns with their needs, containing data center locations, RTOs, RPOs, Mid Server Info, ITOM credentials, etc.
• Instance Observer (IO) is a great tool to have control and real-time status of your instances concerning monitoring, availability, and in-depth analytics on performance… https://docs.servicenow.com/bundle/washingtondc-impact/page/product/impact/concept/io-overview.html

Recommended tools for color correction in presentations/design:

https://color.adobe.com/pt/create/color-wheel

https://color.review/

If you missed week 1 or week 2, here are the links.

Thanks for reading and see you next week!