The Cornerstones of a Project for a Business Analyst

As a business analyst or a functional architect, when entering a new project, you would usually have to read all the available documents to understand the requirements and, most importantly, the context. You cannot just jump into "analyzing" and writing specifications. I believe that a very important factor in the success of any kind of analysis is to be well prepared. This would rise the probability of asking the right questions and to anticipate any risks.

From my experience, it is very important to start from what I would like to call the birdview, and then, work your way down to the details. The utility of this birdview is to have as a macro understanding as possible that would allow you as an analyst, or a functional architect, to be immersed in the context. More importantly, it would give you a map with landmarks that would help you locate yourself anytime you are working on a specific element.

There are two ways that an analyst or an architect would be involved in a project:

1. starting with a new project from scratch or
2. getting integrated in a project that had already started.

In both situations, I believe that there are two elements that are the cornerstone for any work of analysis or architecting.

Data Model

The first element is the Data Model. I cannot stress enough on how this element is vital in any project, no matter how small it is. It gives a list of all the attributes that you have for each object/entity and their different relations. Therefore, any time there is a need to add or receive a new information, we would be able to know if there is already an attribute for it, or if we should add it to the data model.

In addition, a clear vision of the Data Model would allow you to consider any possibility for future extensibility in your design. I remember that in one of my first projects, we had to model a intangible product (a service), and the client did not foresee the possibility of adding another type of products. However, in a future phase of the project, a new need to add tangible product emerged. Because we had a clear and a detailed data model, we were able to design an extremely flexible solution that would add the new product and its variants. Moreover, we took under consideration the possibility to add any newer types of products.

I would say that the most important factor in our success in this project and in solving this issue is that we had a detailed and an up-to-date data model that allowed us to have a clear vision and start working in a timely fashion. This is why I would like to stress on the importance of maintaining the data model at every step during the project.

From a team lead point of view, I recommend to familiarize the developers, and the team members as a whole, with the project's data model because it will make their life easier. From talking to developers that I worked with them, they have confirmed that they consult the data model very often, and they consider it as a vital item of reference for the project.

System Architecture

The second element, and maybe this should be the first, is the System Architecture Diagram. This diagram has a main purpose of visualizing the different interactions between the system being implemented/integrated and the other needed external systems. When we say external systems, we say data exchange. Therefore, having a visualization of the system architecture would give the analyst and the architect an idea of the different data sources.

I would recommend to be very flexible in how to visualize the data exchange between the systems. For instance, having multiple interfaces with the same external system would be a good indication that there is a need for a sequence diagram in order to document and understand the business dependency between these interfaces.

However, to stay on the track of the aforementioned birdview concept, I would recommend to first have a macro-level diagram that would summarize the different external systems that we will need to interact with. This would provide a summary for, and thus a reference to, the dynamism of data in our system, which would clarify the different dependencies and be a reference for future modifications, additions, or expansions.

Having all these systems and their interactions summarized in one diagram would make it much easier for newcomers to understand the context.

Recommendation

I would recommend that:

• If you are starting a new project then there is a need to start creating these diagrams, and
• If you are integrating an already existing project them you need to ask for these diagrams, or create them if they do not already exist.

These recommendations might sound silly, but I have been to projects that did not have these elements (or have them but not maintained), and every time there is a need for a change, a "veteran" needs to be consulted or a reading of long documentations is performed. Either way, I would not recommend these alternatives.

Depending on a person for information does not guarantee getting the information when needed. This person can be on a vacation, sick, or he might even quit.

Reading documentations takes time, while having a diagram is more user friendly and easier to read. I would add that diagrams are easier to update. Therefore, even if documentations are indispensable, adding diagrams is practical. They need to go hand in hand.

Conclusion

Putting the Data Model and the System Architecture Diagram as corner stones of analyzing and architecting a system coincides with considering data at the center of designing information systems. I am a strong believer that data is a main factor in making a lot of decisions during projects, from designing the database to even designing the graphical user interface.

If you think that there are other important elements that would be very useful for a business analyst or a functional architect, do not hesitate to add them in the comment section. I am very interested in hearing your opinion and in benefiting from your experiences.