II. MARCO CONTEXTUAL
2.4 Las preparatorias de la Universidad Autónoma de Puebla
2.4.2 La Preparatoria Regional “Enrique Cabrera Barroso”
In this scenario, an incremental change to the EA blueprints impacts the portfolio of BPM processes, and EA governance needs to be applied to make the
changed targets visible and to decide how to comply with them (if possible). The EA governance scenario includes the following steps:
1a: Adjust process portfolio goals and constraints.
1b: Identify process portfolio impact and initiate change projects.
1c: Monitor architectural compliance of changes to the process portfolio.
Figure 13-1 illustrates where the related collaboration points are placed on the enterprise landscape for a brown field environment with existing BPM artifacts. For special concerns in green field environments with few or no existing BPM artifacts, see 13.1.1, “Cloning of EA artifacts” on page 178.
Figure 13-1 The EA governance scenario
Step 1b, identifying the scope of impact on the portfolio, is absolutely critical. We must identify, in collaboration with the process owners and portfolio managers, which operational processes that are within scope of the changed or new EA targets before we can act appropriately.
"Contract" PhysicalDesign PhysicalAssets Deployment Operations Solutions TO BE (objectives) Solutions TO BE (objectives) Multiple Projects
(Solution Delivery) Note: Feedback often (typically) isapplied between project instances.
Monitor operational effectiveness and operational compliance Portfolio TO BE (objectives) Strategic goals and constraints Strategic goals and constraints Portfolio Management and Optimization, Segments (Solution Delivery) Target blueprints and principles Strategy Strategy Planned Improvement (Enterprise Planning) Monitor architectural compliance and effect of changes 1a 1b 1c
If the change is to an existing EA artifact that is already linked to relevant BPM artifacts, then identifying the scope of impact is easy. Use the EA impact analysis capability and follow the links to the BPM artifacts that are impacted. In our JKHL Enterprises example, we can look up the process hierarchy, which is shown in Figure 13-2.
We can identify processes that are
potentially
impacted, namely those linked to the changed EA model element (in this case, the element labeled with a red box). Using the associated link, we can navigate to the BPM model (Figure 13-3) to validate whether in fact the process needs to change.Figure 13-3 Original BPM model
Any actual changes to the BPM model must be done within the BPM modeling tools, usually in the context of a new (full life cycle) change project. If links do not exist, the EA practitioner and the BPM process portfolio manager can collaborate to identify the relevant set of operational processes manually, and subsequently establish the relevant links for future use.
Note that this does not mean that all such operational processes are necessarily modeled in any form of detail. All it means is that we need placeholder artifacts in the BPM portfolio that can link to the EA target for visibility and later guidance of initiated solution delivery projects.
In some cases, we might also identify collaboratively that there is no current operational process that adequately supports the EA target, so one must be added to the operational portfolio. In the JKHL Enterprises example, we realized, as described in Chapter 11, “BPM applied” on page 147, that we must add a new subprocess to the current online banking process. This subprocess extracts account data from an external SAP system, as shown in Figure 13-4 on page 177.
Figure 13-4 New subprocess extracting account data from an external SAP system
Any new BPM artifact must be linked to the originating EA target. See
Chapter 12, “Linking EA and BPM artifacts” on page 163, for details about how to establish links.
We have already mentioned that many changes in the solution delivery domain are appropriately executed in project mode. Established organizations will use tools to track changes and related change projects across tools and artifact domains. Although the scope of this book does not cover change management in depth, we do want to suggest that it can be advantageous to document desired changes as change requests within the EA domain and link them as applicable to change projects being executed within solution delivery. Figure 13-5 on page 178 shows an example.
Figure 13-5 EA tool with Change Request
When the changes are logged in the EA model, they are tracked and form part of the foundation for EA transition planning, road maps, and so on.
13.1.1 Cloning of EA artifacts
If the BPM discipline in an organization is mostly green field, no existing BPM artifacts are at hand, and the EA discipline at the same time is well developed, the EA governance processes described previously pose particular challenges.
An effective and consistent way of accelerating the design of new BPM processes is needed.
In earlier parts of this book, we explained the concept of cloning. Cloning is used when you want to use one thing as the starting point for another completely different thing, such as using a clone of an EA process blueprint as the starting point for a new BPM process model.
Such cloning capabilities, based on standardized resource format standards such as Business Process Modeling Notation (BPMN) 2.0, are advantageous to have as part of a BPM and EA collaboration arsenal. We have to caution once again that the resulting BPM artifact is different from the EA original. It has its own life cycle and different semantics than the EA process blueprint. (See Chapter 6, “Stop copying; start linking” on page 83, for details.) One reason to be cautious is that by reflex many people think of and ask for export/import when they talk about BPM and EA “integration”. There are several issues with this line of thinking:
The proper relationship between BPM and EA is synergistic collaboration and
coordination, not export/import “integration.”
Export/import produces a non-linked copy. A clone should have a different
identity, its own life cycle, and be linked to the original source for future visibility and change management.
Cloning is the exception and should only be used once per artifact in a green
field situation. The normal situation is existing artifacts with established cross domain links.
Cloning, when properly applied, is a valuable accelerator. When it is misused beyond first time green field scenarios, cloning (or even worse copying) leads to manageability issues.