Reuse through copying and pooling

Reuse through copying consists of taking what already exists and using it in another context. In the context of software development, this comes down to duplicating a part of the source code from a given example. More generally, it is the widely known mechanism used in design “patterns.” A tried and tested practice or structure is reused by adapting it to a specific context. In this case, the reused part is integrated and merged into the target component, which evolves with no direct link to the element used. As discussed in Section 4.1, the TOGAF architecture repository is the ideal place to store this kind of heritage, which must be constantly added to.

Shared reuse or pooling is very different. It consists of sharing a component in different contexts; this is the typical schema used in an SOA context, where several applications will use the services provided by a component deployed in the system. To use SOA terminology, users are consumers, and the shared component is the service provider. This schema develops links between consumers, which must be managed.

The price of pooling

On this issue, TOGAF considers that pooling components multiply costs by at least a factor of two compared with separate development.^e The main causes of these additional costs are as follows:

• First, pooling requires agreement between consumers regarding the terms of the service provided. This contractualization (SLA) precisely defines the conditions under which the service in question will operate. Moreover, we can see that the nonfunctional part plays its full role here: availability, performance, security, and so on.

• Second, each provider evolution is immediately transmitted to all the user clients of the pooled component. This situation often leads to internal conflicts.

Let’s take the example of two applications called A and B, which use the services of a single component named C. For specific reasons, application B needs to quickly modify the interface of component C. The person in charge of application A is forced to resume a test campaign if this component is modified, and to modify his work plan for external reasons.

Thus, we end up with the following paradox: the higher the degree of pooling, the more difficult contractualization becomes. Therefore, if reuse is not managed properly, it can lead to reduced system agility, bogged down by the red tape of contractualization.

Faced with this type of situation, IS managers sometimes decide to temporarily multiply the number of versions of pooled components in order to enable rapid deployment without perturbing other consumers. In Figure 12.2, two versions of component C will be available: version C1 (unchanged) used by application A, and version C2 integrating the modifications requested by application B. This transitional state has to be resolved by the effective pooling of the same version of C by A and B.

This option enables conflicts to be reduced, but leads to a multiplication of versions, which eventually compromises effective reuse and increases the complexity of the system.

For the sake of pragmatism and efficiency, these situations are difficult to forbid entirely. The role of the organization in charge of enterprise architecture consists of avoiding a proliferation of versions. An adapted indicator will facilitate control and management, for example, by fixing a maximum number of simultaneous versions and a limited duration for the coexistence of several versions of a component.

Thus, the work of an enterprise architect consists of finding the best compromise between the advantages of reuse and the disadvantages that we have just discussed.

This choice is based on a set of characteristics:

• The number of consumers

• The stability of the pooled component

• The frequency of use

• The size/complexity of the interface

In other words, for a component used by a large number of consumers, which is very unstable, frequently used, and relatively complex to approach, significant additional costs can be expected.

Stability plays a major role in this type of choice. It is often linked to a certain normalization of the service provided by the provider, which reduces considerably the burden of management. In this category we find many utility components, for example, pooling an e-mail server presents no particular difficulties, despite the fact that it is used by a large number of consumers to automatically send e-mail.

Cross-organization

A process is inherently cross-organizational to the enterprise’s functions and entities. It is made up of the different stages that follow one another in a more or less complex manner, from the trigger event until the final result is obtained. We talk about “end to end” processes, with key performance indicators (KPIs) that measure the quality of the final result. Figure 12.5 shows the progress of an order process, which runs across several enterprise entities (sales, invoicing, production, and delivery). Evaluation of this kind of process measures, for example, the time between an order being taken and the actual delivery of the product. Improvement in the quality of the service rendered to the client means working on the entire process (Figure 12.5).

Depending on the complexity of processes, it may be necessary to perform a further breakdown into subprocesses. Some of these subprocesses can be used in several processes, which facilitates simplification through factorization.

Temporality

