The Four Classical Elements Of The Digital World: Process, Service, Event, and Information

Just as Greek philosophers tried to explain the ancient world in terms of the four classical elements of Earth, Water, Fire, and Air - with the fifth element of Aether defining the invisible context in which they exist - software architects in the digital world work in disciplines that are centered around four basic elements - Process, Service, Event, and Information. However, I think we need a "unifying theory" of the digital world that brings these four elements together more closely.

Who's The Boss?
Too often, one or another of these four elements is elevated to a dominant position in architecture, often at the expense of sufficient attention to the others. Consider:

  • BPM elevates process - and is often coupled with services, as in the increasingly popular phrase "BPM with SOA." But events and information sometimes get short shrift in discussions of BPM.
  • SOA elevates service - but sometimes treats process as "just another layer," events as just "something to be emitted and consumed by services," and information hardly at all.
  • EDA elevates events - but often without sufficient integration into a broader view of SOA.
  • Information hasn't gotten as much attention lately, although at Forrester we've been excited for some time about the potential for Information as a Service, which brings information into the SOA fold. But one still encounters "information bigots" from time to time who are throwbacks to the "data is in the center of the universe" era, or worse yet, "information laggards" who think of data as only the persistent state information for services and processes.

How to solve this problem? First, consider this evidence regarding the intimate connection between the four elements:

  • BPM with SOA is indeed now the dominant trend for BPM. Forrester's survey data shows a high correlation between BPM and SOA implementations in the same shops.
  • A process can also be viewed as a service, in many situations. For example, micro-processes in BPM/SOA stacks often implement a composition of multiple lower-level, fine-grained services, delivering a more business-friendly interface and information model.
  • A service does indeed emit and consume events - although the significance of events is far greater than this connection. Another way to view this is that services are one of many different kinds of things that produce events, or are concerned about events arising from elsewhere.
  • An event can also be viewed as information - either singly, or in groups, a la Complex Event Processing. This is particularly important to an enlightened understanding of real-time business intelligence, both as it exists today, and as it will evolve in the future.

And this really only scratches the surface of all the ways the four elements fit together and are related to one another.

One of the over-arching frameworks Forrester has created to unify other architectures is Digital Business Architecture, that subdivides our understanding of the digital world into four domains. Here's a high-level view, in a version that shows the path to follow in each domain to get from today, to this end-state:

Dba

The scope of this over-arching framework is too large for our purposes, although the four IT elements do apply here - as further articulation of all these domains, from a different perspective.

Therefore, I think we really need to develop a more explicit unifying framework for processes, services, events, and information. Do you? One problem immediately becomes apparent as Forrester works on this: how to arrange the boxes on the picture! This seemingly simple issue is really a reflection of a deeper issue - if we view these four things as architectural layers, there's not really any way to put one above the other - here's a try, which is obviously wrong:

Psei_model

What's the problem? Well, a process can also be viewed as a service, an event is also information, etc. Plus, you can't always say that the layer below is consumed/used by the layer above - sometimes the relationship runs in the opposite direction.

So is this a situation akin to wave/particle duality? For you non-Physics types, this is the discovery from quantum physics that light exhibits properties of both waves and particles, and so is really neither, purely - it is what it is, and sometimes it seems like a wave, and other times it seems like a particle. I think this kind of non-Newtonian way of thinking about the physical world is helpful in understanding how the four elements of the digital world relate to one another.

I recently discussed this situation with Charles Brett, a Principal Analyst on our team, and Charles suggested a circular representation, with four pie-segments, each representing one of these four key "aspects" of the digital world. Here's a shot at that:

Processserviceeventinformation_2

So what  good does it do us to have this representation of the four elements of the digital world? On its own, not much. But I think it's a good starting point to help developers and architects to think about these elements in the right way. What else do we need to make this more useful? Here are some ideas:

  • In the classical Greek (or Hindu) understanding of the four (or five) elements, transformation of one element into another was not an inherent part of the model, although reactions between the elements were understood to be possible. However, even after a reaction, the elements were thought to be "particular and indestructible." However, in the Chinese philosophical doctrine of Wu Xing, instead of five elements, there are five phases, Metal, Wood, Water, Fire, and Earth. And inherent in Wu Xing is the idea that both destructive and generating transformational relationships between the phases exist - hence the choice of phase instead of element to refer to them.
  • Part of the detail of Wu Xing is the specification of these particular transformations that exist in the world: Wood feeds Fire, Fire creates Earth (ash), Earth bears Metal, Metal carries Water, and Water nourishes Wood. Likewise, Wood parts Earth, Earth absorbs Water, Water quenches Fire, Fire melts Metal, and Metal chops Wood.
  • So a complete system of understanding built around the four elements of the digital world would also specify a complete set of relationships between them - all the specific ways in which they relate, including transformation. Without getting into why the Chinese system could be "superior" to the Greek, it's clear that we need these kinds of relationships to understand all aspects of how an event can be information, while at the same time a service is triggered by an event, as the first step in a process the event initiates.

