The Value of BA and Data Architecture Collaboration


When writing requirements (either system or business requirements), it is important to be clear about the data to be displayed or utilized.  If FauxCo specifies that an address is to be displayed to the sales team, the next question should be “Which Address?”  If you leave this detail to the developers, they may pick the most convenient address or make assumptions.   If you work with an address in your prior development task you can easily assume that is the only address and not ask.

For example, there are 3 addresses in the database for a customer record…. These addresses can be historical, future, current… These addresses can be for different purposes, such as mailing, billing, or rating, home office, etc… These addresses can be verified, or from other external sources. A simplistic view would give us, at minimum 9 addresses (1 historical and 1 current of each of the 3 types, all verified) and many, many more when you consider multiple historical addresses and multiple sources of and types of addresses.

-        Should all the addresses be displayed? Are they all current or are some of them out of date?  Should we only display the most recent?  Should we display only one type? Do we need to annotate the addresses when displayed?

-        If the developer chooses to retrieve all 3 addresses, what happens when they are passed on to the downstream system? What if that downstream system can only accept one address?  Are the remaining addresses dropped?

-        What about the types of address? Is this a delivery address, a mailing address, a temporary address?  Is this a pricing address?  (Assuming that pricing changes based on location). A rating address or some other specialty address that is important the business or market segment?

-        Finally, which database was the address retrieved from?  The sales database? (that would be a good assumption, but not necessarily correct) From the service database? Is it from a system of record?

The answers to all these questions are “It depends”. It depends on what the Business need is!   Implementation note - would I actually ask these questions, in order, to a project stakeholder? No, but these are the things that would be running around in my head, based on past experience, related to just one piece of information. 

The story:  At FauxCo, customer data is brought in, verified with the customer, and then sent out to a separate portion of the company that mails out marketing materials for the sales department.  After the system goes into production, the sales team gets calls from long term customers, wondering why they haven’t received information.  In addition, the effectiveness of the campaign isn’t as high as expected.  What happened? Eventually, someone in the mail room notices the increase in ‘returned to sender’ materials.   Three separate teams are ‘looking in to it’.  Finally, the connections are made when the timeframe of the start of problems is about the same as the new system going online.  What was missed and not tested, was the service that returns addresses isn’t able to differentiate between current and past addresses, so all addresses are returned by the service.  In turn, all the addresses are sent on to the separate marketing group.  What was not understood in the system testing was that only one address is accepted as input to the marketing group, and the remaining addresses are dropped.  For the majority of the cases where only one, current, address is sent over, there were no issues. When a company transitioned locations, the old and the new address is sent over, resulting, in some cases, the current address being dropped.

When going through this process, it is important to note that the data sending and data receiving systems need to be on board early.  Having the data related discussions early, in the requirements work, means that your project will have arrived on their radar earlier.  This means work (if it needs to be done) can be planned and orchestrated… rather than an emergency in mid-development. 

As a bonus, this is an opportunity to evangelize the business value with the architecture and system owners. The more your entire team sees the value of the work, and understands the purpose, the less risk you incur.

The other factor involved relates to business processes.  Up front, before development, is a perfect time to understand if there are manual interventions that are in place which can become automated processes.   Process changes often have far reaching impacts in an organization and need to be managed.  This includes changes of the source of data.  [See related post:  Business Process Definition – the Unheralded Skillset]

If you know the data you can retrieve, and where it is, you can work toward additions to this data set or the addition of new services to give you what the FauxCo business needs.   The goal is to achieve consistency and reliability of the data with services.

Finally, understanding the data means a reduction in defects that are potentially missed by the testing team. With an understanding of the data in use, the test cases and the breadth of testing that can be done is made more efficient.  Sample data can be created that is close to reality.  Test cases are written to test specific scenarios that are possible with the data, rather than high level generic testing.  [See related post:  Secret Asset! The BA role and Testing]

With the understanding of the data source, data can be queried for the range of values, data quality can be evaluated and mitigated before go live, and test or sample data can mirror the data in the source systems.  [See related post: Data Quality and the NVISIA BA]

With Agile processes or with shorter iterations, the delivery cycles are also shortened.  In these situations, often a project will forego the data analysis that was traditionally done by the developers or architects on a Waterfall project. We can’t get rid of data analysis completely, but analysis must be done quickly.  If the BA is defining the right system and/or data as part of their role, or in parallel with development work, this reduces project risk.


For Additional Related Blog Post please check out NVISIA's Agile Software Analysis Page

Topics: Agile, Requirements Management

Written by Barb Vandenberg

Barb is an NVISIA Fellow and she started at NVISIA in 1996

Leave a Comment