Tag Archives: business process

Speaking at Brussels JUG: User Experience for Business Process Applications

I’m glad to inform that I will speak at the next Brussels JUG‘s event about user experience thinking and design for business process applications. The event will take place at Hogeschool-Universiteit Brussel, Building Hermes, on Thursday, 30th of May, at 6:30 pm. Visit Brussels JUG website for more information: http://www.brussels-jug.be.

You won’t find a lot of information about this subject on this blog, but I have been doing research about it in parallel since 2006, in collaboration with Kênia Sousa, who would be happy to share the stage, but she had to decline due to family duties. You may find more information on the page Publications of this blog.

If you were assigned to design and implement a business process based application, You may find this session interesting. User interface design is the most time consuming task in a software development process. It is highly subjective and under heavy criticism by end-users. This presentation will help you better deal with this problem, exploring strategies to represent business processes in a way that end-users can easily understand what they see based on their business knowledge. We will discuss about a different approach for Business-IT traceability based on UX, an architecture and a methodology to support constant process changes, navigation approaches and the right widgets for the right actions.

See you there!

Architects Need a Pragmatic Software Development Process

I have been a non-stop software architect since 2006. During my experience, I realized that it’s really hard to perform the role of architect in an organization that doesn’t have a software development process or have it too simplified. When the development is not fairly organized, project managers don’t find a room in their schedule to implement architectural recommendations. They probably have time, people and resources, but since they don’t have a precise idea of the team’s productivity, they feel afraid of accepting new non-functional requirements or changing existing ones. I’ve noticed that, in a chaotic environment, people become excessively pragmatic, averse to changes.

Architects expect that the organization adopts a more predictable and transparent software process. This way, it’s possible to visualize the impact of recommendations and negotiate when they are going to be implemented. They minimally expect a process that has iterations inspired on the classical PDCA (Plan, Do, Check and Act) cycle because it has loops with feedback, which are the foundation for continuous improvement.

The figure below depicts what could be considered as a pragmatic software process.

Iterations are overlapped in time in order to optimize people allocation, use of resources and guarantee the feedback from previous iterations. Each iteration is performed in a fixed period of time. This time depends on the context and it tends to fall as the organization gains more maturity. An iteration is composed of 4 phases (plan, do, check and act) and 5 events that may occur according to the planning. They are:

  • T1: It represents the beginning of the iteration, starting with its planning. The scope of the planning covers only the period of the current iteration. It should not be mixed with the general project planning, which is produced in one of the initial iterations to plan all other iterations. All members of the team participate in the planning.
  • T2: The execution of what was planned for the iteration starts. All members of the team must have something to do within the scope of the iteration. Nothing planned for future iterations should be done in the current iteration. People may produce all sort of output, such as documents, code, reports, meeting minutes, etc.
  • T3: Everything that is produced should be checked. Documents should be reviewed, code should be tested, user interfaces and integrations with other systems should be tested, etc. All found issues must be registered to be solved in due time.
  • T4: Solve all issues found during the check phase and release all planned deliverables. Everybody should deliver something. In case time is not enough to solve some found issues, they must be included in the planning of the next iteration with the highest priority. Statistics should be produced during this phase in order to compare the planning with the execution. The planning of the next iteration also starts at this point, taking advantage of the experience from the previous iteration.
  • T5: Once everything is released, the current iteration finishes. T2 of the next iteration immediately starts because most of people and resources are already available.

T1 to T5 repeats several times, in a fixed period of time, until the end of the project. This suggestion is process-agnostic, thus it can be implemented no matter what software process we claim to have in place or any other modern process we can think of.

