Most architects I know, squirm when told by business users that X system needs to be integrated with system Y and perhaps system Z. This is because integration is such a loose word that one could drive a truck through it. Understanding the scenarios is perhaps easier in understanding the scope, feasibility and ultimately the cost.
Functional Integration Requirements should be Use Case Driven
Thus Integration between systems is primarily functional - use case driven. Once all the Use Cases or Scenarios involving the integrated components are known, architects can dig deeper and evaluate the available and required interfaces on the target system. However, it is important to consider non functional architectural drivers, specially in integration scenarios.
Non-Functional Requirements should span Primary and Integrated Components
When thinking about non-functional requirements, we need to think about the integrated solution and not just the newly developed component. This is important, since we might run into a situation where integration with a legacy system is required to serve an architectural driver in terms of availability, stability as well as recoveribility that can not be met without a system overhaul. Alternatively, Design strategies need to be considered to achieve these non-functional requirements.
Think about non-functional requirements for integration - functionally
Like all good non-functional requirements, these integration scenarios too need to be expressed in functional terms with measurable acceptance conditions to ensure these can be designed for and ultimately tested in production.
No comments:
Post a Comment