Analyst’s role in SDN projects

What is the role of an analyst? What do they do? Is the analyst needed in the project? These questions come up quite often in various organisations, articles or at conferences for analysts. The answers vary depending on the role of the person answering, the habits of the organisation, the way projects are managed or their size.

When looking for a job as an analyst, you will find out that the range of duties that can be performed on this position in each company, and even within the same company but during different projects can differ quite a bit. First of all, when talking about the position of the analyst we can distinguish: business analyst, system analyst and IT analyst.

However, these terms, too, are often used interchangeably, or used with different meanings.

There are times when smaller projects lack a designated analyst, which is why some believe that such a person is not necessary. However, that is not completely true because the other members partially play the role of the analyst in such a case. Regardless of whether we have the analyst in the project or not, it is necessary to develop requirements, define business processes and prepare the required documentation. Nevertheless, without the analyst, there will be a lack of additional insight into whether the needs of the business are well understood by the developers, if certain functionality has been overlooked and consequently whether the product in development is what the business wants.

The role of the analyst in agile working methods and methodologies

The stereotypical role of the analyst in IT comes strictly from the cascade methodology or so-called waterfall.  Unfortunately, even today this method of project management is still equated with the analysis stage and the extensive documentation that needs to be prepared. Arrangements with the client, which should be unchangeable, as well as long implementation time of new solutions caused that the project was becoming unprofitable and inflexible. Newer approaches to running projects, the “more agile” ones, are trying to solve these types of problems. Hence, the role of documentation has been minimized, the focus has been set on working and delivering the solution so that the customer could see the results of the work from the first stage and participate in its creation. But does this mean that every project can be carried out this way? The metaphor often used for this question is “building a bridge”. I don’t think anyone can imagine building a bridge without having access to a full, detailed documentation that from the very start provides for the use of suitable materials. Either way, standard methods are becoming obsolete in the IT world. So what about the analyst?

In the theoretical aspects of the Agile methodology, the analyst is not dead, only their role is perceived differently. In the standard approach the analyst was often confused with the scribe who was supposed to create 500 pages of documentation, while in case of agile frameworks their responsibility has been clearly defined.

Source: Agile Buisiness Consortium, Chapter 7: Roles and Responsibilities

DSDM (Dynamic Systems Development Method) shows the role of the analyst as the bridge between the business part and the technical part (the only part of the “snowman” – DSDM diagram – that has two colours) and the connection between the project level and the solution development team (between the head and the body). It can be said that this role becomes the backbone of a project that has to reconcile many various points of view (which can be translated into many different needs of various teams and user groups).

DSDM places the analyst near the development team while AgileBA promotes the analyst outside the teams but does not limit the variability of the function. Thus, in practice, several analyst roles can be distinguished, as described below.

Analyst as a Product Owner Assistant

In practice, the analyst supports creating user stories as well as managing the product backlog, collects data and helps to arrange the implementation plan. Good information flow is the foundation of collaboration with the Product Owner since the situation where each of them has their own version of truth cannot happen.

Analyst as a member of the Scrum team

In this case the analyst executes the project in sprints, which enforces time constraints on their work and may impair its effects. Faster doesn’t necessarily mean better. The granularity level of the analysis must appropriate so that the amount of work fits into the given sprint. This approach encourages the analyst to go beyond their primary role and take on other tasks like testing or sometimes even coding. Working closely and constant contact with developers is undoubtedly beneficial.

Analyst outside the Scrum team

The analyst works independently from the software development process, thanks to which they have more research capabilities and can revise their analysis more closely. The analyst is not burdened to such extent with the deadlines arising as a result of sprints taking place every couple of weeks. Unfortunately, the biggest drawback of this approach is the lack of close cooperation with developers and good understanding of their needs.

Analyst as a Product Owner

The analyst in their primary role is responsible for the value of the solution delivered to the stakeholders, has subject matter knowledge, knows the needs, requirements and problems concerning the solution that is being created. That’s why in practice they are the one who most frequently takes over the role of the Product Owner, if necessary. Obtaining decision making power, defined as the arrangement of tasks in the backlog, their priorities and order of execution, gives the possibility to deliver value in the built solution as soon as possible. Additionally, a good analyst with high facilitation skills naturally takes on the role of the Product Owner and thus takes into account the interests of many user groups, builds relationships with them, pursues conversations and negotiates.

Analyst in SDN research and development projects

As you can see above, on any given project, the analyst’s role is a variable and there is no single, strictly held position. Each project needs to establish this internally and appoint people to carry out the project-wide analysis. In order to ensure the widest possible range of competencies in SDN projects, analysts together with architects have created a group that is at the same time an independent team (comparable to “Analyst outside the Scrum team”) and is a support for the Product Owner (comparable to “Analyst as a Product Owner Assistant”), whereas the area in which they work (marked in green) is presented in the figure below, layered on the development process.

Analyst’s work area in an SDN project

In SDN projects, analysts together with architects are responsible for preparing data, based on which the developers can implement the given functionality. The first analyst’s task with respect to a given functionality is to develop requirements enabling the architect to create a high-level description of the solution. In the light of the high-level description, analyst develops user stories and complementary test cases, which are useful for the architect’s low-level description of the solution, created together with the development team.

Requirements development

This is the first task performed during the implementation of the functionality. In order to properly carry on the task, it is necessary to know the business needs that we want to achieve. Requirements are developed for this purpose. This includes functional and non-functional requirements.

The developed requirements often concern the whole functionality that is completed in several iterations (within several epics), therefore the requirements are correlated with given release or epic. Additionally, the requirements are verified in accordance with the MVP (Minimum Viable Product) defined for the project.

Architects verify the requirements and create high-level solutions in line with them.

Creating user stories

The architects’ vision of the solution concerns its full functionality.  Unfortunately, based solely on that it is often difficult to make time estimations of the works related to the implementation of the given functionality or to define relevant developers’ tasks. User stories are created to facilitate the understanding of a given problem (requirement), to indicate the possibility of breaking it down into smaller steps and to sequence their execution.

The role of the analyst and working in this position is not simple at all. Often, you need to develop your own system of work tailored to the needs of a particular project. This is also how it is implemented in SDN projects. Division of labour is not a rigid criterion and we often step into the role of other responsibilities. In addition to the framework that has been developed we need to engage into lot of work related to familiarising ourselves with new standards on the market, the possibilities of their application, as well as researching ready-made solutions. With the whole team, we research, search, verify and design a solution to make a telecommunications revolution and create the “network of the future”.