In addition to the process, there are also some good practices:

  1. Consider everything that describes how the system implements business needs as use cases. It can also be functional and nonfunctional requirements, user stories, scenarios, etc; but there must be only one sort of artefact to describe business needs.
  2. Write use cases in a way that the text can be reused to: a) help business people to visualize how their needs will work; b) guide testers on the exploratory tests; and c) help the support team to prepare the user manual.
  3. Avoid technical terms in use cases. If really needed, technical details may be documented in another artefact, such as use case realizations.
  4. If needed, create use case realizations using UML models only. Representing use case realisations as documents implies on a huge overhead. Any necessary textual information can be added in the comments area of UML’s elements.
  5. Fix the size of use cases according to the effort to realize it. For example: we can fix that the maximum size of a use case is 1 week. If the estimation is higher than that, then the use case must be divided in two others. If the estimation is far lower than that, then the use case must be merged with another closely related use case. By simply counting the number of use cases we immediately know the effort and the resources required to execute the project. This fixed number is a parameter to compare the planning with the execution. By performing this comparison after every iteration, we gradually know how precise our estimations are becoming.
  6. Use a wiki to document use cases and other required documentations, such as test cases, release notes, etc. Create a wiki page for each use case and use signs to indicate what is still pending to be released. The advantages of the wiki are: a) use cases are immediately available for all stakeholders as they are gathered; b) stakeholders can follow the evolution of the use cases by following updates in the page; c) it’s possible to know everyone who contributed to the use case and what exactly they did; and d) it’s possible to add comments to use cases, preserving all the discussion around it.
  7. If the organization has business processes, which is another thing that architects also love, then put references in the business process’ activities pointing to the use cases that implement them. A reference is a link to the page where the use case is published on the wiki.
  8. Follow up use cases using an issue tracking system, such as Jira. Each use case must have a corresponding Jira ticket and every detail of the use case’s planning, execution, checking and delivery must be registered in that ticket. The advantages of linking Jira tickets with use cases are: a) Jira tickets represent the execution of the planning and their figures can be compared with the planning, generating statistics on which managers can rely on; b) we know exactly every person who contributed to the use case, what they did, and for how long; and c) it’s an important source of lessons learned.
  9. Test, test, test! It must be an obsessive compulsive behaviour. Nothing goes out without passing through the extensive test session.
  10. Constantly train and provide all needed bibliography to the team on the technologies in use. The more technical knowledge we have inside of the team, the highest is our capability to solve problems and increase productivity.

Working this way, everything becomes quantifiable, predictable, comparable and traceable.

From the practices above we can extract the traceability flow from business to the lowest IT level, as depicted in the figure below.

Business process elements such as swimlanes and activities may inspire actors and use cases. Use cases and actors are documented on wiki pages. Each use case and actor has a page on the wiki, which has a unique URL and can be used to refer the element on email messages, documents, Jira tickets and so on. An Jira ticket is created for each use case and it contains a link to the use case’s wiki page. This wiki page can also have a link to the ticket since it also has a unique URL. Jira tickets can be automatically linked the source code through the version control system (SVN) and declaratively linked to system’s features and user interfaces. Since it’s possible to create mock-ups in wiki pages, then we also link those wiki pages with user interfaces to compare the mock-ups with the final user interface. We finally have actors linked to security roles.

I admit that architects are not qualified to define and implement a software development process in the organization (they actually believe more in the Programming Motherfucker philosophy :D), but they are constantly willing to contribute to have one in place. As they have instruments to monitor servers, releases, tests, performance and so on, they also want project managers having instruments to estimate effort, predict events, anticipate problems and, therefore, produce better planning and results. Warning: Whatever we put in our software processes that is not quantifiable or measurable will become an expensive overhead.

Usi4Biz Has Its Second Journal Publication

We are happy to inform that an article reporting recent contributions on Usi4Biz research was accepted to be published on the Business Process Management Journal. The article is entitled “Getting Users Involved in the Alignment of their Needs with Business Processes Models and Systems” and it was written to report the experience of applying the Usi4Biz methodology at Belgacom, the biggest telecommunication company in Belgium.

Simulation of customer service

