SciFi architecture

Comment on Editorial Paper

DOI: 10.1007/s41251-016-0006-8

Cite this article as:
van Gils, B. Organ Des Enterp Eng (2017) 1: 33. doi:10.1007/s41251-016-0006-8

Abstract

(Enterprise) Architecture has emerged as a key discipline in dealing with continuous change/transformation in which models play a key role. In most current modelling languages (e.g. ArchiMate\(^{{{\textregistered }}}\)) there is a clear distinction between “business concepts” and “IT concepts”. The question that is addressed in this paper is: is that still justified? It is argued that a more symbiotic relationship between human actors and computer actors, performing essential (business) behaviour side by side is the way to long term success. We also briefly touch upon the impact of such change in (modelling) approach on the way we deal with these transformations from a methodological point of view.

Keywords

Architecture Modelling Transformation 

1 Introduction

The topic of ‘change’ and how to handle it has been discussed extensively over the last few decades, especially while referring to the adage that “the only constant is change”. Indeed, we see constant changes in regulations, technology, socio-economic relations etcetera. This can be both a threat as well as offer opportunities, and leaves organizations with strategic challenges related to process (deliberate versus emergence, rational versus creativity, etc.) as well as content (which business model? which position in the market?) [19, 25]. It has also led to the emergence of a wide variety of approaches to dealing with change in the organization such as Enterprise Architecture (EA) and Enterprise Engineering (EE) [5, 7, 8, 16].
Fig. 1

Realizations of a pattern

Often it is claimed that these approaches are/should be ’holistic’ in nature, taking all relevant concerns into account. While this makes sense, it is easier said than done. The same goes for deciding on a course of action to implement/achieve change: approaches range from a top-down, command and control approach to bottom-up, participatory change (e.g. [1, 6]).

2 The business/IT dichotomy

One of the reasons that we are not as successful in dealing with these challenges lies in the fact that we consider ’business’ and ’IT’ to be two separate things. This distinction may have made sense in the early days when information processing was a new and specialized skill (see e.g. [4] for a good overview of the history of computing ). These days it is safe to say that ‘there is no business without IT’. The era where IT was mainly used for text processing and handling repetitive tasks is well behind us. Most value streams of enterprises run on IT, or are supported by IT. However, information systems are still treated as second class citizens by all accounts. A symbiotic view where human actors and information systems work side by side as equal partners is hard to digest by many. It is only to be expected that a situation will emerge where not non-human actors are alien, but those who fail to accept this new type of equality.

We also see this in many architecture frameworks/modelling languages such as TOGAF\(^{{{\textregistered }}}\) and ArchiMate\(^{{{\textregistered }}}\) [7, 13, 17, 18]. A model is generally defined as “a purposely abstracted conception of some domain”, which appeals to the fact that models are created for a reason. These reasons may vary from sense making, design, or analysing the impact of certain (desired) changes. The definition also suggests that models are a mental construct which can be represented in languages such as ArchiMate\(^{{{\textregistered }}}\). In this language, the conception of a domain by a modeller is presumed to consist of elements that are related. There are different types of elements, classified as being either structural or behavioral in nature. Structure elements are further categorized as being either active or passive. A second, orthogonal, classification of elements pertains to layering. Elements (from the ‘core’ of the language) are considered to be part of the business layer, application layer, or technology layer. This creates concepts that are considered to be ‘business behavior’ (i.e. a business process) versus ‘application behavior’ (i.e., an application function). Similarly, we can distinguish between ‘business structure’ (i.e., actors) and technology structure (i.e., nodes).

This appears to make sense. There is a reason why the number of ArchiMate\(^{{{\textregistered }}}\) practitioners is still increasing. In light of the challenges that are outlined above, though, there are some issues that should be resolved if ArchiMate\(^{{{\textregistered }}}\) is to be taken seriously when our way of thinking about symbiosis between business actors and information systems actors matures.

3 A change in perspective

The first issue goes back to the example in the previous section: if core value streams are being executed by our information systems, then how relevant is the business/IT dichotomy? Can we (still) safely argue that an information system is ‘merely’ an application? A second issue is more philosophical in nature: can we really differentiate between business behaviour and application behaviour, or is this construct artificial and superfluous? After all, the distinction is based on the type of structure element that executes the behaviour.

In this respect it is interesting to note that we, as society, are in a state of transition: it seems that we accept the help of information systems and even robots in many areas of our society (think of robots that perform surgery, automated driving, manufacturing, etc.) but ultimately humans are still responsible for their behaviour. This is despite the fact that machines have (or: are about to) surpass our abilities on many levels. Accepting a SciFi scenario where machines are our equals is, for many, still at least one bridge too far.

Figure  1 shows an example of what can be achieved by letting go of the layering in the behaviour elements. We see a single pattern with behaviour (e.g. a process) which is assigned to a structure element that will execute it. It has three realizations, each with separate characteristics:
  1. 1.

    Realization A can be considered a “straight through process”, the desired behaviour is executed by a application structure element. A characteristic for this realization would be a KPI that measures the straight through degree, and the first time right degree.

     
  2. 2.

    Realization B can be considered a “manual process” as the desired behaviour is executed by a business structure element. Here a straight through degree would not make sense. Relevant KPI’s would be the average waiting time, and the first time right degree.

     
  3. 3.

    Realization C can be considered a “semi automatic process” where two structure elements from different layers work together in completing the process (more specifically, the business structure element executes the process and in doing so uses the application structure element). Similar KPI’s would work here.

     
