IT Architecture Principles

Example overview visualization of Dragon1 IT Architecture Principles.

Guiding changing requirements with IT Architecture Principles

Every organization today uses software applications and digital data in their processes. That means that every organization has a business operation supported by IT. Constantly, the organization's IT requirements are changing.

To provide a solid framework for IT to evolve within, a set of IT Architecture Principles is more and more often used.

IT Architecture Principles are statements of truth for the IT of the organization.

IT Architecture Principles differ from strategic starting points, general rules, and guidelines.

Principles are small chunks or pieces of knowledge.

Principles explain how things are structured, grouped, and connected. Else, they are not principles.

A principle statement should always mention an inevitable consequence.

Everything in the IT environment has to be (made) compliant with the principles, or else the principles are not workable for your environment.

If things cannot be made compliant with the principles, change your current state IT architecture principles so that they describe the current situation: what is implemented, complied with, etc... The approved IT Architecture Principles will then constrain any change to the IT environment. This ensures that any change allowed will not cause other parts of IT to be impacted negatively.

Current State and Future State Principles, linked to goals

It is common to work with two lists of principles: current state and future principles.

The current state principles describe the IT Architecture Principles implemented, obeyed, or respected in your IT environment. This could mean some principles hinder or block your strategy execution.

The future state principles describe what the IT Architecture Principles should be that are implemented, obeyed, or respected by your IT environment. This means they should always be derived from your business strategy and IT strategy to ensure better strategy execution.

Goals

Every principle should have a goal or objective linked to it to justify recognizing and using it in the organization.

Doing that helps you budget, plan changes, and mitigate risk IT risks much better.

Let's use an example: The principle(s) of IT Services

Suppose that you have an IT goal in your strategy of providing applications, datasets, and IT infrastructure to the business with a higher level of access, availability, and scalability, and you have another IT goal of lowering the cost and complexity of your IT environment.

Then it is more and more common to select the principle(s) of IT services and make that part of your IT Architecture.

The principle(s) of IT services contain chunks of tested and proven knowledge on how to design best and change your IT environment so you can provide it to the business in the form of high-quality IT services.

One of the things these principles of IT services tell you is that it is very wise to create an IT Services Catalog, a document of understandable and workable IT services for business users with a service level specified.

These principles tell you that you could and should be making the IT services as independent as possible of other IT services. So that changing some IT components in the background of 1 IT service does not or hardly affect the other IT Services.

Thirdly, it is common to group IT services into business process, application, and infrastructure services.

For every IT goal in your strategy, you can select 1 or more IT architecture principles and vice versa.

Example list of IT Architecture Principles

The IT of an organization can be divided into domains.

Per domain, we will provide 1 relevant principle common to many organizations in various industries.

Read all the words below as: The Principle of ...., such as the Principle of Change Management.

The list of common IT Architecture Principles is:

1. Standardization (of Network and App DevOpsSec)
2. Interoperability
3. IT Services
4. Service Orientation (SaaS)
5. Work with IT Domains
6. Change Management
7. Disaster recovery (plan)
8. Scalability (of IT Services and components: SaaS, IaaS, and PaaS)
9. On Prem vs SaaS
10. IT Governance (look for a standard like COBIT)
11. IT Service Management (look for a standard like ITIL)
12. Life Cycle Management (don't work with EoL components)
13. Vendor Management (don't buy from blocked vendors)
14. Technology Debt Management (always remove unused components)
15. Zero Trust
16. Authenticated and Authorization of access
17. Complexity Reduction
18. Load Balancing
19. Redundancy
20. Seperation of Concerns (SoC)
21. SoC: separate data analytics domain/databases from production domain/databases
22. Loosely coupling
23. Reuse before buy before build
24. Design from a business perspective
25. Design from a user perspective
26. Centralization of core components
27. Ownership (of components)
28. DevOpsSec (f.i.: do not develop or test in production)
29. Segmentation (Front, Mid and Back Office/Back End)
30. Mobile First
31. Cloud First
32. SAP Only
33. Microsoft First
34. Ownership (of every component and service)
35. Single Source of Truth (SSoT)
36. Data is an Asset
37. Segmentation
38. REST APIS

Governance of IT Architecture Principles

For principles to work well and be effective in an organization, there must be a governance process set up.

This governance process makes clear to say what the status and importance of a principle are.

Common phases for principles are:

• Proposed
• Under review
• Approved
• Rejected
• Obsolete

Having your principles approved by the CIO or CTO is a very effective way to ensure many projects and new solutions will comply.

When principles are approved at that level, they are adopted more easily in policies.

Documentation of IT Architecture Principles

Every principle should be documented in a good way.

It should be documented who decided to choose this principle and the architecture decision why it was chosen: to solve what problem?

Also, the literature reference is necessary to be documented.

Here is a link to a document template for documenting Architecture Principles

Visualization of IT Architecture Principles

To communicate principles effectively, a principle should be visualized in a Principle Details Diagram.

Next to that, on an IT Landscape Diagram the IT architecture principles can be listed and shown if the IT services and IT components or the IT environment is compliant with the principles.

Links

Read more about principles here:

Interoperability
Architecture Principle Definition
Dragon1 Open Standard Architecture Principle
Dragon1 Principles