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 that is supported by IT. Constantly there are changing requirements for the IT that is used by the organization.

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 are different 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 always should 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 to the principles, change your current state IT architecture principles so that actually they describe the current situation: what is implementen, complied to, etc.... Any change to the IT environment then will be constrained by the approved IT Architecture Principles. This ensures that any change that is 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 that are currently 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 it is recognized and used in the organization.

Doing that helps you to budget and 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 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 best design 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 the business users with a service level specified.

Another thing these principles tell you is 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 effects the other IT Services.

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

For every IT goal you have 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 blacklisted 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 also 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 in an effective way 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