This toolkit provides a catalogue of architecture principles that can be used as a source of inspiration by practitioners in the field of architecture. We have classified the architecture principles into five categories, listed below.
Business Unit Are Autonomous
Rationale: Autonomous business units can adapt to changes quickly because they do not need to align with other business units. Autonomous business units can be separated more easily from a financial and organizational perspective, and eases future restructuring.
Implications: Business units have their own profit and loss, based on which they are evaluated. Business units can make their own decisions and investments.
Customers Have a Single Point of Contact
Rationale: It is much more customer friendly when the customer can direct all his communication to a single point, is serviced directly, and does not have to contact multiple people.
Implications: There is one access point for customers, which may be a customer contact centre or a dedicated person for important customers. The access point attempts to shield the customer from the internal organization, and handle the request completely
Stock Is Kept to a Minimum
Rationale: Keeping stock at a minimum saves costs since unnecessary investment, storage and transport is prevented. A small stock allows quality problems to be detected and solved quickly, so that the quality of additional delivery increases.
Implications: Items are ordered on-demand when possible. The stock is registered and pro-actively monitored in order to prevent it falling below certain thresholds.ll de
Processes Are Straight Through
Rationale: Straight through processes strive to deliver the output with a minimum delay, which increases customer satisfaction. Straight through processing aims to streamline processes and make them as efficient as possible.
Implications: Buffers between activities are prevented as much as possible. Routine processes are automated.
Processes Are Standardized
Rationale: Standard processes are repeatable, predictable, scalable and more efficient.Process standardization is often required in order to comply with certain legislation or quality standards.
Implications: A standard process exists and is based upon current and best practices of departments. All departments adhere to the standard process.
Management Layers Are Minimized
Rationale: Elimination of management layers minimizes overhead costs. By eliminating management people tend to take more responsibility for their work, which increases the quality and efficiency.
Implications: There are as few layers of management as possible. The ultimate objective is to have self-directed teams throughout an organizational unit with no layers of management at all. People who perform the actual work have responsibility for making decisions.
Tasks Are Designed Around Outcome
Rationale: By making workers responsible for the delivery of the outcome they feel more involved and tend to take more responsibility for their work, which increases the quality and efficiency. Giving people more responsibility also increases their job satisfaction.
Implications: Tasks are designed around an objective or outcome instead of a single function. Workers have autonomy over when and how to perform the tasks they are lined up for.
Routine Tasks Are Automated
Rationale: Routine tasks require relatively little specific knowledge and can be automated fairly easy. Automated tasks are more efficient in time and costs, and less error-prone than manual tasks.
Implications: The knowledge required to perform certain tasks is analysed, and embedded in an IT system when it can easily be formalized. Employees are assigned to tasks that require complex knowledge.
Primary Business Processes Are not Disturbed by Implementation of Changes
Rationale: Primary business processes are the core of the organization, and disturbances in these have a major impact on the organization. Organizations change continuously, and frequent disturbances are unacceptable.
Implications: New processes and systems are not employed until they have been tested and approved. Downtime of applications is minimized during deployment, and preferably performed outside business hours.
Components Are Centralized
Rationale: Central components are easier to manage since management can be targeted at one location. Centralization eases consolidation and standardization. Centralization can benefit from economies of scale.
Implications: Components are placed centrally, unless requirements dictate a decentralized approach.
Front-Office Processes Are Separated from Back-Office Processes
Rationale: Front-office processes are different from back-office processes: the first is focused on customer intimacy while the other is focused on operational excellence. Front-office processes require different skills and knowledge than back-office processes. Separating back-office processes from front-office processes allows for reusing these back-office processes.
Implications: Processes are dedicated to the front-office or back-office. Disengagement between front-office and back-office processes is clearly defined. Front-office applications do not contain back-office logic.
Channel-Specific Is Separated from Channel-Independent
Rationale: A lot of business activity is independent of the channel (telephone, mail, Internet, office) through which customers are contacted, and can be shared for multiple channels. Data are ideally available through all channels, which is only possible when the data are managed in channel-independent processes.
Implications: The activities at the borders of an end-to-end business process are specific to a channel and communicate with other activities in a channel-independent format. Applications have dedicated components for channel-specific processing that interface with components that provide channel-independent business logic and data.
The Status of Customer Requests Is Readily Available Inside and Outside the Organization
Rationale: Customers want to know when to expect a response to their request. The status of a customer request is also important for the internal organization, since service levels must be met.
Implications: The status of customer requests is administered in a central administration and updated when changed. The up-to-date status is available to customers via electronic channels (telephone, website).
Data Are Provided by the Source
Rationale: When those who have the data also provide them, unnecessary intermediate layers (e.g. people or IT components) are prevented. The performance and reliability of the data also increases, since each link in the chain adds performance overhead and potential errors.
Implications: Electronic forms are provided to customers to enter their requests. Applications acquire data from the source application.
Data Are Maintained in The Source Application
Rationale: Maintaining data in multiple places introduces risks of inconsistencies, which is undesirable at best. It is inefficient to gather similar data from multiple places and resolve any potential conflicts.
Implications: The source application for all types of data is known.Applications acquire data from the source application. Replication of data is accepted when properly motivated.Replicas are never updated, unless a controlled synchronization mechanism is in place. Data are not copied before it is finalized.
Data Are Captured Once
Rationale: It is inefficient and user-unfriendly to ask for the same data twice or more.
Implications: Before acquiring data it is first determined whether the data are already available.Data that are already available are pre-filled in forms. Applications expose shared data for reuse by other applications.
Data Are Consistent Through All Channels
Rationale: This enables sharing data more effectively, through all channels (e.g. branch, Internet, mail). It enables users to work at their preferred appropriate time, location, and device for given task.
Implications: Data updates are shared across channels. Data are stored in a channel-independent format.
Content and Presentation Are Separated
Rationale: Content that is separated from presentation can be reused in multiple channels.If content and presentation are separated they can be authored independently from each other.
Implications: All data that are acquired are translated to a presentation independent form. Separate authoring environments exists for content and presentation. Dedicated IT systems and/or IT components are used for enriching content with presentation data.
Data Are Stored and Exchanged Electronically
Rationale: Storing data in electronic form makes sharing the data much easier. Data that are available electronically can be manipulated and retrieved in structured form and make it available for automated handling in IT systems. Electronic data exchange is much more efficient and less error-prone than manual exchange.
Implications: Manual re-entry and/or exchange of data is prevented, especially when volumes are high. Physical data are transformed in electronic form, structured and attributed with the proper meta-data.
Data That Are Exchanged Adhere to a Canonical Data Model
Rationale: Using common data definitions prevents unnecessary translations and semantic differences. A Canonical Data Model standardizes the definitions of data that are exchanged within the organization.
Implications: A Canonical Data Model exists and is managed centrally.All messages exchanged between applications use the schemas that codify the Canonical Data Model. Applications that are unable to adhere to the Canonical Data Model rely on integration middleware to translate their application-specific data model to the Canonical Data Model.
Data Are Exchanged in Real-Time
Rationale: Users expect the most recent data in most of their work processes. Decisions made based on old data have a lower accuracy and may lead to errors and/or inconsistencies.
Implications: All changes to data are processed immediately. Data changes are propagated immediately to all other IT systems that have a copy of the data. Batch processes are prevented.
Bulk Data Exchanges Rely on ETL Tools
Rationale: ETL tools provide the most efficient solution for bulk data exchanges, minimizing the time needed for the exchange. ETL tools are proven solutions for bulk data exchanges.
Implications: Data that are larger than 1 MB are exchanged using ETL tools.
Documents Are Stored in the Document Management System
Rationale: This allows finding and retrieving documents from one location and sharing them between workers. Electronic storage of documents prevents physical handing of documents. Generic measures for security and archiving the documents can be enforced by the document management system.
Implications: There is a document management system that is available to all users. All incoming physical documents are scanned and stored in the document management system. All outgoing documents are stored in the document management system. There is no other location than the document management system for storing documents. Records management functionality is configured in the document management system.
Reporting and Analytical Applications Do Not Use the Operational Environment
Rationale: Reporting from a separate environment prevents interruptions and delays in the operational environment. Reports often require data that are spread over multiple applications. Analytical applications require their own data, and using a separate environment prevents polluting the operational data.
Implications: A data warehouse environment is created that is loaded periodically. Reports are not based on current data, but on data that have been loaded some time earlier.
Applications Have a Common Look-and-Feel
Rationale: Inconsistency leads to a lower productivity and irritation of users. A consistent user interface optimally supports the business process.
Implications: User Interface guidelines exist and are applied consistently.Applications are custom developed to support the user interface guidelines. The application of packaged applications is limited.
Applications Do Not Cross Business Function Boundaries
Rationale: This allows business functions (e.g. procurement, sales, production, et cetera) to operate as independently as possible. It shields business functions from changes in other business functions.
Implications: Applications that provide functionality in multiple business functions are split into multiple applications. Packaged applications have separate instances for separate business functions. Dependencies between business functions are clearly defined and drive integration.
Applications Respect Logical Units of Work
Rationale: Business processes consist of logical units of work that need to succeed or fail as a whole. Inconsistency of data should be prevented. Logical units of work provide well-defined moments in time in which data are consistent.
Implications: Applications use technical transactions or other mechanisms (e.g. compensating actions) to ensure that all functionality related to a logical unit of work is committed as a whole or rolled back otherwise. Application functionality (e.g. application services) is defined to resemble logical units of work.
Applications Are Modular
Rationale: Modularized applications are much easier to develop, maintain, reuse and migrate than monolithical applications. Modularized applications are also more reliable since changes have a more localized and therefore predictable impact.
Implications: Applications are decomposed into components that have limited and acyclical dependencies on other components. Application components are units of configuration management and deployment. Application components have a logical and documented layered structure, where lower level layers are independent of higher level layers. Presentation logic, process logic, business logic and data exist in separate layers or components.
Application Functionality is Available Through an Enterprise Portal
Rationale: A portal provides functionality that is targeted at the role and personal preferences of the user, optimally supporting users in their work. A portal provides a single point of access, and integration of functionality at the glass, relieving users from manually finding and integrating functionality. A portal can provide single sign-on to users.
Implications: There is an Enterprise Portal that provides access to all application functionality. All applications are portal-enabled, exposing their functionality as portlets/web parts.
Applications Rely on One Technology Stack
Rationale: Components within an application are tightly coupled. By using one technology stack development and maintenance is more efficient since the knowledge required and transformations needed are minimized. Integration within one technology stack is much more efficient and leads to a better performance.
Implications: One programming language, development environment, application server and database management system is defined as standard and used for all components within the application. There is no need for integration of middleware and/or Web Services within the application.
Application Interfaces Are Explicitly Defined
Rationale: Explicit interfaces ensure that dependencies between applications are made explicit. Explicit interfaces are needed in order to determine whether the interface fulfills functional and non-functional requirements. Explicit interfaces are a prerequisite for change control, and thereby a controlled evolution of application interfaces.
Implications: There is a functional and technical specification of all application interfaces. Application interfaces are administered centrally.
Proven Solutions Are Preferred
Rationale: Proven solutions minimize operational risks (stability, performance, security) because they have been tested in multiple situations. Proven solutions have a large installed base, which provides much more confidence in current and future support of the product.
Implications: Solutions are only acquired when there are multiple references of clients in the same region and with a similar business. The track-record of the supplier is assessed before solutions are acquired.
IT Systems Are Scaleable
Rationale: Future volumes are hard to predict, but must be supported.Enable the business to adapt to unpredictable market opportunities. Buying IT systems for the maximum future capacity is relatively expensive since the capacity is not needed directly and capacity will be cheaper in the future.
Implications: IT systems are selected that can be scaled horizontally, or otherwise vertically. IT systems are sized at the current volumes, and volume growth is monitored periodically. ICT and business units need to agree an appropriate over-capacity level, to cater for short-term, unpredicted business growth requirements.
Only in Response to Business Needs Are Changes to IT Systems Made
Rationale: This will foster an atmosphere where the information environment changes in response to the needs of the business, rather than having the business change in response to IT changes. This is to ensure that the purpose of the information support is the basis for any proposed change. Unintended effects on business due to IT changes will be minimized.
Implications: Changes in implementation will follow full examination of the proposed changes using the enterprise architecture. We do not fund a technical improvement or system development unless a documented business need exists. Change management processes conforming to this principle will be developed and implemented.
Components Have a Clear Owner
Rationale: Without a clear ownership of components it is unclear who decides in and pays for changes in the component. Changes to components should be streamlined in order to ensure their quality and (re)usability.
Implications: All business components (processes, services, information) and IT components (data, services, applications and infrastructure) are assigned an owner. The owner has a clear stake in the component and has budget for adapting the component to requirements and needs.
IT Systems Are Standardized and Reused Throughout the Organization
Rationale: Standardized systems are cheaper because redundant investments are prevented, and economies of scale can be exploited. It is easier to focus attention, resources, knowledge and investments in a standardized environment.
Implications: Standards are determined for all IT functionality.IT systems do not provide functionality that overlaps with other IT systems. IT systems are reused throughout the organization by all business units. Concessions may be needed in user requirements.
IT Systems Adhere to Open Standards
Rationale: Open standards ease the integration of IT systems. Open standards prevent a vendor lock-in.
Implications: Standards are selected based on their maturity and relevance to the organization. Support for open standards is an important criterion in the acquisition of IT systems.
IT Systems Are Preferably Open Source
Rationale: Open source software prevents vendor lock-in. Open source software is much cheaper to procure and maintain than commercial software.
Implications: When functionality of an open source system is equivalent to commercial systems that are available in the marker, the open source system is selected.
IT Systems Are Available at Any Time on Any Location
Rationale: People perform their work at various locations (in the office, at the client, at home) and at various times (day and evening) and expect to be supported in all these locations. It is inefficient to reserve fixed office space and facilities (e.g. workstations) for employees when they are mobile.
Implications: Software is server-based, allowing access to them from all locations. Strong authentication services are available to ensure secure access to applications from other locations.
IT Systems Are Sustainable
Rationale: IT contributes significantly to the pollution of the Earth due to energy consumption and the generation of waste. There is a general awareness that measures need to be taken to protect our natural resources and prevent global warming as much as we can.
Implications: Energy consumption and the usage of environment-friendly materials are criteria in the acquisition of new IT systems. Energy consumption is explicitly taken into account in the design of IT environments such as data centres.
Processes Are Supported by a Business Process Management System
Rationale: Explicitly defining and automating processes eases process standardization. Automation of business processes increases efficiency. This allows for changing processes independently from application functionality. Business Process Management systems provide management information, and thereby provide insight in process execution.
Implications: Business processes are modeled explicitly using business process modeling tools. Business processes run in the Business Process Management system.
Presentation Logic, Process Logic and Business Logic Are Separated
Rationale: These forms of logic are inherently different, and it should be possible to change them independently. By separating these forms of logic they can be reused independently from each other.
Implications: Presentation logic, process logic and business logic are implemented in separate application components. Components have a layered dependency structure, with minimal dependencies. Data are only managed in components that implement the business logic.
IT Systems Communicate Through Services
Rationale: Services can be reused, which leads to less interfaces and is thus much more efficient. By reusing services new solutions can be assembled much faster, resulting in a shorter time-to-market.
Implications: Services are defined for all data and functionality that IT systems provide to other IT systems. Services are defined as reusable as possible, shielding implementation details and adhering to interface standards, formats and protocols. Services are published in a service directory where they can be found for reuse.
Reuse Is Preferable to Buy, Which is Preferable to Make
Rationale: Reusing IT systems that are already available is often the simplest and cheapest solution, assuming that the IT system can be reused. Custom development of IT systems is often very expensive, especially maintenance is taken into account. Buying standard IT solutions is cheaper than custom building them, as long as they are not adapted, and maintenance is left to the supplier. Use available expertise from the market.
Implications: When functionality is required existing IT systems in the organization are first evaluated and used, unless they do not exist and/or are a mismatch to the required functionality. Package selection criteria exist. Custom developing systems is the last resort and should be prevented as much as possible.
IT Systems Support 24x7 Availability
Rationale: Channels such as the Internet require functionality to be available around the clock. It should be prevented that applications have inherent restrictions to being available through these channels.
Implications: Batch and support windows are minimized.Service level agreements are aligned to 24*7 availability requirements. Sourcing partners have been selected based on the ability to provide 24*7 support. Applications support hot backup.
IT Systems Are Selected Based on a Best-of-Suite Approach
Rationale: A suite of IT systems from one vendor provides the highest level of integration, and any integration problems that arise should be solved by the vendor. Buying a suite from one vendor provides opportunities to get a high discount.
Implications: A limited number of vendors that provide broad suites have been selected strategically. There are environments specifically targeted to the vendor suites.New functionality required is realized with the appropriate IT system in the suite.
Sensitive Data Are Exchanged Securely
Rationale: The confidentiality and integrity of sensitive data needs to be ensured. Security attacks are often performed from inside the organization.
Implications: Data are associated with a security classification. Sensitive data are encrypted when transported across the network, preferably at the content level. Sender and receiver mutually authenticate before sensitive data are exchanged.
IT Systems May Under no Circumstances Revert to Insecure Mode
Rationale: Confidentiality and integrity must be maintained under all circumstances.When many systems fail in any way, they revert to insecure behavior. In such systems, attackers only need to cause the right kind of failure, or wait for the right kind of failure to happen.
Implications: Systems that fail must not accept any further inputs. Operational Management measures must be taken to detect system failure and act timely.
Management of IT Systems is Automated as Much as Possible
Rationale: By minimizing manual intervention costs are reduced. Human tasks are error-prone, and self-management may decrease error levels.
Implications: All systems that require remote operation and system management must be network attached and can be managed remotely. Systems must be capable of measurement by providing metrics and facilities for instrumentation. System management functionality is included in applications, including the ability to recover from errors and provide degraded functionality in case of interruptions.
End-to-End Security Must Be Provided Using Multiple Defensive Strategies
Rationale: Confidentiality, integrity and availability must be ensured whenever one layer is compromised. Security that is not end-to-end might be compromised in the intermediate layers.
Implications: Multiple security measures are taken to secure an object. Multiple security zones are defined in the network. Data that exchanged is encrypted at the content level, rather than at the transport level.
Access Rights Must Be Granted at the Lowest Level Necessary for Performing the Required Operation
Rationale: Providing users or systems with more access rights or for a longer period than strictly necessary introduces unnecessary risk of abuse. Management of permissions is more complex when excessive access right are granted because they do not match the rights needed.
Implications: Users do not log in using administrator accounts. Access rights are based on the role of the user. Access should be granted only for the amount of time necessary.Access rights that are no longer needed are revoked.
Authorizations Are Role-Based
Rationale: A role based authorization model is less sensible for changes in the organizational structure. Users with the same role usually have the same authorizations, which makes a role-based model more efficient to maintain.
Implications: There is a central administration of roles, which is the basis for all authorizations. Roles are related to responsibilities and not to specific applications.
The Identity Management Environment Is Leading for All Authentications and Authorizations
Rationale: The identity management environment ensures that authorizations are defined and enforced in an efficient, reliable, traceable and manageable manner. The identity management environment enforces that all access to IT systems is authenticated, that authentications are performed uniformly and that users have to authenticate only once.
Implications: There is a central administration of identities, roles and authorizations.There is a provisioning environment that propagates user, role and authorization data to target environments. There are authentication and authorization services that enforce access to IT systems.
Security Is Defined Declaratively
Rationale: Security is a cross-cutting concern that should be defined only once for maintainability and consistency reasons. Security should not depend (solely) upon the discipline of application developers to embed security controls in programming code.
Implications: Security functionality is not hard-coded in programming code. Infrastructural components are used for authentication and authorization that enforce security policies.
Access to IT Systems Is Authenticated and Authorized
Rationale: People should not have access to data and/or functionality for which they are not authorized. Preventing unauthorized access requires measures in all IT systems involved (a chain is as strong as its weakest link).
Implications: Users are identified and authenticated before using an IT system, and the users identity is used to determine access rights. Automated access to IT systems (e.g. through electronic messaging) also relies on authentication and authorization.
Integration with External IT Systems Is Localized in Dedicated IT Components
Rationale: Using dedicated IT components for integration with external IT systems is more efficient and manageable since interface costs are spent only once, and changes can be limited to one component. Dedicated IT components can provide a first line of defence for security attacks. B2B integration is often more complex due to special interchange protocols, formats and agreements which require dedicated middleware.
Implications: Applications contain IT components dedicated to integration in the business logic layer, which can be used from the presentation layer. IT components are selected and used to support the interchange protocols, formats and agreements that are needed for integration with other organizations.
Application Development Is Standardized
Rationale: Application development is labor intensive, error prone and relatively costly. The business should focus time, money, people and knowledge on business innovations.
Implications: Software development standards and guidelines exist. Standard software factories, based on software generation techniques are employed. Declarative techniques are used for defining logic, such as business rule and process languages.
All Messages Are Exchanged Through the Enterprise Service Bus
Rationale: The Enterprise Service Bus shields IT systems from changes in other systems, such as changes in location, data model or technology. Manageability of message exchanges increases since all exchanges are defined in the bus, and the bus can guard the quality of service. Message exchanges defined in the bus can be reused by other applications.
Implications: Applications do not send messages directly to other applications. An additional layer of definition is introduced for all message exchanges.
Rules That Are Complex to Change Are Managed in a Business Rules Engine
Rationale: Changing business rules in a business rules engine is easier than changing rules that are hard-coded. Business rules engines require less technical knowledge and can be used by business analysts. Using business rules engines eases the reuse of business rules in different applications.
Implications: Business rules are explicitly identified and documented in the analysis phase.The complexity and changeability of every business rule is determined. Separate business rules engines exist for all relevant types of business rules (e.g. process rules, accounting rules, acceptance rules). The business itself can change business rules, but they are tested before they are implemented.