Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
78:process_architecture [2021/12/20 20:15] – created emr | 78: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 [[: | 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 [[: | ||
- | [[https:// | + | {{ https:// |
- | Above is an example of process architecture. | + | Above is an example of process architecture. |
- | Furthermore, | + | Furthermore, |
In the final layer, specific programs have been instantiated from the ‘Software Engineering’ workspace. This is done by first integrating the ‘Software Engineering’ process into the Program workspaces and later tailoring each of the Programs. | In the final layer, specific programs have been instantiated from the ‘Software Engineering’ workspace. This is done by first integrating the ‘Software Engineering’ process into the Program workspaces and later tailoring each of the Programs. | ||
Line 19: | Line 19: | ||
===== Integrate Processes ===== | ===== Integrate Processes ===== | ||
- | In order to integrate a process into the next level, use the option '' | + | To integrate a process into the next level, use the option '' |
[[https:// | [[https:// | ||
Line 67: | Line 67: | ||
If the interface is still present in the second module, the warnings will go away. | If the interface is still present in the second module, the warnings will go away. | ||
- | ===== 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”, | ||
+ | |||
+ | [[https:// | ||
+ | |||
+ | 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. | ||