Such an approach raises a host of new questions and possibilities which are beyond the scope of this text. One of the things that should be pointed out, though, lies in the fact that this way of modelling will make it possible to represent the (levels of) pattern(s) that we would like to see realized in the real world by achieving what was specified in the architecture, and compare it to the actual realized “instances”, something would be of major value for rationalized decision making in managing the enterprise.
Fig. 2

Effectiveness of realization

Figure 2 shows another example. Again we have a pattern of a behavioural element that is executed by a structure element. In this case the realization is more complex and requires one business structure element and two application structure element, each working in concert to realize the desired pattern. The analysis on the top right indicates that the “realization degree” is fairly high, but the effectiveness of the realization is very high. Such insights can be used in investment decisions. As a side note: the actual realized structure might be ‘discovered’ using techniques from the realm of process mining (see e.g. [24])

Examining the examples more closely leads to the insight that human actors and computerized actors (which can be modelled as a mix of hardware and software elements) collaborate actively in executing behaviour in the enterprise. This is not as SciFi as it may seem: as mentioned previously, we see this in many industries already. For example, in Broadbent et al. [3] it is reported that robotics can, under the right circumstances, be accepted in health care even by the ‘older’ generation (the assumption being that this is typically the group having a hard time accepting such radical innovations). It is not uncommon in SciFi movies such as StarWars and Startrek for robots to be (semi) sentient, show social behaviour, and appear to have a mind of their own. Indeed this goes a few steps beyond where we are now. However, it appears that this is starting to happen in reality too in various branches and we better make sure that our (architecture) methods are ready to handle this shift in mindset.

4 Mindset for change

If we manage to change our mindset and accept the fact that human and computerized actors are increasingly equal (i.e., accept a ‘cybernetic’ view [2, 15]) then this should also be reflected in the way we consider change/engineering the enterprise. Unfortunately it appears unlikely that we can simply ‘leverage the force’ to make change happen. In this final section I will explore several aspects related to the ‘mindset for change’ in such complex socio-technical environment by raising and formulating research topics.

It is a well established fact that data and information systems are increasingly important for modern day enterprises: data is the new oil [11, 14]. Being able to do business any time, any place, anywhere is increasingly important with more and more people having access to high speed (mobile) internet, advanced gadgets and the power of ‘social’ [9, 10]. This requires a digital platform for execution and sufficient agility to deal with the ever increasing demands of customers [12, 20].

It is often said that ‘the only constant is change’. In the digital enterprise, though, it is essential to go one step further. The constant change of flux is best characterized as continuous transformation which is defined as “the orchestrated (re)design of the architecture of the enterprise” in line with Rouse [21]. The main distinction lies in complexity and scope: transformation covers various aspects of the enterprise, from strategy, processes, information/data, organization to technology.

Professionals—at all levels of the organization—will have to learn how to deal with this new reality. This will be challenging to say the least. To stay within the SciFi theme: it may well be compared to training to become a Jedi-knight by wielding the force; it requires a new ‘world-view’ and major shift in perspective.

The Cynefin framework [23] distinguishes between a simple domain, complicated domain, complex domain, and chaotic domain. For purposes of this discussion, the complicated domain and complex domain are relevant. A situation is said to be complicated if it can still be analysed in order to find a likely solution to a problem: it is hard work, but it can be done. Typical examples are the development of an information system, or rationalising an information systems landscape. The key characteristic of the complex domain is that a situation can not be analysed. All we can do is attempt to get a sense for the situation, act, and monitor whether our action has a positive or negative effect. This not only increases our understanding of the situation, it also helps in deciding on the next course of action (strengthening/dampening). Practitioners often have a bias towards one of these perspectives [22].

In current (business) practice, it is a wide-spread belief that—in Cynefin terms—change in the IT domain are mostly in the complicated domain, whereas organisational change is mostly in the complex . This is of course a gross over simplification. Even more, in the new ‘symbiotic’ paradigm it will be increasingly clear that this line of thinking is plain wrong: there is no real distinction between business and IT any more. It is to be expected that the ongoing transformations, mixed with a new world view will increasingly entice professionals to consider situations to be in the complex domain.

In this domain, models will still play an important role. Rather than the traditional view on models (used to either document the essence of a current or future situation), in the complex domain they are mostly used for sense-making: models are a hypothesis of what a situation could (baseline situation) or should (target situation) look like, and are used to select a course of action that seems viable. They will have to shed light on hard questions such as: how much trust do we place in computer actors? what are the legal implications of letting teams of human and software actors perform primary processes? Are ‘old’ legal structures around privacy and security still viable?

5 Conclusion

In this article we have briefly explored implications of a more symbiotic relation between human and computerized actors, working together to accomplish the mission of an enterprise. It may still sound like a SciFi scenario, but then again: the future is only just around the corner. Such vision raises several research topics, such as: what does this mean for the way we handle continuous business transformations in the digital space? Is it feasible to analyse the complex interactions between different types of actors (human and computer) and the interplay of their behaviours? What requirements does that pose on modelling language that are used in this realm? How managers and practitioners in the field be trained in learning to act profitably/effectively in the light of a new paradigm where human and computer actors are equal citizens? How can we train change agents (architects, program- and project managers, etc.) to use the new methods and approaches effectively?

There is a lot that can be learned in a ‘laboratory’ setting, by analysing practical cases, drawing on a body of research from various disciplines such as management, technology, psychology, and engineering. However, bringing these results back into the field, to the practitioner, may turn out to be the hard problem.

Copyright information

© Springer International Publishing Switzerland 2017

Authors and Affiliations

  1. 1.Strategy AllianceLelystadThe Netherlands

Personalised recommendations