EA Toolsets project : OsUiWorkflows

User interface - Workflows

A key requirement is that the toolset support integration with architecture governance.

To do this, each project, during its creation process (i.e. 'File>New...'), should be linked to a defined governance method, such as TOGAF, extended-TOGAF or SEMPER (business-oriented architecture). The default method, for example, would allow simple uncontrolled model/view-creation using 'association' links only, and would allow the results to be saved, but would require an explicit 'merge' action to merge any of the results into the main shared repository.

For all governance-models, common requirements would include:

every project, however brief, must be done for a business reason, and that reason should be recorded as part of the project content
the 'client' must be identified
the funding source must be identified (and likewise other resources as appropriate)
the 'success criteria' for the project must be identified at the start

Design principle: projects may use only one governance-method, but may contain sub-projects which use either the same or another governance-method.

Design principle: projects are nested such that every architecture-project is ultimately a member of the central shared project. Projects operate in their own workspace whilst being developed and worked upon, but may be merged back into their 'parent' project-workspace at any time as appropriate. (For short projects the 'appropriate time' is usually on project completion, but parts of longer projects may need to be incorporated back into a parent-level at intermediate steps, usually at the end of a defined phase of work.)

Design principle: all projects must be able to access common reference-materials for themes such as vision, values, principles, standards, regulations, glossary and thesaurus; in practice this may require the ability to include-by-reference one or more 'global' workspaces into any project workspace. (Credit: Serge Thorne.)

Example workflow

The following is a suggested workflow for a project using extended-TOGAF (see Bridging the Silos or Doing Enterprise Architecture).

Start new project

Use 'File>New...' to create a new project, using extended-TOGAF as the governance-method.

This would create the base workspace for the overall project, and set the rules for governance and for embedding of sub-projects.

Step 1 ('Phase A'): Define project purpose and scope

This is in effect part of the setup for the new project: we identify the project business-purpose, key 'client', funding-source etc, required resources, and success-criteria. We also need to define the time-horizons for assessment (as-is, to-be and any intermediates), and the order in which we would expect to assess them. [This example assumes a simple 'as-is' and 'to-be', with 'as-is' assessment first.]

We then launch a sub-project to identify the scope in terms of the base-categories - layers, columns (assets, functions, locations, capabilities, events, decisions), asset-type and skill-type etc - and derive a RACI matrix of relevant stakeholders. On completion of the sub-project, we merge the results back into the base-project as its scope and stakeholder-list.

The toolset should be able to generate a set of documentation for the end-of-phase review, covering purpose, scope, stakeholder-list etc.

The project entity should be used to record the go/no-go decision from the end-of-phase review. If the decision is 'no-go', skip forward to project-completion ('Phase H').

Step 2 ('Phase B'): Describe 'as-is' context

This step launches a sub-project, whose purpose is to explore the as-is context for the specified scope of the main (i.e. 'parent') project. Client, authorisation, funding-resources and other key governance-details would be auto-populated and/or included by reference from the parent project.

The sub-project would operate within its own workspace, and follow a standard process/governance-method common to all 'assessment' types (as-is, to-be, intermediates). Its initial scope and set of applicable views would be constrained by the parent scope, though may be amended (extended or reduced) as appropriate.

Within those constraints, and within its own workspace, the sub-project should allow the creation of any views, model-extracts, model-amendments and additions (entities and instances), and any appropriate reports. The sub-project would allow the creation of sub-sub-projects for experiments, each within their own 'sand-pit' workspace, and permitting content to be merged back ito the sub-project's workspace as appropriate on completion.

On completion of the assessment, the results should be presented to a review-board drawn from the RACI matrix for the parent project. The toolset should be able to generate a set of documentation for the end-of-phase review, providing a full description of the as-is context at the specified level of detail.

Following the end-of-phase review, appropriate content should be merged back into the parent-project workspace, and optionally into the main shared workspace, as advised by the review-board.

The project entity should be used to record the go/no-go decision from the end-of-phase review. If the decision is 'no-go', skip forward to project-completion ('Phase H').

Step 3 ('Phase C'): Describe 'to-be' context

This step launches a sub-project, whose purpose is to explore the to-be context for the specified scope of the main (i.e. 'parent') project. Client, authorisation, funding-resources and other key governance-details would be auto-populated and/or included by reference from the parent project.

The sub-project would operate within its own workspace, and follow the same standard process/governance-method as for the as-is assessment. Its initial scope and set of applicable views would be constrained by the parent scope, though may be amended (extended or reduced) as appropriate. Optionally, editable content (i.e. new instances of the same repository-entities) could be copied in from the as-is assessment to act as a base for amendment, rather than starting modelling from scratch.

Within those constraints, and within its own workspace, the sub-project should allow the creation of any views, model-extracts, model-amendments and additions (entities and instances), and any appropriate reports. The sub-project would allow the creation of sub-sub-projects for experiments, each within their own 'sand-pit' workspace, and permitting content to be merged back ito the sub-project's workspace as appropriate on completion.

On completion of the assessment, the results should be presented to a review-board drawn from the RACI matrix for the parent project. (Note that because of the variances implied by the different time-horizon, this may not be exactly the same review-group as for the 'as-is' assessment.) The toolset should be able to generate a set of documentation for the end-of-phase review, providing a full description of the to-be context at the specified level of detail.

Following the end-of-phase review, appropriate content should be merged back into the parent-project workspace, and optionally into the main shared workspace, as advised by the review-board.

The project entity should be used to record the go/no-go decision from the end-of-phase review. If the decision is 'no-go', skip forward to project-completion ('Phase H').

Step 4 ('Phase D'): Derive change-requirements from gap-analysis

This step launches a sub-project which should automatically generate, within its own workspace, a set of comparisons between the as-is and to-be assessments, and identify the gaps (i.e. implied changes) between them.

The toolset should be able to generate a set of documentation for the end-of-phase review, covering xxxxx.

Following the end-of-phase review, appropriate content should be merged back into the parent-project workspace, and optionally into the main shared workspace, as advised by the review-board.

The project entity should be used to record the go/no-go decision from the end-of-phase review. If the decision is 'no-go', skip forward to project-completion ('Phase H').

Step 5 ('Phase E'): Develop high-level solutions to requirements

The toolset should be able to generate a set of documentation for the end-of-phase review, covering xxxxx.

Following the end-of-phase review, appropriate content should be merged back into the parent-project workspace, and optionally into the main shared workspace, as advised by the review-board.

The project entity should be used to record the go/no-go decision from the end-of-phase review. If the decision is 'no-go', skip forward to project-completion ('Phase H').

Step 6 ('Phase F'): Assist in change-project detail-design

Step 7 ('Phase G'): Assist in project implementation

Step 8 ('Phase H'): Identify realised-benefits and lessons-learned