Examples of architecture principles

Now, we will define principles to which the solution needs to adhere. Each table consists of one principle with these rows:

Name Unified customer experience
Statement Functionalities and responsibilities across all channels must be defined.
Rationale The company must provide consistent and seamless interaction across all touch points with the customer.
Implications The customer will have the same experience, not influenced by a type of touch point.

 

Name Easy to use
Statement The solution is easy to use for customers and employees.
Rationale The more time that is needed to invest in understanding applications, the more time those users need to invest in understanding how to use applications, and the less incentive they have to use them.
Implications The solution must adopt a common look and feel, encompassing all of the components of the solution.

 

Name Maximum benefit
Statement Decisions are made to provide maximum benefit to the enterprise.
Rationale Decisions made for the benefit of a whole enterprise have higher values than decisions made for the benefit of a single part of the organization.
Implications Priorities for solution definition and adoption must be established for the enterprise as a whole.

 

Name Security first
Statement A comprehensive and centrally administered security solution is needed.
Rationale Non-centralized security without a unified view and reporting increases the risk of security incidents.
Implications The company will need to implement centralized security and identity and access management (IAM) solutions.
Name Integrations
Statement All of the systems incorporated in CX solution must be integrated so that they are able to provide unified experience for customers and gain a unified view about them.
Rationale Integrations need to adhere to SOA principles, so that they are able to support the changes to support agile businesses needs in an appropriate manner.
Implications Shift from system-centric to a customer-centric mode.

 

Name Omni-channel support
Statement Functionalities should not be unique to a specific channel—they should be general in nature.
Rationale Time to market (TTM) is much lower if functionalities are general in nature. Functionalities are the same across all the channels.
Implications Common monitoring and management solutions need to be implemented for each of the channels. The functionalities defined need to be feasible across all the channels.