IT Architecture Principles

In IT Architecture, Architecture Principles are important statements that prescribe the architectural structure of any IT system we build. They ensure that the architecture defined is consistent, coherent and efficient in line with companies' needs and requirements.

An Architecture Principle is a statement that guides how requirements need to be considered. It justifies decisions and provides guidelines for the build of the architecture and solution. The definition of the architecture principles are driven by the business strategy and objectives and they restrict and limits how the architecture is designed while ensuring its requirements are met. 

A company can have over 50 Architecture principles, others have only a few and depends on the Architecture practice maturity as well as how strong its guidance is within the company. We list here the 10 most common IT Architecture principles below:

1. Reuse before buy, buy before build
2. Design with business perspective 
3. Architecture Components are centralized
4. Access to IT systems is authenticated and authorized
5. Application Development is standardized
6. IT solutions are scalable
7. Front-end is separated from back-end 
8. All components have clear ownership
9. Data is provided and maintained by source
10. Reporting and analytical applications do not use operational environment

Each of these principles is discussed in more detail below:

Architecture Principle 1: Reuse before Buy, Buy before Build

This principle guides in first looking at the reuse of existing solutions that are needed when considering new alternatives. When new solutions are needed, consider buying instead of building. 

Rationale

• Improves cost efficiency, reduces the total cost of ownership, reduces complexity and reduces time to market
• Reuse is key to achieving rapid deployment of solutions without major development effort and risk
• Packaged solution’s built in processes are well tested and based on market standards
• But highly customizing packaged solutions leads to high maintenance costs as it is difficult to follow package upgrades and patches once a solution is customized
• Building solutions from 0 requires functional and technical expertise and experience, adds to risk to deployment and in technical performance

Implications

• Look at internal existing solutions within the company before buying
• Architectural components should be centralized and designed for reuse in order to minimize the cost of developing new systems
• Software license agreements and system development contracts should be written to allow for re-use
• If a package solution is chosen, avoid high level (more than 30% of package) of customization

Architecture Principle 2: Design with Business Perspective

Business and functional processes must drive the design, development, operation, maintenance and monitoring of solutions.

Rationale

• To avoid the costs of implementing technology for technology’s sake
• Solution development should be driven by the business
• IT investments will be aligned with enterprise / business strategic goals
• Clarifies responsibilities, ownership and total cost of ownership

Implications

• Process design needs to be a vital part in every solution’s design. Tasks are designed around an objective or outcome instead of a single function
• Organizational change might be required to implement re-engineered work processes
• Always design for operational process monitoring in addition to technology monitoring 

Principle 3: Architecture Components are centralized

Central components are easier to manage since management eases consolidation and standardization.

Rationale

• Centralization eases better management, control and governance, consolidation and standardization and cost
• Centralization lowers total cost of ownership

Implications

• By default architecture components are placed centrally, or if in hybrid cloud environment, it could be dictated that certain components are centralized on both locations 
• The following components are recommended to centralize:
• Enterprise Service Bus (ESB)
• API Management (API Mgt)
• ETL/CDC
• Document Management (ECM)
• Printing Management
• Business intelligence (BI)
• Datawarehouse / Datalake
• Business Rules Engine (BRE)
• Business Process Management (BPM)
• Authentication, user registration
• Operational Tooling: Backup, monitoring, job scheduling

IT Architecture Principle 4: Access is authenticated and authorized

Users are identified and authenticated before using an IT system, and the user identity is used to determine the access rights. People should not have access to data and/or functionality for which they are not authorized. 

Rationale

• Any user should not be able to access functionality or data for which it is not authorized
• A holistic approach needs to be taken to ensure security at all levels to ensure authentication and authorization is properly managed and guaranteed 

Implications

• Users need to be able to identify and authenticate themselves before using an IT system.
• Users´access rights need to properly determined and implemented at application and managed through local or central repository of users  

IT Architecture Principle 5: Application development is standardized

Allow of reuse of existing components, skills and expertise. Reduces time to market through reduced complexity, simplified IT environment. 

Rationale

• Improves cost efficiency through reduced IT skills required to support legacy systems or obsolete standards and reduced set of configurations and components
• Reduces time to market through reduced complexity, simplified IT environment 
• Allow of reuse of existing components and skills

Implications

• Software development standards exist at company level and are available for the largest platforms used
• Governance to leverage development standards is in place through code control and peer review
• Software factories leverage automation to check fo use of application development standards
• Standards include declarative techniques, nomenclature, patterns and use of best practices

IT Architecture Principle 6: IT solutions are scalable

IT systems are selected that can be scaled horizontally or otherwise vertically. IT systems are sized at current volumes and volume growth is monitored periodically. IT and business need to agree on capacity contingency to avoid system failure in case of minor volume increments.

Rationale

• Lifespan of IT systems is at least 3 years and therefore needs to be able to sustain future volumes
• Needs to ensure that IT can accommodate business for organic and non-organic growth and market opportunities
• Scaling and IT solution once built that have not been designed for growth can be costly and requires in most cases detailed a re-engineering of the solution
• Ability to scale systems in future will lower total cost of ownership as hardware cost is typically cheaper in future

Implications

• IT systems need to be able to scale vertically, or otherwise horizontally
• Predictive monitoring on IT resources usage needs to be put in place to alert on possible under capacity
• Adaptive auto scalability can also help to manage dynamic scalability and lower TCO

 

IT Architecture Principle 7: Application Architecture is decoupled

Decoupling front and back is required to provide better agility, independence, flexibility, re-use and better possibilities to scale and tune for performance. 

Rationale

• Front and back are separated from each other as they have different focus, one on customer intimacy, while the other is focused on operational excellence
• Separated independent components, layers and structures allow higher agility on its own and better re-use by other components and systems 
• Autonomy and self-sufficient components allow easier scalability and contribute to higher availability as failures stay isolated to its own components and do no affect complete systems assuming they are well designed

Implications

• Balance in decoupling needs to be analyzed and designed properly to avoid over complexity in applications, component architecture and data
• Design needs to focus first on Horizontal layering and then on vertical decoupling to maintain priorities between robustness and agility

IT Architecture Principle 8: All components need clear ownership

All IT components and systems need to have clear ownership to clarify clear responsibilities, accountability and cost allocation.

Rationale

• It needs to be clear who is responsable and accountable for its design, construction and performance of each component 
• Clarifies who pays for changes in the component

Implications

• All functional components (processes, services, information) and IT components (data, services, applications and infrastructure) needs to have specific ownership 
• The owner facilitates design, maintenance and any changes to the component 

IT Architecture Principle 9: Data is provided and maintained by source

Information must be provided and maintained consistently throughout the enterprise, and should only be acquired once.

Rationale

• Unnecessary intermediate layers of managing data entities should be prevented
• Data quality and performance decreases once data is used in multiple locations due to additional overhead, risk for inconsistencies and potential errors
• Changes to data should be done in same location to avoid replication conflicts

Implications

• Data validation should happen at entry level before data is stored to avoid low data quality
• Applications need to acquire data directly from source  
• Data replication is accepted when properly motivated 
• Applications should be able to expose shared data for re-use by other applications

IT Architecture Principle 10: Analytical and reporting applications should use own datasets

Reporting should have separated environment to prevent interruptions and delays in the operational environment

Rationale

• Doing analytical reporting and analysis impacts data environment performance and could lock source, therefore affecting production and operations
• Building reports and analytical queries could take much time, while operational data could change during same time frame
• Analytical applications carries large risk to change operational data  

Implications

• Need for data replica for reporting and analytical queries 
• Replication mechanism needs to be designed properly in order to have updated and clean data in reporting environment