In the previous chapter, we discussed the importance of determining the original state workflow and formulating the objective state workflow. Process change then enables the transition path from the original state to the objective state. Even when the workflow must stay the same, process and procedural advancements within existing functions could still increase performance. Finally, when current state performance is threatened by adverse external forces, increasing adaptiveness within the business process can sustain the integrity of the workflow. Solutions development, therefore, involves improving the process in most situations. Even when just making changes in personnel, new training and new management tasks in the overall process might be required to yield a complete solution. Even with the replacement of one technical component in the architecture, that replacement is only a solution if it improves speed, quality, duration, or some other performance metrics. The act of replacement involves a process. But if nothing has changed, then the replacement activity is just maintenance. Some processes are designed with such self-adaptiveness and self-organization capabilities that the solution is to find better ways to technically support the existing patterns of change. Other processes may be designed with such rigidity to prevent errors that all changes must be heavily validated and cautiously adopted. No matter the system or service requirements, the heart of solutions development starts with understanding the process with architecture, technologies, and people supporting the process [1].