The bottom line: I believe it is important that we develop a complete, exhaustive model - a semantic model, really - of all the ways in which the four elements of the digital world relate to one another. This in turn will fuel a complete, exhaustive meta-model for representing these concepts in systems and tools, one that can model any system in the digital world, in any architecture, in a way that can stand the test of time and not need to be changed because of some new architectural fashion.

A tall order. Do you think I'm right? Or is this a Quixotic quest? Please respond with your suggestions!

Categories:

Comments

re: The Four Classical Elements Of The Digital World: Process,

Maybe the problem is trying to classify things in IT terms, e.g. because as you note, a service can do more than one thing. Following your physics analogy, perhaps we need to get more "fundamental".Information drives decisions. Decisions drive actions. Actions either create value or information, which can be fed back into the cycle. So, a service could provide information, make a decision, or trigger an action. Events can come from all three domains. Process connects the pieces, etc.I'm going to have to pick a bone with the "wave/particle duality". This idea is one of the most widely misunderstood, even amongst professional physicists (who you think would know better). The problem arises in trying to explain a new phenomenon (quantum effects, not really so new) in terms of old ontologies (waves, particles). Quantum field theory requires a fundamentally different ontology about how physical states evolve, though there's some conceptual overlap with classical ideas about waves and particles; there are also effects explained by neither classical concept. Indeed, this situation might be a better analogy for why the Information/Event/Service/Process classification appears to be so slippery.

re: The Four Classical Elements Of The Digital World: Process,

Interesting idea about decisions - in fact, James Taylor made the same observation, and I think you and he are right that Decision, or some meta-object that relates to rules, needs to be considered for inclusion in this model.My criterion for including something here is, at least in part, that it can be in an "Is A" relationship with the other things. Meaning, under some circumstances, one can say:-- A Service "Is A" Process-- A Process "Is A" Service-- An Event "Is" Information-- and so on.On the other hand, I have not yet seen a way in which an Event "Is A" Service, or a Process - rather, it triggers a service or process, or is emitted by a service or process.I don't think a Decision "Is" any of these things. There's no question that if we break these things down to their more fundamental elements, as you suggest, that Decision would be among the fundamental elements. Having meta-modeled this domain before, I can tell you that it's extremely complex, and the value of modeling it is somewhat limited, except to designers of languages or runtimes (or, for another example, the designers of model-driven execution languages like BPEL or XLang).So I want to do more modeling work here to build out the part of the model around Process-Event-Service-Information (PESI?), and need to look at whether there's some aspect of decisions or rules that can also be included at that level, which is not at the level of logic flow, but at the level of a "key business decision" (for example) that would be managed directly by the business. I think that's possible, I just haven't thought through it yet (need to spend some time in front of a white board with a few colleagues, I think).James and I also hope to do some scrawling on the back of a cocktail napkin, while sharing a drink in Vegas next week. So if you'll be at Forrester's IT Forum, you're welcome to join in for that discussion.Thanks for your post, and for pushing us on this point!

re: The Four Classical Elements Of The Digital World: Process,

This reminds me of my introduction to Data Processing (as it was called nearly 40 years ago when I first studied the subject).In your list of four elements, Process and Services are at a higher level of abstraction than Information and Events, and consequently have been more recently introduced into IT vocabulary.To complete the definitions of Information and Events we need also to recall the definitions of Data Processing Systems, Data, State and Messages. So:A Data Processing System (DPS) is a collection of (biological or artificial) components arranged so that they can store and process Data.Data are collections of symbols. They come in two forms. They can represent the State of a DPS at a point in time. Or they can can form a Message that has the ability to change the state of a DPS.Messages that can change the state of a human mind are known as Information. The change in state of the human mind is called Meaning. [Very little of the data that resides in our computers is Information or can convey Meaning to most humans.]Events are changes in State. Events are fully described by (reference to) the Message that triggered the event, the resulting State Change and the Event context (eg time of event).A Service is a DPS that produces machine-readable messages that convey Information [ie Data that is meaningful to the humans that use the system]. The use of Web Services messaging standards is not fundamental to whether a DPS is a service.A Process is an ordered sequence of Services designed to produce "more useful" Information and Events than any individual Service can produce on its own.

