Challenge

An unmaintainable system in a customer that is been used to cover the needs of a highly  complex business domain. The system had a long life of more than 25 years with bad solutions  and desgins that makes really difficult any evolution. The actual business changes pace in this  digital world motivate to make a new software.

The documentation about the system was highly poor and obsolete, not corresponding with the  actual system really does. The process then required begin from scratch, trying to understand  what the problem the system solve. The first approaches between the software developers and  business experts to understand the business domain to solve show many ambiguities,  contradictions between business experts and even many business rules not clear. The sessions  to understand the business problem quickly ended talking about the screens of the new system  (the solution) and the people were not focus previously on understand the problem to solve (the  business domain). The first weeks show business experts discussing between them with not  clear idea of the business domain and business rules, and developers not understanding what is  the problem to solve. A different approach was required.

Tool

A different approach to a common understanding of the problem to solve was selected. We  choose to follow Domain Driven Design, that is an approach with techniques that focus first on  the problem to solve (get a deep understanding of the business domain) previous to design a  solution. The common understanding between business experts and software engineers about  the business domain is achieved using graphical representation of the business domains based  on UML diagrams (represent information of the business domain and the business rules to  consider on a visual manner). (Visualization Tool).

Application

Other key ingredient of the process was how we applied this tool. We incorporate to the team  experts software architects with experience in this kind approach and we begin to make daily  meetings in which this experts make the right questions to the business experts and with the  answers they begin to express the business domains in a graphical way. This graphical  representation also were explained to the business experts so they discover a different way to  see their business, the information they manage in their business, the business rules and how  all was related.

Insight

The graphical representation of the business domain for the business experts discover other way  to see the knowledge they have and suddenly they solve a lot of ambiguities, they get a deep  insight on the knowledge they have. Suddenly all the business experts can see in a unique place  the knowledge of all of them put together, ordered. This deep insight even later entailed  innovations on the solutions that together (business experts, and developers) put in place.

For the developers, follow a graphical representation of the business domain base on objects  models get a better understanding of the problem to solve and a very good starting point on the  problem to solve.

This also generate cohesion between the teams because both (business experts and developers)  could get important benefits of the daily interaction and the results of them.

Approach:

Some people were allways resistant to new ways of work, or do the job. In the future I will  allways begin with the right people (people flexible to accept changes) and with the first positive  results extent to the rest. In my experience to have people resistant to change generate many  problems till the first results appear.

