From the BA perspective, data can no longer be an afterthought! Successful projects think about the data during the business requirements process, in both iterative and agile projects.
First, when aligning Business needs with IT infrastructure, data is an important component of these discussions. With a need for faster time to market of ideas and systems, the task of writing business requirements and then passing them to IT to be vetted, before design can begin, chews up valuable time and resources. Not to mention the unplanned re-work when IT tells the Business “I can’t build what you asked for." See related post: Adding Agile best practices into your non-Agile processes] [See related post: Agile, Iterative, Waterfall – picking and choosing the best practices that work for your organization]
The Business view is often strategic and based on the systems or information that they, the business, already has access to. To a person not versed in the system infrastructure, the location of the data, the systems of record, and the acquisitions/migrations that are ongoing within the organization, it may seem like a simple request to match the FauxCo sales information, with the service records, and “ta da”… create a forecasting system.
When the vision is only on the end user pieces of data, a request to build something (e.g. a forecasting system) sounds easy. If it sounds easy, the timeframe for completion is shortened, the budget is small, and the requirement document is simple. Is there any wonder that there is a mismatch when the Architecture, IT or development team gets the project specs?
The BA should care about the Data - The BA should be asking:
- Is the needed data in the same system or different systems?
- Are these systems of record? (also, are these the current and accurate pieces of data)
- What key identifiers can I use to retrieve the data?
- What fields do I need, and what if I don’t have key pieces of information (failure processing)
- Are there services I can use to retrieve the data (if not, will the BA write service requirements document?) [See related post: Writing Service Requirements]
Rather than accepting at face value that all the needed information is integrated, the BA will help determine up front where the missing pieces are and collaborate with the business and architecture teams to determine exactly what can be built and a plan for future expansion when the pieces are available. After all, you can’t build with what you don’t have! [See related post: The Value BA and Data Collaboration]
For Additional Related Blog Post please check out NVISIA's Agile Software Analysis Page