People, Systems and Data analysis
When looking at an existing application ecosystem for the first time, whether for an upgrade to the functionality or for a complete system migration, it is sometimes difficult to know where to begin in our quest to understand the ecosystem. To add to the problem, the most common state that we see is that the existing ecosystem is not documented at all. One method that you can use to help to ensure that you understand the ecosystem is to look at people, systems and data (PSD). Examining these three areas and the interplay between them will create a boundary around the ecosystem that will help you to fully understand how the ecosystem functions. The key value of this method is that it relies on elements that are easy for people to recall but yet still form complete boundaries around the ecosystem. For example, once you use an organizational chart or even the actual list of logins to identify the users, you can be sure that there are no other users because no one else has access to the system.
When looking at people (actors), the place to start is organizational charts and interviewing actors to find other actors. It is pretty easy to identify all of the actors because people are used to thinking about the people that they work with. Organizational charts include not only those who use the system, but also those who operate the system and those who built or maintain the system. A representative lead from each group should be identified who can act as a single decision maker to represent the user population and who can help to identify those with special knowledge of a facet of the system. In addition, you need to ensure that any subgroups are identified as well. For example if there are two types of sales reps that use the system in different ways, they should be identified as different actors. Other ways to bound the population of actors include looking at the database of all users who have access to the system, identifying all developers who have checked in code into the change control system and all operations team members who maintain the system. Once you have identified the complete user population in this way, you have created a firm boundary that limits the unknowns. The next step is to begin meeting with the various actors and figuring out how they interact with the system. These interviews will result in the generation of high level use cases. By their very nature, the use cases will not be a comprehensive description of the system, they will simply be a guide to how the people do their jobs in relation to the system. Chances are you will not get all of the use cases on the first try, but in conjunction with looking at systems and data, you will follow an iterative process that will get you to a complete model of how the system works today.
When looking at systems, the goal is to identify all of the major applications that participate in the ecosystem. Generally speaking it is easy for users, operators and maintainers to list the systems, however it is much harder for them to be able to detail all of the interactions between systems without some organized structure. By creating system context diagrams you can create a visual framework that will help to focus on the relationship between any two systems, so that only the relationship between those two systems has to be considered at a time. This makes it much easier to capture all of the information about that relationship. The system context diagram simultaneously shows all systems and, at a high level, what the interactions between the systems are independent of sequence. The list of all systems provides another boundary that is easy to achieve. Once all the pertinent systems have been identified, screen shots from those systems can be used to help drive discussions around the specific business rules and functionality of the systems. In addition, direct access to the existing systems can be very helpful. Finally, to ensure that all the business rules are captured, examination of the source code is generally required. However as this step is very time consuming, it should be used as a way to validate an existing list of business rules rather than to generate the list of business rules in the first place.
Finally, users often times think in terms of the data that they create and the data that they use. Data is only ever created, transformed or consumed, so once you have identified an object, you can ask the question of how did it get created, how is it used and what happens to the data between the time it was created and the time it was used? Looking at data entry screens and reports help to identify how the data is created and used. Since there are a finite number of these screens and reports, you can be certain that they form a complete boundary around the data in the system. The next step is to determine the data flows through the system, data dictionaries and business rules that govern the entry and transformation of the data. You can use system context diagrams to help generate the data flows as you can identify in which systems data is created and then follow the flow of the data through various applications until it is used.
The key value of looking at people, systems and data is really in looking at the interplay between the three. Data flows will help to identify use cases (i.e. how does someone use this data?). System context diagrams help to drive discovery of the data flows. Screen shots help to trigger memories of business rules that apply to the data. Use cases or reports may help to identify missing systems or discover missed data objects. By working iteratively through people, systems and data you can feel confident that you have a completely bounded understanding of your application ecosystem.
When looking at people (actors), the place to start is organizational charts and interviewing actors to find other actors. It is pretty easy to identify all of the actors because people are used to thinking about the people that they work with. Organizational charts include not only those who use the system, but also those who operate the system and those who built or maintain the system. A representative lead from each group should be identified who can act as a single decision maker to represent the user population and who can help to identify those with special knowledge of a facet of the system. In addition, you need to ensure that any subgroups are identified as well. For example if there are two types of sales reps that use the system in different ways, they should be identified as different actors. Other ways to bound the population of actors include looking at the database of all users who have access to the system, identifying all developers who have checked in code into the change control system and all operations team members who maintain the system. Once you have identified the complete user population in this way, you have created a firm boundary that limits the unknowns. The next step is to begin meeting with the various actors and figuring out how they interact with the system. These interviews will result in the generation of high level use cases. By their very nature, the use cases will not be a comprehensive description of the system, they will simply be a guide to how the people do their jobs in relation to the system. Chances are you will not get all of the use cases on the first try, but in conjunction with looking at systems and data, you will follow an iterative process that will get you to a complete model of how the system works today.
When looking at systems, the goal is to identify all of the major applications that participate in the ecosystem. Generally speaking it is easy for users, operators and maintainers to list the systems, however it is much harder for them to be able to detail all of the interactions between systems without some organized structure. By creating system context diagrams you can create a visual framework that will help to focus on the relationship between any two systems, so that only the relationship between those two systems has to be considered at a time. This makes it much easier to capture all of the information about that relationship. The system context diagram simultaneously shows all systems and, at a high level, what the interactions between the systems are independent of sequence. The list of all systems provides another boundary that is easy to achieve. Once all the pertinent systems have been identified, screen shots from those systems can be used to help drive discussions around the specific business rules and functionality of the systems. In addition, direct access to the existing systems can be very helpful. Finally, to ensure that all the business rules are captured, examination of the source code is generally required. However as this step is very time consuming, it should be used as a way to validate an existing list of business rules rather than to generate the list of business rules in the first place.
Finally, users often times think in terms of the data that they create and the data that they use. Data is only ever created, transformed or consumed, so once you have identified an object, you can ask the question of how did it get created, how is it used and what happens to the data between the time it was created and the time it was used? Looking at data entry screens and reports help to identify how the data is created and used. Since there are a finite number of these screens and reports, you can be certain that they form a complete boundary around the data in the system. The next step is to determine the data flows through the system, data dictionaries and business rules that govern the entry and transformation of the data. You can use system context diagrams to help generate the data flows as you can identify in which systems data is created and then follow the flow of the data through various applications until it is used.
The key value of looking at people, systems and data is really in looking at the interplay between the three. Data flows will help to identify use cases (i.e. how does someone use this data?). System context diagrams help to drive discovery of the data flows. Screen shots help to trigger memories of business rules that apply to the data. Use cases or reports may help to identify missing systems or discover missed data objects. By working iteratively through people, systems and data you can feel confident that you have a completely bounded understanding of your application ecosystem.
posted by Anthony C. at 3/26/2006 11:21:00 PM
0 Comments:
Post a Comment
<< Home