Stages Documentation

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
78:process_architecture [2022/01/14 17:18] – aakr78:process_architecture [2024/02/15 00:00] (current) – external edit 127.0.0.1
Line 1: Line 1:
 ====== Define a Process Architecture ====== ====== Define a Process Architecture ======
  
-The Process Architecture is the hierarchal design of the processes. As the business undergoes changes and processes become more complex, a strong process architecture ensures that processes remain in their optimal state. Organizational strategy, structure, process ownership, and program portfolio are some of the key considerations that go into defining the architecture.+Process Architecture is the hierarchal design of the processes. As the business undergoes changes and processes become more complex, a strong process architecture ensures that processes remain in their optimal state. Organizational strategy, structure, process ownership, and program portfolio are some of the key considerations that go into defining the architecture.
  
 In Stages, since each of the processes resides in its own workspace, process architecture is represented by the hierarchy of the workspaces. Before integrating it into the next process in the hierarchy, it is recommended that each process should be baselined (versioned) and only the [[:general:validversion|valid version]] of the process should be integrated. In Stages, since each of the processes resides in its own workspace, process architecture is represented by the hierarchy of the workspaces. Before integrating it into the next process in the hierarchy, it is recommended that each process should be baselined (versioned) and only the [[:general:validversion|valid version]] of the process should be integrated.
Line 7: Line 7:
 {{  https://doc.stagesasaservice.com/lib/plugins/ckgedit/fckeditor/userfiles/image/75/processarchitecture4.png?nolink&1000x239  }} {{  https://doc.stagesasaservice.com/lib/plugins/ckgedit/fckeditor/userfiles/image/75/processarchitecture4.png?nolink&1000x239  }}
  
-Above is an example of process architecture. Since common elements like phases & milestones, common roles (e.g. stakeholders) are defined at the corporate level, they have been defined in a workspace called ‘Lifecycle Management’. The other process areas directly interface with process elements in this workspace.+Above is an example of process architecture. Elements like phases & milestones or value streams have cross-process validity. They are defined in a workspace called ‘Lifecycle Management’. The other process areas directly interface with  elements in this workspace, e.g. associating work products with milestones.
  
 Furthermore, all the process areas (including Lifecycle Management) are integrated into a single Standard Process workspace called ‘Software Engineering’ which contains all their process elements (workflows, activities, roles, phases & milestones, work products, and guidance). Furthermore, all the process areas (including Lifecycle Management) are integrated into a single Standard Process workspace called ‘Software Engineering’ which contains all their process elements (workflows, activities, roles, phases & milestones, work products, and guidance).
Line 19: Line 19:
 ===== Integrate Processes ===== ===== Integrate Processes =====
  
-In order to integrate a process into the next level, use the option ''Add module'' on the **Process** start page. In our example, once the Software Engineering workspace is created, all the process areas are added at one go by using the ''Add module'' option. The recommended practice is to select the valid version of the processes to be added.+To integrate a process into the next level, use the option ''Add module'' on the **Process** start page. In our example, once the Software Engineering workspace is created, all the process areas are added at one go by using the ''Add module'' option. The recommended practice is to select the valid version of the processes to be added.
  
 [[https://doc.stagesasaservice.com/lib/exe/fetch.php?tok=29fb0f&media=https://doc.stagesasaservice.com/lib/plugins/ckgedit/fckeditor/userfiles/image/73/addmodule_2.png|{{https://doc.stagesasaservice.com/lib/plugins/ckgedit/fckeditor/userfiles/image/73/addmodule_2.png?direct&900x388}}]] [[https://doc.stagesasaservice.com/lib/exe/fetch.php?tok=29fb0f&media=https://doc.stagesasaservice.com/lib/plugins/ckgedit/fckeditor/userfiles/image/73/addmodule_2.png|{{https://doc.stagesasaservice.com/lib/plugins/ckgedit/fckeditor/userfiles/image/73/addmodule_2.png?direct&900x388}}]]
Line 69: Line 69:
 ===== Use Workspace Collections to control Process Interfaces ===== ===== Use Workspace Collections to control Process Interfaces =====
  
-TODO: v7.8+More complex projects and programs are best instantiated as multiple workspaces. For example, a program following a scaled agile approach would have one portfolio workspace, several workspaces for the different products or systems, and then subsequent workspaces for each sub-system, component, or team. Of course, this whole workspace hierarchy should be connected via the correct interfaces. 
 + 
 +In the image below, “Program A” needs to have interfaces with “Component A1 Hardware” and “Component A2 Software”, but not “Component B1 Hardware”, “Component B2 Software”, or “Component B3 Software”, even if the same process modules are integrated there. 
 + 
 +[[https://doc.stagesasaservice.com/lib/exe/fetch.php?tok=7dd61d&media=https://doc.stagesasaservice.com/lib/plugins/ckgedit/fckeditor/userfiles/image/78/multilevelprogram.png|{{https://doc.stagesasaservice.com/lib/plugins/ckgedit/fckeditor/userfiles/image/78/multilevelprogram.png?direct&800x381}}]] 
 + 
 +The above structure can be correctly instantiated **by using workspaces collections** to control the creation of interfaces. By creating workspace collections depicted by the colored dots in the image above, the interfaces will be correctly created, because **all workspaces within all collections of the current workspace** are being searched for interface candidates. The interface search uses internal identifiers instead of just names, which makes it very robust and allows the workspaces to have arbitrary names. 
 + 
 +In addition, this allows the same process module to be integrated into different workspaces with different tailorings. For example, the “Component B2 Software” and “Component B3 Software” workspaces can have the same software development process module integrated but might have different tailorings or even different versions of the same module, and it will correctly interface with its parent “Program B” workspace. 
 + 
 +Finally, those workspace collections will always show the end users the expected search results, when the search scope “Recommended Workspaces” is being used.