When documenting business requirements for a multi-application technology-based solution, is it crucial to have proper representation from the impacted systems in each discussion? For example, provider contracts may be stored in one internal application (i.e., SharePoint) but must be exposed to providers via a second application (external portal) after being passed through a third application (internal workflow tool) to manage the contracting process from a workflow perspective while automating the process at the same time. Further complicating the mix is the validation required of a provider’s signature if the option to electronically or digitally sign a contract is provided via the external portal. So right from the beginning, there are four different technologies or systems for which requirements must be gathered and solutions must be developed.
So during the business requirements phase, should a Technical Architect from each potentially impacted system be present to fully understand the coordination required between all systems to meet the end goals being set by business leadership? Or should their involvement be reserved for the system requirements phase and onward? There are pros and cons to each approach. If the Technical Architects are involved right from the start when business requirements are being documented, the discussions may become too technical and the business goals may not be understood in their entirety before decisions are made to change or sometimes even kill the project as a whole. On the other hand, Technical Architects can help the business understand some fundamental issues concerning the end solution being requested, things that may be more costly than alternatives or just technologically impossible.
The benefit of involving the architects early comes in handy when business requirements start specifying technical requirements for applications that are not fully understood by the business users who are requesting the functionality. For example, the business user may need application 1 to launch inside application 2 to make his or her job easier, and may document such a business requirement in the BRS. However, once the BRS is approved and system requirements are being gathered, it may be revealed that the two applications are technologically incompatible and cannot be integrated in this way. At that point, the process of properly changing requirements takes over and slows down the progress of the project itself. In this case, I have seen projects get postponed over months and even years. Every time the project is picked up, the same arguments over the technologies take place but are never resolved because the business requirements were never re-visited with the Technical Architects who could have provided the necessary insight into the impacted systems.
So a lesson learned is that when it comes to business requirements for technology-based solutions, it is crucial to involve the Technical Architects of the potentially impacted solutions to ensure that the end goal being proposed by business leadership is technologically feasible. When to involve the architects depends on the dynamics of the teams. Some companies have architects in the business requirements sessions to ensure no time is wasted asking for solutions that are too costly or impossible. Other companies involve architects after the business requirements have been documented but not officially approved for the next phase. This allows the business to document their requirements without lengthy technical discussions and also allows the architects to provide their input without causing major delays.
