The following discussion is meant to nuance and translate the perspective angle of modelling practice to an architectural approach.
To explain this point, we’ll use the well–known ArchiSurance case study, which illustrates the use of ArchiMate® in the context of TOGAF®’s business and IT viewpoints.
Figure 1 shows the model of the “Handle claim” process supported by the applications used by the Home & Away division of ArchiSurance.
As illustrated in this figure, the process “Handle claim” is composed of five sub-processes, namely: Capture information, Notify additional Stakeholders, Validate, Investigate, and Pay. These processes are undertaken by application services in blue ovals, which are themselves carried out by application components in blue rectangles.
For example, the Home & Away policy administration provides the claims administration service that undertakes the notification of additional stakeholders, as well as the validation, and the investigation.
“architecture” refers to the structure resulting from the way components are linked, and sub-processes are assembled to constitute the larger process (cf. ”building blocks” in TOGAF®).
Nevertheless, Architecture is not just a synonym of structure, nor masonry work.
Figure 2 shows how EXCOGITEA® represents the ”Handle Claim” process of ArchiSurance while including the following considerations:
When modeling a process, which is part of the Organization’s activities, one might need to consider which activity unit is accountable for that process.
When addressing a human intervention in a process, one might need to consider his authority in terms of decision-making, or simply his functional adequacy regarding his know-how, training, etc. Therefore, the profile of the human must be considered. Furthermore, it means considering the persons assignments to the activity team. And in fine, all persons within the Enterprise.
When supporting activity (processes) with applications, one might need to consider software dedicated to the activity unit, as well as non-dedicated software providing shared information and processing (Enterprise-wide).
As it is conceivable that non-dedicated software is managed by another team through other activity units, maybe even in different business lines, one can also conceive having dedicated software managed by another team, e.g., an IT team could be in charge of functional maintenance, technical instantiation and deployment.
The activity unit obviously uses and produces data/information. Again, it must be considered whether input data can be provided by other units, and output/produced data can be of use to other units.
Acknowledging this, going further up, one might need to only consider the units and their orchestration, without details (e.g., for overall governance purpose).
Hence, the Home&Away unit, aside an “Home&Present” unit, within an “Home&Troubles” business line, having the shared usage of information and applications defined in other dedicated units (e.g., accounting, invoicing, CRM), managed by different teams, etc. This regarding their respective identified goals, without being blinded by the detailed level of their content. Actually, shaping happens at different scales. For example, conceiving a hospital doesn’t start by water distribution in the surgeon’s locker room.
Those few points, yet key, bring an awareness and understanding of Architecture that goes beyond current practices.
Indeed, although current practices may address all modeled processes with an ”enterprise–wide” scope, Enterprise Architecture goes way beyond the execution items. It addresses all constituents, regarding their nature and not only their usage.
This leverage the context of cogitation to another level.