A process has a beginning and an end, and runs over a given period of time.^g This statement may appear trite but is worth remembering. For example, “contract management” generally does not represent a process of the enterprise but rather a function or logical group of processes, since “contract management” has no start and no finish. The “contract management” group can include, for example, the “open a new contract” and “amend a contract” processes, which run over a given period of time between the moment they start and the moment the result is obtained.

Parallelism

When a process is run, we often find activities that run simultaneously, notably those that are undertaken by different actors. These parallel branches require that information be exchanged or synchronized. In the previous example, the enterprise can decide to run the invoicing and production activities at the same time. The actual delivery of the product waits for the end of these two activities before starting. This new organization reduces the overall duration of process execution, but requires strict synchronization of the end of the two invoicing and production activities. This is a typical choice for process architecture, with greater or lesser repercussions on the other architectural constituents involved, such as business organization or IT elements.

Events

Business processes are rarely isolated. They react to outside events that have a direct influence on their progress. In particular, certain activities will find themselves in the position of waiting for a given event to happen: the process is suspended until this event occurs. For example, when an insurance claim is processed, the investigation will await the results of the evaluation report before continuing. Other events can also interrupt an activity that is underway, such as a cancelation request.

Note that this event aspect is particularly present in BPMN notation, which provides no less than 50 different types of events.

Generic typology of business processes

The following classification is fairly widely used,^h since it provides initial positioning of processes within the enterprise:

• Operational processes or “core business” processes, responsible for direct enterprise added value (claims processing, client orders, etc.).

• Support processes, which assist operational processes without directly participating in the results (price update, production and update of product catalogs, etc.).

• Management processes, linked to the strategies and general management of the enterprise (market studies, general goal definition, supervisions, etc.).

This list can be completed by adding the “internal process” type, which designates processes that are not specific to the business in question, such as recruitment processes or resource management processes.

This typology facilitates the hierarchical organization of processes and enables better definition of their relationships. Operational processes are obviously the most critical for the enterprise, but each process contributes to obtaining defined goals.

Types of sequences

The types of relationships that exist between the activities of a process are variable and define its functioning mode. The sequencing of activities can be strictly determined, or can be left more or less flexible. In the first case, we will talk about deterministic or “mechanistic” processes. Anyone looking at the example in Figure 12.6 will quickly come to the conclusion that the sequence of activities of the process in question cannot be different (unless we consider that it is normal to start by ironing and to finish by washing clothes). Different paths can exist, but these are strictly marked out by explicit conditions. In our example, ironing is an option depending on the client’s wishes.

In the second case, the sequence of activities is much more random and can be the result of choices made by participating actors (Figure 12.7). This is notably the case with design or diagnosis processes, in which the path to the expected result cannot be described simply, even if the activities themselves are clearly defined.ⁱ

In the example of the medical diagnosis, we can simplify by stating that each consultation or analysis activity can potentially redirect the patient to one or several other activities according to the practitioner’s opinion. The exhaustive description of all possible paths would result in a highly complex, totally unusable graph.

We find a similar distinction in the workflow community between the “procedural” workflow and the “ad hoc” workflow. Procedural workflows (also called production workflows or directive workflows) are business processes known to the enterprise, which are the subject of preestablished procedures, and whose sequence of activities is fixed. Ad hoc workflows are based on a collaborative model in which actors participate in the decisions regarding their sequence of activities.

Knowing which type of sequence of activities is involved (even without going into detail at this level) conditions certain decisions, notably with regard to modeling work and implementation choices.

Most modeling languages such as BPMN are better adapted to describing mechanistic processes, with a fixed sequence of activities.^j Some approaches advocate representation through event and condition tables in the case of nondeterministic processes.

It is clear that process automation implementation can vary significantly depending on the type of sequence of activities. Once again, process execution history tools facilitate deterministic processes, but the emergence of “case management” solutions^k provides a more collaborative vision of processes.

Batch processing and desynchronization

We have seen that a process takes place through the sequence of its activities. Activities represent work units, each of which contributes to the final result, as in an industrial production line. Let’s take a typical example of a (highly simplified) process concerning order processing. This process (which is deterministic) is broken down into three activities: validation, invoicing, and order delivery (Figure 12.8). It is triggered when the order is received.

