Does it make sense to draw business processes when designing a software solution

Question

We are working with the design of the software. It is piece already working developed from scratch again. My managers are telling me to draw the business processes. I doubt in this due the fact that I know this piece already and I can start the design and prototype development immediately. Do you see business process as good starting point when designing software ? This is something we can present to the stakeholders. They invest money, so maybe this way they can understand what we are doing. They understand the picture of the business process.

My skepticism is for following reasons:

1. I already know the processes, so I do not need to draw them. I agree that other participants might not know them;
2. I observed that sometimes first software is created and next processes are drawn as part of documentation which seems too late for me;
3. processes are imperfect way of presenting the design; I need to described additionally the data structure, the logic, the user interface; the interface with 3rd party system, etc.

I agree that having the processes drawned we have possibility to present the plan to customer representative. We can also decide on the scope by saying that these processes we cover, and that we do not cover. We can also discuss with product owner.

I heard about code based design. Can you tell something about it ? I removed sentence about "alternative ways of software design" as recommended in the comment.

My preferred way is to do rather step-by-step prototyping when the agile team will be formed. I love discussions in the agile team upon the planned solution. unfortunately not all team members are equaly involved.

Answer 1

I doubt in this due the fact that I know this piece already and I can start the design and prototype development immediately.

Do you see business process as good starting point when designing software ? This is something we can present to the stakeholders.

So you understand the process perfectly and can just go off and write the code.
Good for you.

Does you understanding match that of the Stakeholders who are paying you to do this job? How do you know this?
Have you agreed the processes with them?
How might you do that before going off and potentially writing the wrong thing, wasting their time and money?

Often, "translating" that you know into a different format makes you think about it in a different way and some of the oddities and edge cases start to pop out of the woodwork.

Answer 2

For some development projects, drawing business processes may a helpful tool for communication or documentation, for collecting or validating requirements, for designing the structure of the system, and sometimes just for marketing purposes. For other projects, this may not be necessary or don't even make sense. For some projects, other forms of graphical or written documentation may be more helpful than business process models.

This depends

• on the kind and size of system to be developed

• on the kind of business process the system will support

• on the people involved, their different levels of knowledge and their preferred way of communication and documentation

• the point in time in the project, and the required level of abstraction for communication or documentation at that specific point in time

There is hardly enough information in your question to tell you what makes sense in your specific case. But from the fact you think you (or your team) knows the business processes well enough to develop the right piece of software I would not come to the conclusion that all stakeholders are immediately convinced of the same. So it may be necessary to demonstrate them somehow that you know what you are doing. How you decide to do this is up to you, your organization, and to what your stakeholders think.

Answer 3

Challenges of software that impacts significantly business processes

There are some challenges when developing from scratch a new software that affects existing business processes:

1. The software and the supported business processes are interdependent. They need to be designed and evolve together, in order to reap the expected benefits. Sequencing these activities (first business process analysis then software, or the contrary) is often not realistic or result in sub-optimal solutions.
2. Redesigning complex business processes is a kind of "organisational development", that requires collaboration of all the different stakeholders involved, because nobody has the full picture (users mostly see only the bounded context in which they are operating and managers are not aware of all the details).
3. Keeping in synch the software and the process development needs some kind of process modelling, that makes the link between seemingly independent user stories. Thinking that developing the process only based on user stories, is like starting to dig a tunnel on both ends without ensuring that the digging is done in the same direction.

Note: If the new software does not fundamentally change the process flow, or if the process is straightforward, then the process drawing might not add any value to the software design.

Risks and pitfalls of process modelling

Business process modelling faces the following risks in the context of software development:

1. Starting with the existing business processes has the inconvenience of drawing the old world first. This tends to create a bias in direction of legacy situation, instead of focusing on the innovation and opportunities that the new system could bring.
2. Starting with the future processes often misses opportunities because many users have difficulties to imagine the future process without seing the software, and the software experts might not know sufficiently the existing process to anticipate all the needs and required interactions.

So, your managers are right in that there is a need for a process "drawing". You are right in that such drawings are imperfect and are not sufficient.

Proposed integrated (agile) approach

Fortunately, it is possible to combine both approaches in an agile fashion:

• Start with the equivalent of user stories but for end-to-end business processes.
• The first development iteration will be a process development iteration. It will give you a simplified, high level map of your process and the process steps in which the software will be used. Exactly as the UI details should be avoided in the user stories, avoid operational and software details in this first "process-story" iteration.
• A second process development iteration could be required to identify potential major process variants and exceptional situations.
• From then on, start the software development using your usual user story driven approach. Just, instead of only developing software, each iteration shall also refine the business process model (which will be the organisation's "software") (and refine only if it's not about minor or irrelevant process details: nothing worse as a DIN A3 diagram with 100 detailed steps that are as many trees that hide the forrest)

Answer 4

In addition to the value of communicating and documenting functionality, I do it as a major time saving and prototyping step. It's what business analysts are supposed to do and why so many exist.

ref. https://en.wikipedia.org/wiki/Business_process_modeling

Answer 5

You are correct that communicating with other teams is a great reason to document current process. This makes it easier for all stakeholders to understand what is being built and what it will do.

It definitely makes sense to have this as part of your software process as it is also very important to validate that the current process is actually correct. Often times, when stakeholders see the business process drawn out, they will find logical issues or things that do not match up with what they actually need to do in the real world. Remember, your users know best how they need to work, and communication with your users is a key part of building your software. Before you have a working prototype, a flow diagram is very helpful in getting feedback on the logic of your application.

Usually, however, I would expect your product owner to be driving these discussions as acceptance criteria/requirements are being formed, but at the very least they would need your input to validate the business flow is correct to your understanding.

Answer 6

You know the business processes (or so you say), but I don't. By drawing the business process, you make sure that I can continue doing your work if you can't for any reason. People who are actually using the business process can use your drawing to verify that your understanding of the process is actually correct.

What you say about agile development is most misleading. Every development starts with determining your goals; what you actually want - in your case, implement the business processes in a more efficient way. For what you need to know the business processes. A specification is the step that comes after that: You specify what your software should do to achieve its goals. That's where agile development tells you that you don't need a complete specification when you start. But still, for every task you need a specification so when a developer says the task is finished, you can take the specification for that task and figure out whether it is actually finished or not.