Architecture Principles
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. Contact us if you want to suggest a new principle.
-
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.
-
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
-
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
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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).
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.