Differentiating Requirements Engineering from IT Architecture

(My post was inspired by the excellent presentation by Gregor Hohpe)

Where does Requirements Engineering end, and where does IT Architecture begin? The boundaries are sometimes fluid, but let’s examine this specific example. The integration between System A and System B, necessary to implement certain functional requirements, certainly falls within the scope of the responsibilities of a Requirements Engineer. They can depict the systems and their relationships in a component diagram. However, determining how the integration is to be technically implemented falls within the domain of an IT Architect, based on the requirements that the RE must gather and specify.

At this point, I would like to emphasize to Requirements Engineers the awareness that they need to understand, on a level abstracted from technology, the architecture of the application landscape and actively contribute to shaping it. For IT Architects, I want to raise awareness that the real action happens in the lines between the boxes (here between System A and B). They should not remain at the level of boxes and arrows but must, based on the functional and non-functional requirements, design the right technical concepts for realizing the integration relationship. In doing so, they must make conscious decisions on aspects including:
– Synchronous or asynchronous communication
– Error handling
– Stateful or stateless communication
– Retries and back-off techniques
– Idempotency
– Data format
– Publish-subscribe, event-driven, or point-to-point integration

An IT Architect should be able to effortlessly categorize and make situation-appropriate decisions for all these buzzwords listed here.