re: The Four Classical Elements Of The Digital World: Process,

I agree with most of what you say, Dave, except that:1) An event that happens outside the context of a DPS may not have any visible impact on the state of the DPS, but is still an event. Analytics over a collection of such events (really, of the data that represents them) can in turn extract correlated events which are relevant to the DPS and trigger a message that causes a state change.2) We use the term Information not in the way you do (which I think is also a perfectly valid convention), but instead to refer to the superset that includes all of structured, semi-structured, and unstructured data, a.k.a. content. So meaning to a human is not a prerequisite to be information, in the way we've been using the term.3) That's why we say that an event can be represented by information - but it's really just data.Also, I've been thinking about why we are scoping the discussion of these meta-entities in the way we are - it is that we are focusing on the things that matter to what Forrester calls "Dynamic Business Applications." That is, these are the elements that enable applications to exhibit more dynamic behavior than is normally possible when code changes are the only way to effect a behavior change. So Rules are another great example that qualifies.

re: The Four Classical Elements Of The Digital World: Process,

Hi Mike, this is a very good basis for discussion. Thanks. A few remarks: On the subject of the wave/particle duality, there is no such thing. Simply because there is no particle. Mass is no more than another form of energy. The duality is created by how you interact with the energy. The receiver is as important as the sender in defining what happens and it has to do with resonance. No resonance, no energy exchange. Scientists describe each of the possible resonances as the nuclear forces or fields. But still it is a good simile to the IT problem.Like in physics, what the four elements of an application are seen as depends on how you interact with them. While I agree with the need to structure applications, I personally feel that both BPM and SOA are overrated. Both require rigidity in implementation, but are then to offer more agility? How? Yes, maybe compared to Java coding ...Process should not be a rigid procedure but a goal-driven assembly of information (including content BTW) based on metadata (repository), interfaced with data federation or backend services (from a registry), controlled by a state/event progression, and constrained by business rules. But you need two more things. Process has to be built upon organizational role/policy (security) definitions and it has to be displayed using presentation services (into GUI and content!).You are right: all this needs to be related to each other, but that depends on how you manage the application to keep it agile. In the ISIS Papyrus Platform we solved it by assembling applications by means of an object-relational database, allowing dynamic changes of relations from version to version at any time.There is no single exhaustive IT model that will work for everything. We need to give up reductionism in IT as in physics. I go with Nobel laureate Robert B. Laughlin who says that in nature complex systems are emergent and can not be causally predicted from its parts. Yes, I agree with you: IT is like physics and that is why emergent chaotic social computing like the Internet does more than all the hard-coded applications and all BPM and SOA on this planet.BPM and SOA are to agility what communist governments are to freedom and free markets.

re: The Four Classical Elements Of The Digital World: Process,

Some thoughts about these terms can be found here:http://epthinking.blogspot.com/2008/08/on-first-class-citizens-of-enterprise.html

re: The Four Classical Elements Of The Digital World: Process,

The previous comments has been done by myself, sorry for the error in submission.Opher

re: The Four Classical Elements Of The Digital World: Process,

Mike G. gave us the classical view, and I think those building blocks still hold. Dave C., your #2 is DATA not information. It isn't information until data is transformed (by process) into something that "drives decision" (thank you Mike). I like the extension of the notion of event, but is it an event in the context of the system if it is invisible. Maybe not until it becomes visible. Data and events are atomic, concrete, or at least the lowest level of abstraction with which systems deal and react.Process is a higher abstraction, and service higher yet. Processes transform data into information and are in turn triggered by or trigger events, etc.thanks for interesting discussion

re: The Four Classical Elements Of The Digital World: Process,