But if, as is often the case, the enterprise decides to group several orders into a single delivery that takes place at the beginning of every week, this description becomes incorrect. The “Order delivery” activity does not exist. Furthermore, the real activity of delivery of a batch of orders is not triggered following order invoicing, but rather at a fixed date (at the beginning of the week). A more realistic representation of the process is provided in Figure 12.9.

The process ends up being “decoupled” into two separate processes, each with a different trigger. This is a recurring question with regard to processes and work organization methods: the choice between “just in time” processing and “batch” processing. According to the context, the enterprise can choose to manage each order individually right through to delivery, or as we have just seen to deliver batches of orders.^l

It is easy to imagine that the consequences of this choice on the organization and architecture will be significant: an accumulation of orders over the week, product storage issues, delivery implementation, and so on. Thus, it is essential that desynchronization phenomena be identified in order to properly carry out work on the resulting architecture.

All too often, rushing into detailed modeling of processes leads to a paradoxical situation: the proliferation of models that are difficult to use and quickly obsolete. Many enterprises that have undertaken the large-scale modeling of their processes observe that results are poor compared with the investments made: the reality of the situation has evolved while a significant part of the repository has been “treading water.”

Note that here we are talking about process models that are intended to last, like architecture repository elements. Descriptions, models, or various representations realized for temporary needs are not concerned. By nature, these are “perishable” and are not subject to the same durability constraints.

Of course, this disconnection between reality and description can be seen for each part of the architecture repository. However, the risk of a break with reality is particularly high for business process models for two essential reasons: first, the elevated cost of investment in process modeling and, second, the frequently changing nature of the subject being dealt with. Modeling a process consists in “dissecting” activities, with all the implicit imprecision and knowledge this includes. The result will only be convincing through the involvement of business resources, which are sometimes difficult to mobilize within a reasonable timeframe. Consequently, the representation of real processes goes beyond simplistic diagrams made up of “boxes” and “arrows,” and requires real introspection on the intimate functioning of the enterprise.

How should one proceed faced with this situation? Above all, by starting from the goal in terms of communication and use, and by adapting the form and content of the representation in accordance with this goal: to represent in the repository what we really need and what needs to be maintained over time.

Identification, qualification, and modeling

With this in mind, we suggest the definition of three distinct levels of representation for business processes: identification, qualification, and modeling.

This distinction has two advantages. First, it organizes the process repository into successive layers, by increasing the level of detail, and second, it encourages a more progressive approach, which tends to be quickly beneficial by minimizing investment (both cost and time).

Modeling

Models based on graphical notation are essential to the detailed representation of business processes, as with the BPMN^p standard.

Figure 12.10 presents a simple example of a business process described with BPMN. The “Order reception” trigger event starts up the process, which begins with validation of the order. Two parallel branches are then run: dispatch and delivery confirmation on the one hand, and invoicing and payment on the other. The process only ends when both these branches have been completed.

Models have long been used in many sectors to understand, develop, simulate, and communicate (see Chapter 5). Modeling requires particular skills and knowledge: choice of level of detail, gathering and consolidation of information, and communication of results. The type of modeling carried out will vary depending on the goal (general description, detailed information on the process, or support for automation).

Using this principle, Bruce Silver^q identifies three levels of business process model: the descriptive level, the analytical level, and the executable level. The descriptive level provides the fundamental structure of the process, with its main activities, but without taking exceptions into account. The analytical level establishes the sequence of the process in detail, with all its activities and exchanges. The executable level is used in the context of process automation by integrating links to software elements and technical constraints. Once again, we observe the need to separate viewpoints applied to modeling.

Process description management

Using TOGAF terminology, the breakdown into levels that we have just discussed consists of defining a set of viewpoints dedicated to processes:

• The “identification” viewpoint, which presents high-level views that are simple to use but which provide a summary of the main process-related information.

• The “qualification” viewpoint, which is the result of analysis of the process, its characteristics, and possible improvements.

• The “modeling” viewpoint, which describes process content in a more or less detailed way, using BPMN-type notation.

