GooBiz

Identity : Controled Evolution

Intent : Ensuring coherent evolution to capabilities and services of the architecture according to changes captured on business goals.

Solution Step 1 - What are capability components that have to be impacted by the change: Responses to changes are handled horizontally by assigning coherent responsibilities to appropriate capabilities able to control directly achievement of related behaviours.

 

Solution Step 2 - How should these components be impacted in depth : It is also essential to ensure a coherent propagation of the response to changes not only horizontally as treated in step 1 but also vertically until identifying business services exposed by underlying components of strategic capabilities (such as business functions, processes, roles of the actors, etc...). Thus, impacts of changes are traced throughout the underlying structures of target capabilitiy components to help them evolve coherently with assigned responsibilities.

 

 

 

Explanation Step 1 :

The first step assists strategists and analysts in the identification of capability components able to support response of the enterprise ecosystem to changes. In order to confering to business and IT architectures a coherent evolution according to changing goals, underlying strategic responsibilities are to be assigned to appropriate capability structures able to host them and directly control their evolution.

 

The figure below shows new assignment of responsibilities to capabiliities due a changing goal. To realize the goal, underlying strategies and tactics are assigned to existing capabilities. Two of them namely Turn Visitors into Buyers and Incite Customers to Purchase Complementary Products are assigned to the CRM System Capability shown within a circular dashed line.

Objectives that quantify the expected outcome for the first strategy are also indicated using a UML note and assigned to the corresponding message Turn Visitor into Buyers().

 

 

Figure 1 : The UML communication diagram shows responsibilities assigned to capabilities (using messages) by the goal element shown in the center of the diagram. As there was no notation defined for capabilities in ArchiMate 2, we used business function notation to symbolize them.

 

 

 

Explanation Step 2 :

 

Now, in order to adapt each capability component to assigned responsibilities, we focus on their internal components and try to understand how they should be impacted by the change.

 

PROPAGATION OF THE CHANGES WITHIN A TARGET CAPABILITY

 

On the basis of this initial outline of impact analysis, components that underpin a target capability may be determined further by decomposing goals until gathering corresponding requirements.

 

There are different possibilities for mapping changing requirements onto the existing architecture of the system.

 

A possible solution is to use the ArchiMate Goal-Realization Viewpoint that allows identification of requirements on the basis of Drivers, Goals and sub-goals of the architecture. On the other hand, emerging requirements help to discover initial components of target capabilities able to realize them.

 

Such an hierarchy is shown below where two internal sub-capabilities of the target Extended CRM System capability are discovered.

 

 

 

 

Figure 2 : An initial structure of sub-capability components of the business architecture may be discovered using the ArchiMate Goal-Realization Viewpoint

 

 

Before proceeding to reconfigure these sub-capabilities using business functions, we focus on risks related to their realization and actions to mitigate them. The worksheet below provides for the sub-capability Managing Visitor Registration some risks, their impacts on the resulting business architecture and actions to mitigate these risks.

In order to let them identifiable and easily controlled by the orchestrator of the capability to be configured, we express the emerging Mitigation Actions using Objects with target [States] where corresponding risks have to be mitigated.

 

 

Figure 3 : Excerpts of the Risk Identification and Mitigation Assessment Worksheet to identify potential business functions

 

 

On the basis of actions that can mitigate risks of Managing Visitor Registration... sub-capability, we start to configure it below using business functions reified in Objects [States]. A special controller for the business capability being configured is designated to orchestrate these functions.

 

 

Figure 4 : Business functions identified as part of the previous 'Risk Identification and Mitigation Assessment Worshsheet' are shown here with their internal processes and being controled by the capability orchestrator Visitor [Registration].

 

Now, in order to understand more about services that support capabilities and govern access to its functions, we need to focus on their expected service level (SLE) per function.

 

The diagram above illustrates revisions on some SLEs to be considered based on requirements and risks we have provided in the related figures above.

 

Figure 5 : Business functions identified in the previous diagram are shown here as Service Points with their Functional Service Level Expectations (SLE).

 

 

The following patterns focus on process modeling approaches to implement responsibilities assigned to target capabilities.

• PTAL (Traceable Abstraction Layers) describes related business processes and roles of the actors in realizing them.
• PUBS-AL (Using Business Service Specifications from the Applications) allows users of the IT applications to invoke business functions that configure capabilities using different channels offered to them and based on their application choices.

 

 

 

Strengths of the pattern PCE (Pattern for a Controled Evolution): 

 

This pattern helps to ensure coherent evolution for capabilities of the architecture according to changes captured on business goals. It does not only execute a vertical impact analysis by focusing on the sub-components of the target capabilities but also highlights impacts on other capability components by doing a horizontal impact analysis on their functions.

 

 

Relationships : The pattern PCE also requires contributions from others patterns such as PTAL (Traceable Abstraction Layers) and PUBS-AL (Using Business Service Specifications from the Applications). Its dependencies with other patterns of the Goal & Capability-Driven SOA (GD-SOA) development backbone are illustrated below.

 

 

 

Relationships between the pattern PCE and other patterns to enable the Goal & Capability-Driven Development Framework : Detailed description of each pattern is available by a simple click on its icon.