2

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.

  • OK, I applied your recommendation. Can you tell me where I can find one such bookshelf ? – Marek Mitros Dec 26 '18 at 21:54
  • 1
    Asking for off-site resources is off topic too. – whatsisname Dec 27 '18 at 1:39
  • @MarekMitros: google for "software design books" or "uml books". – Doc Brown Dec 27 '18 at 8:23
  • @whatsisname Where have I asked about "off-site resources" ? Why asking about "off-site resources" is off topic ? – Marek Mitros Dec 27 '18 at 8:36
  • @DocBrown UML is used for data modelling, not for business processes. I may read some books about software design. So far I work for 20 years in software design without reading much... Maybe I should rather write a book ? – Marek Mitros Dec 27 '18 at 8:43
3

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.

  • 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 cannot reveal the details of my project here. At least I should ask first my project manager. – Marek Mitros Dec 26 '18 at 21:39
  • 2
    You say you know the process, how do you convince others you know? How do you communicate those details to other developers? – whatsisname Dec 27 '18 at 3:16
  • @MarekMitros: 1) Repeating "you know them" again won't convince your stakeholders.2) Yes, as I wrote, the required documentation may depend on the correct point in time. But don't forget business processes are not automated or changed by one release cycle of a certain software, it may require an iterative change process. 3) Yes, you and your team (including your superiors) have to find out by yourself what works best for you and the stakeholders for your purpose, that is exactly the point of my answer. – Doc Brown Dec 27 '18 at 8:31
  • OK, I will draw the processes I know today and I send to involved parties. See if this will help us ... – Marek Mitros Dec 27 '18 at 8:44
  • @whatsisname Right, I need to communicate. For developers I will prepare specification. I might include some pictures or screens or whatever inside. They are telling us that in agile methodology even specification is not needed. So I could just explain them on one page on planning meeting what should be done. – Marek Mitros Dec 27 '18 at 8:47
3

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.

2

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)
  • I agree with this suggestion. We could use one or two customers to discuss the processes with them. I am not totally against processes, just I do not want to spend too much time on them. We tried such project 9 and 3 years ago and we have failed. That's why I have ready ideas to apply. I do not want to loose this chance again to produce good piece of software. – Marek Mitros Dec 28 '18 at 18:53
  • @MarekMitros I fully understand your concerns. I apply this method since around 20 years for various kind of enterprise software, and it proved to be (extremely) effective. The dialogue with stakeholders almost always provide useful insights to all parties. One should not spend too much time on processes either: after the first one or two iterations, there's a risk of over-specifying (people develop too much cases which cause problems, or invent details that could be achieved better in another way). Seeing some working software then helps to focus and keep momentum. – Christophe Dec 28 '18 at 19:07
1

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

  • How is this 'not useful?' it isn't long enough? – John Barbour Dec 27 '18 at 14:52
1

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.

  • My problem is that I never met the user of our software. Maybe now project manager organize periodical meetings with pilot customer. I need some time to digest all the answers here. – Marek Mitros Dec 28 '18 at 18:57
  • This is actually a great reason to document the flow. If you never meet with users, then whomever does needs something they can use to validate with thosr users. – Jay S Dec 29 '18 at 14:50
1

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.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.