Answer

In classical systems analysis, it is important to accurately define where the boundaries of the designed system lie — which functions are implemented within it, what is delegated to external services, and how integration with them is constructed. In large projects, this stage is critical for simplifying the architecture and minimizing risks.

Key Features:

• System boundaries are defined by business functions, areas of responsibility, and data composition.
• Regular analysis of existing services and interfaces is necessary to avoid duplication.
• It is important to develop integration scenarios, formats, and entry/exit points.

Background of the Question

As early as the 70s and 80s, it became clear during the analysis of large systems that incorrectly chosen boundaries led to costly integration modifications and chaos in the architecture.

Problem

Too broad or narrow system boundaries complicate maintenance, increase the number of integrations, and cause data inconsistencies.

Solution

Use the Context Diagram technique and the Service Responsibility Matrix to allocate functions and responsibilities. Focus on business goals so that the system boundaries align with the real structure of the company.

Tricky Questions.

Should one always strive for maximum autonomy of the created system?

No, sometimes it is more efficient to delegate certain functions to other systems to avoid duplication.

Should the analyst define data formats for all integrations before starting implementation?

No, this is done at the high-level design level. Detailed formats are worked out together with architects and integrators later on.

Is it very bad if the same function is implemented in several systems?

This leads to duplication, synchronization costs, and loss of data integrity, so such overlaps should be avoided.

Common Mistakes and Anti-Patterns

• Not developing the context diagram.
• Ignoring already existing company services.
• Immediately diving into technical details of integrations without defining business boundaries.

Example from Life

Negative Case:
The system was designed without considering the company's structure, failing to clearly define which functions would be internal and which would be in other services.
Pros: quick start of design, minimal resource expenditure. Cons: ended up with many duplicative integrations, ongoing data exchange issues, and bloated architecture.

Positive Case:
The business analyst developed a context diagram, aligned the system boundaries with the business and architects, and minimized integration interactions.
Pros: transparent architecture, fewer integration bugs, convenient support. Cons: significant preparatory work at the start, expertise required on all related systems.