This work was possible thanks to the support of Amandine Lievyns, a UCL master student at the time, who had an internship at Belgacom and helped us to apply the methodology in some internal processes. Her master dissertation was about this experience and she could give a significant contribution for this article.

Usi4Biz has been applied in two large organizations and with this article we have completed the publication of each one of these applications in journals. The previous one was an article in JUCS, reporting how Usi4Biz was conceived and applied in an insurance company, which is part of a Belgian bank.

A complete reference to this article will be available in our research page, as soon as we have more information from the publisher.

Important Milestone: Usi4Biz PhD Thesis Defended

An important milestone was achieved last month at IBM Forum Brussels. Kênia Sousa, who is now a doctor in Management Science, defended her PhD thesis on June 24th. Her thesis represents the consolidation of all research produced on the promising field of UI-Business alignment so far.

The ceremony was preceded by a presentation of Dr. Noi Sukaviriya, a distinguished researcher of the Watson Research Center, NY. The subject of her presentation was “Human Aspects & Entity-Centric Business Process Modeling”, summarizing the IBM contributions on rethinking the way how business processes might be managed in the future.

The ceremony began when the jury entered the room and the president of the jury, Prof. Philippe Chevalier, presented the members of the jury, who were Prof. Jean Vanderdonckt (UCL, Belgium), the advisor; Prof. Gaëlle Calvary (UJF – Grenoble INP, France); Prof. Stéphane Faulkner (UCL, Belgium); Prof. Manuel Kolp (UCL, Belgium); and Dr. Noi Sukaviriya (IBM Research, United States). Unfortunately, the jury could not count on the presence of Prof. Elizabeth Furtado (Unifor, Brazil), who was Kenia’s advisor during her scientific initiation. Although, she had an important participation on Kenia’s private defense early this year.

Kenia presented her research during 35 minutes. After that, the president passed the word to the jury for questions. She was questioned for more 15 minutes, going very well in all answers. Then the president called the jury in private out of the room to the final deliberation. After some minutes the jury and the president came back to the room and announced their decision, assigning to Kenia the title of “Docteur en sciences économiques et de gestion” for her thesis titled “A Model-Driven Approach for User Interface – Business Process Alignment”.

The ceremony was witnessed by friends, relatives, co-workers and IBM employees. Most of them were kindly mentioned in the thesis acknowledgments for their direct support for the success of this challenging journey. This post is one more opportunity to say “thank you” to all the supporters. At last, Congratulations Kênia! We hope you keep your motivation high to continue this impressive and highly recognized research.

Activiti by Alfresco: A BPMN 2 Implementation

I’m giving a try on the recent open source project Activiti, which implements BPMN 2 (Business Process Management Notation). Despite being in its first alpha version, Activiti already called a lot of attention from the community. I think it is due to the fact that the leaders are quite reliable people. They are former JBoss‘ employees, who created and maintained the JBPM project, a business process management framework, and it is quite successful nowadays.

I’ve met Tom Baeyens and Joram Barrez in the last edition of Devoxx. Their talks were a “must attend” section in all recent Devoxx editions, and they will probably present their brand new product  at this year’s edition too. The framework is still in alpha but I think it will evolve a lot until there. By the way, the current version is more about playing and understanding the idea than effectively performing processes. What I’ve seen so far deserves some comments.

My first impression was nice. Activiti is very simple to install and the team made a very good work on the design of the user interfaces. Of course, I cannot be so critical right now because it is just beginning, but I will follow the project from now on to give constructive feedbacks to the team.

On the other hand, I was expecting something different, simpler, like a process engine 100% controlled by REST web services. I don’t like the fact of a web application handling the processes execution (screenshot above). Using Activiti Explorer, you can start processes and perform their activities, but it forces the user to be aware of processes’ details. I think an application that implements a business process should be more focused on:

  • the performance of the user when executing his/her activities; and
  • the quality of the data inserted.

Better to wait a little bit more to see the Activiti evolution. I do support the project and hope to see it widely adopted.