Separation of Concerns for e-business Architects

A brick and mortar retailer may face any number of challenges to implementing a successful online presence.

The separation of concerns for e-business architects refers to the concept of separating different aspects of e-business systems design and architecture into distinct, independent components. The separation of concerns allows architects and developers to focus on specific areas of the system without being distracted by other concerns, and enables more modular and scalable designs that are easier to maintain and update. Some of the key areas of concern for e-business architects include:

1. User interface (UI) design: This involves designing the visual and interactive components of the system that are presented to end users, such as web pages, mobile apps, and other graphical interfaces.
2. Business logic: This involves defining the rules and processes that govern how the system operates, such as workflow, data validation, and decision-making.
3. Data management: This involves designing the database and data storage components of the system, including data modeling, schema design, and data access mechanisms.
4. Integration and interoperability: This involves designing the mechanisms for integrating the e-business system with other systems and services, such as third-party APIs, legacy systems, and cloud services.
5. Security and privacy: This involves designing the security and privacy features of the system, such as authentication, access control, encryption, and data privacy.

By separating these areas of concern into distinct components, e-business architects can more easily manage the complexity of modern e-business systems and create more flexible, modular, and scalable designs. This approach also enables better collaboration between teams with different areas of expertise, such as UI designers, developers, and database administrators, and can help to ensure that each component of the system is designed and implemented according to best practices and standards.

These concerns can overwhelm and confuse an architect, unless they are broken into manageable pieces. For example, the architect can partition the problem based on geographic distribution of the constituents, organizational roles and responsibilities, or application functionality, depending on the perspective under consideration. Separation of concerns allows the architect to reduce overall complexity.

The architect determines the interfaces defined by selecting boundaries. In other words, the interface (or view) also determines how those boundaries will be represented. In the case of the display of information (information management), what is displayed through access privileges determines how a message is presented and interpreted by an end user. In the case of Enterprise Resource Planning (ERP) solutions, boundaries are created by traditional business functions such as HR, Strategic Ledger, Workflow, Order Entry. These packaged back-office solutions provide a quick means to jump past competition who were not using automated business ERP systems. Another example is linking a company's existing ERP solution directly into their supply chain providers via a VPN, or secure socket connection. Drawing boundaries and/or expanding boundaries can push a company forward in terms of locking into a relationship, increasing flexibility for the company, or increasing timeliness between two companies or processes. Architects and package selection: The architect's involvement with package selection includes:

In partitioning the problem space, the architect determines boundaries. For example, if all she cares about is how the whole application performs, she will not care about details inside. If she cares about how pieces work, she will adjust her boundary accordingly.