I'm thrilled that this discussion has continued! Apologies for not having posted in a while. Some thoughts about things back up the thread:1) Wave/particle duality. Sure, the concept of a wave or a particle is really just a shorthand for the "entity" in question (not the sort of entity Opher is talking about, more just a general "thing") exhibiting behavior in a particular situation that can be conveniently modeled more as a particle, or as a wave. But it really is the same underlying thing, and if at one moment it can seem to be a wave, at the next moment it can seem to be a particle. I was interested to read about recent enhancements at CERN which may create mini black holes in search of the elusive Higgs Boson, using the new Large Hadron Collider:http://news.cnet.com/8301-11386_3-10011229-76.html2) Does this issue, the same "thing" being more conveniently modeled in one way, or another, at different times, provide a useful tool for this discussion? I think it does. Note in Opher's post on his own blog that he models event vs information as discrete things, where one is never the other. The key point I'm trying to introduce is that under other circumstances we may wish to model the content that represents a stream of events as being simply a set of information, which we want to analyze (as in CEP). And in one very real sense it is just information - bits in memory - which we can plug into a query engine and process just like we might process the contents of an in-memory database.3) Why does this matter? I think the discussions analysts and various other experts have around things like BPM, CEP, EDA, and SOA are far too divisive and stovepiped. Also in Opher's post he points out this same division between SOA and EDA, and questions its value.At Forrester we have long sought to be uniters and not dividers (ugh!) of these architectural disciplines. So rather than depicting the progression of architectural disciplines as some kind of long march which is always making the older disciplines passe' and creating new ones to be the subject of new research papers and conferences, we view it as more a long process of refinement of our (the industry's) understanding of how best to model and create software systems. SOA is refined by BPM, refined by events (call it EDA if you like), and so on.4) Max Pucher's post is in synch with this idea, that you really need all these things to be modeled and supported together in one cohesive way in order to take full advantage of them all. This does present a challenge for the industry, which has an ecosystem model which tends to create bits of technology here and there, then aggregate them together through acquisitions. It's hard (but not impossible, as Papyrus shows) to create a solution that, from the start, attempts to unite all these things. But even then, it's an imperfect world, because in a sense it is a long march - it just keeps on evolving. Any company has to make and sell a product at a moment in time, and it's hard to evolve your underlying meta-meta-model in any significant way once you've laid it down. That is, the set of architectural assumptions (and inevitably, limitations) upon which one's product vision is founded, is hard to evolve to embrace these new things as they come along.5) Still, there's hope. It's interesting to see examples of these technologies being aggregated through acquisition (or foresight, as for Max). Progress has done a good job of bringing together service and event, with less strength around process. It's about to make a much stronger play around information (as in, Information-as-a-Service). But then as the Oracle/BEA combination shows, it's really, really hard - sometimes impossible - to "mash" bits of software created in different labs together, if they weren't created in a way that makes that feasible.I'd better stop now. More later!Mike

re: The Four Classical Elements Of The Digital World: Process,

Mike,What about the work being done at the intersection of information and ontology? Your reference to meta-models suggests this world, both the ontology work in information science and specifically the "upper ontology" idea to create semantic harmony across disciplines. Could this work inform your objectives perhaps?John

re: The Four Classical Elements Of The Digital World: Process,

Mike,What about the work being done at the intersection of information and ontology? Your reference to meta-models suggests this world, both the ontology work in information science and specifically the "upper ontology" idea to create semantic harmony across disciplines. Could this work inform your objectives perhaps?John

re: The Four Classical Elements Of The Digital World: Process,

John, thanks for making this point. Yes, the work at the intersection of information and ontology, especially in attempting to make use of semantic technologies to complement or even replace other approaches to information modeling, is relevant to this question. I'm not an expert on semantic technology, but it looks to me like:1) The four areas (Process, Event, Service, Information) would each be domains where particular semantic perspectives would hold - and the semantic infrastructure would map between them.2) A given instance of meta-information could then be viewed from any of these perspectives that are relevant to that instance, and in each perspective, it would exhibit the attributes and relationships that make sense in that domain. So in the event domain, one event might "trigger" another (a form of relationship carrying specific meaning), whereas when viewed in the information domain, that same instance would just have a one-to-many relationship back to itself to show that one could be related to one or more others.One thing we've found so far in researching how semantic technology is being used, is that it's seen as overly complex and costly for simpler situations where existing approaches based around SQL or XML are working reasonably well. Whereas in other situations (defense, intelligence, and clinical medicine) its power is needed to deal with the complexity of the modeling requirements, and in particular the ability to support multiple perspectives/domains, and leave them somewhat flexible relative to each other.