Real life separation of concerns

One of the most frequent questions faced in the process of software design is "Where do I locate a given piece of logic?" In fact, most of the practice of software architecture is focused on this very question.

The concept of Separation of Concerns leads one to think carefully before implementing any given solution out of a purposeful intention to reuse and compartmentalize the parts and pieces of a system. We want loose coupling, for sure, but in real life there are additional considerations that must be taken and applied to the architecture.

In working with a client recently, I found myself pondering where to perform a data retrieval task as part of a larger process. My solution included a Workflow that called out to an API. That separation of concerns was no problem - the API was available to any client. The question arose in regard to whether or not the Workflow package should manage retrieval of the source data for the API, or whether the Workflow should be passed the source data as a parameter.

Considering Scale
The primary discussion about this architectural question centered around whether or not the Workflow would be used to manage additional API calls, or the integration with a single API. If the former, then it would make sense to retrieve data externally, and pass it to the Workflow with an indicator of which API to call. However, if this was a single-purpose utility, then there is no risk of embedding the data retrieval in to the Workflow itself, making a direct reference to the Business Objects and Data Access layers specific to the application domain.

Considering Time
Another contextual element in this decision was the project time line, and whether it would afford a more significant effort in order to provide a more flexible multi-API implementation. In my experience the additional time may be just enough to push a team towards making a shorter-term decision, under the premise that when time permits (perhaps in the next sprint) a revision of the initial decision can be implemented.

Considering The Deployment
Finally, while I strongly believe that practicing good architecture should hold true in any project, it has to be acknowledged that sometimes a project scope would be prone to over-architecting due to the particularities of the project. Certainly a one-off utility that can be agreed to only operate in a given domain may not require an architecture that leads to highly portable outcomes. As a team, it is important to establish a set of criteria for what determines whether a project or component is a one-off or not.

In the end, we decided to pass in data to the Workflow in anticipation of future data sources and applications also leveraging the Workflow. All the same, I felt this was a good example of how to evaluate the architectural needs in the proper context.