This structuring in the architecture repository enables more efficient communication and reduces the risk of uncontrolled proliferation of process descriptions.

In practice, the aim is not to define all the enterprise’s processes in one “big bang” operation. Priority will be given to “core business” processes or opportunity-driven processes (optimizations, evolutions). Generally speaking, the number of “identified” processes is greater than the number of “qualified” and “modeled” processes. We strongly recommend that the switch from one level to another be clearly justified, notably for modeling, in view of the investment necessary for this type of work.

The “process driver”^r function is used in many enterprises to guarantee the quality, monitoring, and continual improvement of business processes. Today, a whole host of publications exist on the subject, as well as sharing communities such as the “Process Driver Club.”^s It has multiple roles and touches on several facets:

• Description and modeling

• Improvement and optimization

• Coordination of the application components involved in the process

• Training and informing of users

• Supervision of execution, key performance indicators

• Feedback from monitoring and information/warnings provided to management

• Maintenance, support, and parameterization

• Study of changes

• Repository update

Furthermore, this function emerged relatively late and is still having difficulty in widely establishing itself. This is paradoxical since everyone is convinced of the critical role played by processes within the enterprise.

The main reason for this delay is the cross-organizational nature of business processes. We have already seen that business processes generally run over several functions, managed by distinct organization units. This positioning goes against the historical and sometimes “hierarchical” structure of enterprises. “Traditional” IT applications easily find their place in this type of organization, under the clearly defined responsibility of well-established units. However, installing and stabilizing a cross-organizational-type organization, which plays a real driving role, is a delicate task. That said, this depends on the business context. In fields closely linked to logistics, such as transportation, processes are naturally seen as being at the heart of the business. For other types of activity, the approach by process has only really begun to develop over the past few years.

Role in enterprise architecture

Enterprise architecture, another cross-organizational activity, is an opportunity for process drivers, which are very often found in the frontline during architecture development and transformation work. In this respect, process drivers have to participate in transformation work, throughout all phases of the ADM cycle. In some cases, it is the creation of an architecture project that triggers the implementation of specific process management, which continues beyond the ADM cycle.

In general, we can identify two main categories of information that coexist within an enterprise: structured information and nonstructured information.

• Structured information is organized according to a preconceived, defined archetype. Each element of information corresponds to an element that specifies its type and its value domain. These information elements can be handled directly through IT processing. Databases constitute the main support for this type of information.

• Nonstructured information, such as textual documents, does not follow a predefined format. It is organized (for example, into chapters), but particular tools are required to process it. This is the field of electronic content management (ECM).

In recent times, two opposing movements have emerged. On the one hand, the transfer of a large amount of nonstructured information to a structured formulation: an order previously transmitted via a paper order form is now directly entered into a form via a website. On the other hand, the multiplication of nonstructured information in all its different forms: electronic messages, videos, forums, and so on. Let’s not forget that the number of documents available within an organization is often considerable, and that these documents contain a large proportion of its know-how.^w

Enterprises (and their employees) have opened up to the outside world, and this has further extended the boundaries of their communication. How can one not regard the web as a gigantic reservoir of nonstructured information?

Consequently, concentrating all efforts on structured information is too restrictive, and does not allow the reality of work modes today to be taken into account. Enterprise architecture also means looking into intranets, document organization, or the efficient management of electronic mail systems.^x

Resources and messages

Like stocks and flows, information is presented in two different ways:

• Persistent information, or resources, which last beyond business activities and processes.

• Exchanged information, in the form of messages whose content has a limited duration.

By definition, a client repository or a regulatory document contains persistent information. However, interapplication flows do not last. It is clear that persistent information requires special management in order to guarantee that it remains pertinent throughout its lifecycle. This is typically the field of the MDM (Master Data Management), which uses enterprise data synchronization and general management tools. However, the information transmitted during exchanges is more volatile and subject to fewer constraints. We will see that this can lead to some confusion.

Table 12.2 summarizes the different types of information that we have just discussed, with examples corresponding to the different possible cases.