#entarch
#bizarch
#UnicomEA
#SSM
#VSM
#VPEC-T
At yesterday's EA Forum, a rich picture of the oil industry was presented by
Mesbah Khan, who then posed a question about the possible use of such a picture, for enterprise architecture and beyond.
The rich picture is a core technique of the Soft Systems Methodology (SSM). Over the years, there have been many attempts to produce hybrid methodologies combining SSM with more structured systems approaches. One of the earliest such attempts was Multiview, produced by Trevor Wood-Harper and others in the mid 1980s. In Multiview, a version of SSM is used to analyse issues, and these are then aligned with the analysis of tasks using a more conventional IS modelling approach.
Among other things, Mesbah's rich picture model features stakeholders and their concerns (shown as bubbles), and identifies the conflicts between different stakeholder concerns (shown as crossed swords). This is clearly equivalent to Multiview's analysis of issues.
Nowadays, the terms "stakeholder" and "concern" are mandated by ISO 42010, and incorporated into several enterprise architecture frameworks. (However, stakeholder concerns are often presented as a relatively homogeneous and consistent set of goals and objectives, e.g. using the Business Motivation Model or other schemata, and there is often not enough attention given to the conflicts between stakeholder concerns.)
As I see it, each of these conflicts calls for a series of capabilities or activities to govern the conflict - to allocate resources, balance priorities, and contain the risks. (However, these capabilities and activities are often absent or marginalized in the structured models produced for IT purposes.) They also have important implications for organizational design and trust.
One way of looking at these management and control capabilities is to use a cybernetic view of the enterprise, such as Stafford Beer's VSM. Mesbah indicated that his rich picture can be mapped onto VSM, but he did not have time to present this mapping at yesterday's forum.
Meanwhile, the trust issues may require a different style of analysis, such as VPEC-T, which helps to highlight those issues that are typically "lost in translation" when we go from a "rich" model to more abstract and homogenized "structured" models. See my note Does Rigour Matter?
Showing posts with label VSM. Show all posts
Showing posts with label VSM. Show all posts
Friday, September 28, 2012
Sunday, June 17, 2012
The Cybernetic View
#bizarch One of the Six Views of Business Architecture is the Management View or Cybernetic View. To understand this view, let's start by asking what kind of thing management is.
One way of thinking about management is as a particular bundle of capabilities, such as planning, resource allocation, monitoring and control. These capabilities can be mobilized according to some routine schedule of activity (for example, the annual budget cycle), or in response to various events inside and outside the enterprise. So we can view management from a Capability viewpoint, or from an Activity viewpoint.
Another way of thinking about management is as a particular bundle of role and responsibilities. These may be presented as a hierarchy or matrix, although such depictions are usually highly simplistic. Management responsibilities may be controlled by a select group of senior staff, with "manager" or "director" or "officer" in their job title. Alternatively, they may be wholly or partially distributed to other staff along with various operational responsibilities. In any case, the real (defacto) distribution of roles and responsibilities is usually much more subtle and flexible than the official (orgchart) distribution. (cf The Four Organizations of Lord Brown.)
We may therefore view management at different levels of abstraction - either specifying the concrete division of responsibilities between named roles or even named individuals, or merely identifying the total set of responsibilities without allocating them to specific roles.
Both the Capability view of management and the Responsibility view of management are useful, but neither of these viewpoints really captures what is distinctive about management. Instead, we need to turn to a systems view of management, inspired by such thinkers as W. Ross Ashby, Russell Ackoff, Stafford Beer and Gregory Bateson. Let's call this the Cybernetic View.
The Cybernetic View is based on the idea of goal-directed behaviour, based on feedback and feedforward loops. This is elaborated into various frameworks, including Stafford Beer's Viable Systems Model (VSM).
A conventional interpretation of the Viable Systems Model is that it models an organization from the viewpoint of a neutral and all-seeing observer. The cybernetic literature can be divided into First-Order Cybernetics, which accepts this interpretation, and Second-Order Cybernetics, in which the position of the observer is itself problematic.
Bateson's work on Second-Order Cybernetics has directly or indirectly inspired many generations of management and organization scientists, including Chris Argyris, Donald Schön, Kenwyn Smith and Peter Senge, and I have used many of their ideas in my own framework for Organizational Intelligence. Some researchers are currently exploring Third-Order Cybernetics, but this is not yet mainstream.
The Cybernetic View should also embrace Robert Rosen's concept of Anticipatory Systems -
The Cybernetic View provides a useful complement to a conventional process view. As I pointed out in my post on Collaboration Impact Zones, AS-IS models can often be incomplete descriptions of reality, because they fail to document all the informal communication and coordination mechanisms that keep the business running. One way to discover these missing elements is to analyse the AS-IS models according to cybernetic or statistical principles, which may allow us to infer the existence of some coordination mechanism, even though we don't have any visible evidence of coordination taking place.
See also my earlier post Organizations as Brains.
My booklet on Business Architecture Viewpoints is now available in draft on the LeanPub platform. http://leanpub.com/businessarchitecture-viewpoints/
One way of thinking about management is as a particular bundle of capabilities, such as planning, resource allocation, monitoring and control. These capabilities can be mobilized according to some routine schedule of activity (for example, the annual budget cycle), or in response to various events inside and outside the enterprise. So we can view management from a Capability viewpoint, or from an Activity viewpoint.
Another way of thinking about management is as a particular bundle of role and responsibilities. These may be presented as a hierarchy or matrix, although such depictions are usually highly simplistic. Management responsibilities may be controlled by a select group of senior staff, with "manager" or "director" or "officer" in their job title. Alternatively, they may be wholly or partially distributed to other staff along with various operational responsibilities. In any case, the real (defacto) distribution of roles and responsibilities is usually much more subtle and flexible than the official (orgchart) distribution. (cf The Four Organizations of Lord Brown.)
We may therefore view management at different levels of abstraction - either specifying the concrete division of responsibilities between named roles or even named individuals, or merely identifying the total set of responsibilities without allocating them to specific roles.
Both the Capability view of management and the Responsibility view of management are useful, but neither of these viewpoints really captures what is distinctive about management. Instead, we need to turn to a systems view of management, inspired by such thinkers as W. Ross Ashby, Russell Ackoff, Stafford Beer and Gregory Bateson. Let's call this the Cybernetic View.
The Cybernetic View is based on the idea of goal-directed behaviour, based on feedback and feedforward loops. This is elaborated into various frameworks, including Stafford Beer's Viable Systems Model (VSM).
A conventional interpretation of the Viable Systems Model is that it models an organization from the viewpoint of a neutral and all-seeing observer. The cybernetic literature can be divided into First-Order Cybernetics, which accepts this interpretation, and Second-Order Cybernetics, in which the position of the observer is itself problematic.
Bateson's work on Second-Order Cybernetics has directly or indirectly inspired many generations of management and organization scientists, including Chris Argyris, Donald Schön, Kenwyn Smith and Peter Senge, and I have used many of their ideas in my own framework for Organizational Intelligence. Some researchers are currently exploring Third-Order Cybernetics, but this is not yet mainstream.
The Cybernetic View should also embrace Robert Rosen's concept of Anticipatory Systems -
"A system containing a predictive model of itself and/or its environment, which allows it to change state at an instant in accord with the model's predictions pertaining to a later instant." Wikipedia
The Cybernetic View provides a useful complement to a conventional process view. As I pointed out in my post on Collaboration Impact Zones, AS-IS models can often be incomplete descriptions of reality, because they fail to document all the informal communication and coordination mechanisms that keep the business running. One way to discover these missing elements is to analyse the AS-IS models according to cybernetic or statistical principles, which may allow us to infer the existence of some coordination mechanism, even though we don't have any visible evidence of coordination taking place.
See also my earlier post Organizations as Brains.
My booklet on Business Architecture Viewpoints is now available in draft on the LeanPub platform. http://leanpub.com/businessarchitecture-viewpoints/
Important note - I haven't read all of these papers myself yet, so I'm putting them here for my own reference as well as yours. Update: Professor Vidgen kindly dug out a paper he wrote ages ago.
Sabine Buckl, Florian Matthes, Christian M Schweda, A viable system perspective on enterprise architecture management. 2009 IEEE International Conference on Systems Man and Cybernetics (2009)
Gil Regev, Ian Alexander, Alain Wegmann, Use Cases and Misuse Cases Model the Regulatory Roles of Business Processes. Business Process Management Journal, "Goal-oriented business process modelling" Guest Editors: Ilia Bider and Paul Johannesson Volume 11 Number 6 2005 pages 695-708
Richard Vidgen, Cybernetics and business processes: using the viable system model to develop an enterprise process architecture. Knowledge and Process Management, 1998.
Anders Jensen-Waud, Paradoxes in EA and Systems Research (April 2010)
Mohammad Esmaeil Zadeh, Gary Millar and Edward Lewis. Mapping the Enterprise Architecture Principles in TOGAF to the Cybernetic Concepts--An Exploratory Study (2012 45th Hawaii International Conference on System Sciences)
Mohammad Esmaeil Zadeh, Gary Millar and Edward Lewis. Reinterpreting TOGAF’s Enterprise Architecture Principles Using a Cybernetic Lens (Journal of Enterprise Architecture, May 2012)
Saturday, March 10, 2012
Structure Follows Strategy?
#entarch In his talk to the BCS Enterprise Architecture Group this week, Patrick Hoverstadt suggested that traditional enterprise architecture obeyed Alfred Chandler's principle: Structure Follows Strategy. In other words, first the leadership defines a strategy, and then enterprise architecture helps to create a structure (of sociotechnical systems) to support the strategy.
Chandler's principle was published in 1962, and is generally regarded nowadays as much too simplistic. In 1980, Hall and Saias published a paper asserting the converse principle Strategy Follows Structure! (pdf), and most modern writers now follow Henry Mintzberg in regarding the relationship between strategy and structure as reciprocal.
What are the implications of this for enterprise architecture? Patrick offered us a simple syllogism: if enterprise architects determine structure, and if structure determines strategy, then enterprise architects are (consciously or unconsciously) determining strategy. In particular, the strategies that are available to the enterprise are limited by the information systems that the enterprise uses (a) to understand what is going on both internally and externally, and (b) to anticipate future developments. In many situations, the information isn't readily accessible in the form that managers would need to mobilize a strategic response to the complexity of the demand ecosystem.
Of course it isn't as simple as this. The defacto structure (including its information systems) is hardly ever as directed by enterprise architecture, but is created by countless acts of improvisation by managers and workers just trying to get things done. (The late Claudio Ciborra wrote brilliantly about this.) People somehow get most of the information they need, not thanks to the formal information systems but despite them. Thus the emergent structures are a lot more powerful and rich than the official structures that enterprise architects and others are mandated to produce. Patrick cites the example of a wallpaper factory where productivity was markedly reduced after smoking was banned; a plausible explanation for this was that smoking had provided a pretext for informal communication between groups.
Meanwhile, Minztberg drew our attention to a potential gulf between the official strategy and the defacto emergent strategy. (I have always especially liked his example of the Canadian Film Board, published in HBR July-Aug 1987.)
Nevertheless, Patrick's mission (which I endorse) is to connect enterprise architects with the strategy processes in an enterprise. He is a strong advocate of Stafford Beer's Viable Systems Model (VSM). Using his approach, which he encourages enterprise architects to adopt, VSM provides a unique lens for viewing the structure of enterprise, and for recognizing some common structural errors, which he calls pathological; I encourage enterprise architects to read his book on The Fractal Organization.
Related post: Co-Production of Strategy and Execution (December 2012)
Chandler's principle was published in 1962, and is generally regarded nowadays as much too simplistic. In 1980, Hall and Saias published a paper asserting the converse principle Strategy Follows Structure! (pdf), and most modern writers now follow Henry Mintzberg in regarding the relationship between strategy and structure as reciprocal.
What are the implications of this for enterprise architecture? Patrick offered us a simple syllogism: if enterprise architects determine structure, and if structure determines strategy, then enterprise architects are (consciously or unconsciously) determining strategy. In particular, the strategies that are available to the enterprise are limited by the information systems that the enterprise uses (a) to understand what is going on both internally and externally, and (b) to anticipate future developments. In many situations, the information isn't readily accessible in the form that managers would need to mobilize a strategic response to the complexity of the demand ecosystem.
Of course it isn't as simple as this. The defacto structure (including its information systems) is hardly ever as directed by enterprise architecture, but is created by countless acts of improvisation by managers and workers just trying to get things done. (The late Claudio Ciborra wrote brilliantly about this.) People somehow get most of the information they need, not thanks to the formal information systems but despite them. Thus the emergent structures are a lot more powerful and rich than the official structures that enterprise architects and others are mandated to produce. Patrick cites the example of a wallpaper factory where productivity was markedly reduced after smoking was banned; a plausible explanation for this was that smoking had provided a pretext for informal communication between groups.
Meanwhile, Minztberg drew our attention to a potential gulf between the official strategy and the defacto emergent strategy. (I have always especially liked his example of the Canadian Film Board, published in HBR July-Aug 1987.)
Nevertheless, Patrick's mission (which I endorse) is to connect enterprise architects with the strategy processes in an enterprise. He is a strong advocate of Stafford Beer's Viable Systems Model (VSM). Using his approach, which he encourages enterprise architects to adopt, VSM provides a unique lens for viewing the structure of enterprise, and for recognizing some common structural errors, which he calls pathological; I encourage enterprise architects to read his book on The Fractal Organization.
Related post: Co-Production of Strategy and Execution (December 2012)
Monday, February 06, 2012
Organizing Business Capabilities
#entarch #bizarch Following a Linked-In discussion on business architecture and capability modelling, I was slightly alarmed to see how many contributions to the discussion were based on an argument from authority: IBM says this, Michael Porter says this, Forrester/Gartner says this.
Obviously these are all clever guys, but does that mean they have all the answers? Someone claimed that IBM's model was based on something called "natural clustering", but I don't know what he thinks that means. The only clustering I've ever seen used in architectural contexts has been artificial, meaning that what you get from clustering depends a lot on what algorithm or mechanism you use, as well as when (at what stage in the process, the level of granularity) you choose to carry it out.
In any case, I am sceptical of generic architectures. If I want a house that is exactly the same as everyone else's house, I don't really need an architect at all - I just need a structural engineer to calculate the strength of the beams and align the plumbing. I don't expect an architect to spend months just giving me a slightly modified copy of something he found in a textbook.
I think the interesting question is how to derive a capability map from the particular behaviours of an organization and the particular intentions of its leadership, rather than just imposing some off-the-shelf business school or vendor nostrum.
So, what kind of capability map do we need to understand the organization of capabilities? Many people think all we need to do is identification and classification - decomposing the enterprise into a set of independent capabilities. Business analysts can then document each capability separately (I sometimes use a capability canvas that is adapted from Osterwalder's business canvas), decide which capabilities are of greatest strategic importance, and produce a plan for business improvement. (The UK MOD practises a methodology called Through-Life Capability Management, and a casual Internet search will identify several large consultancies and systems houses that claim expertise in this area.)
This is all well and good, but it misses what I regard as the critical architectural point - the relationships between capabilities. Business analysts may be happy with capability decomposition, but I think business architects also need a capability dependency diagram, which shows, among other things, how one capability creates or modifies, coordinates or governs other capabilities. Many of the popular capability modelling methods concentrate on modelling the operational capabilities only, but I prefer to produce a model that includes the higher level development and management capabilities.
Fans of Stafford Beer's Viable Systems Model (VSM) will regard the operational capabilities as corresponding to what Beer calls System One, while the higher level capabilities correspond to Systems Two through Five. (For many purposes, I find a simpler three-level schema is enough.)
Another schema for modelling different classes of capability can be found in the draft Systems Engineering Body of Knowledge: Enterprise Systems Engineering Background. This schema is useful in recognizing the distinction between operational capabilities and other classes of capability, but I think it is limited by its strong engineering bias and is probably insufficient for the purposes of business architecture.
Marketing genius Seth Godin once reported a conversation with a publishing executive: "People ask me what the hardest thing is... is it finding authors? I tell them that the two hardest things are hiring great people and watching the cash flow." [The Hardest Thing, April 2006] Things like these are not just hard but critically important to the success of an enterprise - because so many other things are dependent upon them.
It is these dependencies that the business architect must understand - in order to see how improvements in one area may or may not ripple through the rest of the organization, sociotechnically as well as technically. That's why I think capability mapping is more than just engineering.
Obviously these are all clever guys, but does that mean they have all the answers? Someone claimed that IBM's model was based on something called "natural clustering", but I don't know what he thinks that means. The only clustering I've ever seen used in architectural contexts has been artificial, meaning that what you get from clustering depends a lot on what algorithm or mechanism you use, as well as when (at what stage in the process, the level of granularity) you choose to carry it out.
In any case, I am sceptical of generic architectures. If I want a house that is exactly the same as everyone else's house, I don't really need an architect at all - I just need a structural engineer to calculate the strength of the beams and align the plumbing. I don't expect an architect to spend months just giving me a slightly modified copy of something he found in a textbook.
I think the interesting question is how to derive a capability map from the particular behaviours of an organization and the particular intentions of its leadership, rather than just imposing some off-the-shelf business school or vendor nostrum.
So, what kind of capability map do we need to understand the organization of capabilities? Many people think all we need to do is identification and classification - decomposing the enterprise into a set of independent capabilities. Business analysts can then document each capability separately (I sometimes use a capability canvas that is adapted from Osterwalder's business canvas), decide which capabilities are of greatest strategic importance, and produce a plan for business improvement. (The UK MOD practises a methodology called Through-Life Capability Management, and a casual Internet search will identify several large consultancies and systems houses that claim expertise in this area.)
This is all well and good, but it misses what I regard as the critical architectural point - the relationships between capabilities. Business analysts may be happy with capability decomposition, but I think business architects also need a capability dependency diagram, which shows, among other things, how one capability creates or modifies, coordinates or governs other capabilities. Many of the popular capability modelling methods concentrate on modelling the operational capabilities only, but I prefer to produce a model that includes the higher level development and management capabilities.
Fans of Stafford Beer's Viable Systems Model (VSM) will regard the operational capabilities as corresponding to what Beer calls System One, while the higher level capabilities correspond to Systems Two through Five. (For many purposes, I find a simpler three-level schema is enough.)
Another schema for modelling different classes of capability can be found in the draft Systems Engineering Body of Knowledge: Enterprise Systems Engineering Background. This schema is useful in recognizing the distinction between operational capabilities and other classes of capability, but I think it is limited by its strong engineering bias and is probably insufficient for the purposes of business architecture.
Marketing genius Seth Godin once reported a conversation with a publishing executive: "People ask me what the hardest thing is... is it finding authors? I tell them that the two hardest things are hiring great people and watching the cash flow." [The Hardest Thing, April 2006] Things like these are not just hard but critically important to the success of an enterprise - because so many other things are dependent upon them.
It is these dependencies that the business architect must understand - in order to see how improvements in one area may or may not ripple through the rest of the organization, sociotechnically as well as technically. That's why I think capability mapping is more than just engineering.
Monday, November 29, 2010
Enterprise Architecture as Viable System
#entarch #ea2010 @uoaeao tweeted
In response to this, @uoaeao explained that
The dilemma for EA in this kind of situation is clear - how to appear useful in a crisis without (a) throwing all the EA professional discipline out of the window or (b) demanding at least four months to carry out a proper study.
Meanwhile, I wonder what makes this an enterprise architecture task rather than a programme management or risk management task. What is specifically architectural about checking alternative plans for "intolerable business impact"? If we were to observe the EA team responding to this kind of demand, how much of the activity and expertise could be described as "architectural"?
Discussions about the contribution of enterprise architecture to the enterprise often highlight one or more of the following four elements
As followers of Stafford Beer may recognize, these elements roughly correspond to Systems 2-5 of the Viable Systems Model. Applying VSM to EA produces the following demands and challenges.
A number of my friends have one foot in the systems thinking world (including VSM) and one foot in the enterprise architecture world. We are looking to organize something early in 2011, probably in London. Please contact me (e.g. via Linked-In) if you're interested.
"The most immediate and effective way to reduce costs is to use #entarch to stop or delay projects that are spending money."My first thought was that using enterprise architecture for this purpose wasn't likely to be the fastest way to stop projects. Surely the most immediate and effective way to reduce costs is to stop projects, period.
In response to this, @uoaeao explained that
"#entarch adds value here identifying *which* projects should/can be stopped or delayed without intolerable business impact".I wonder what EA process is required to provide a professional answer to this question, and how long it is likely to take. There are at least three possibilities.
- The EA team has already done this analysis, possesses all the necessary models and information, and is just waiting for someone to ask the right question.
- The EA team comprehensively analyses the new situation, runs strategy planning workshops with senior management, produces a revised set of architectures and strategic project plans.
- The EA team does a quick and dirty exercise to protect its favourite projects.
The dilemma for EA in this kind of situation is clear - how to appear useful in a crisis without (a) throwing all the EA professional discipline out of the window or (b) demanding at least four months to carry out a proper study.
Meanwhile, I wonder what makes this an enterprise architecture task rather than a programme management or risk management task. What is specifically architectural about checking alternative plans for "intolerable business impact"? If we were to observe the EA team responding to this kind of demand, how much of the activity and expertise could be described as "architectural"?
Discussions about the contribution of enterprise architecture to the enterprise often highlight one or more of the following four elements
- Vision and forward planning
- Intelligence and optimization (e.g. just enough complexity)
- Resource allocation
- Coordination (interoperability, standards)
As followers of Stafford Beer may recognize, these elements roughly correspond to Systems 2-5 of the Viable Systems Model. Applying VSM to EA produces the following demands and challenges.
- A complete account of enterprise architecture needs to cover all four elements identified above (Systems 2-5), and also explain how they are connected.
- Given that various other disciplines (including design thinking, organizational intelligence, programme management, risk management and scenario planning) also claim to address some or all of these elements, explain how enterprise architecture collaborates with (or incorporates) these other disciplines.
A number of my friends have one foot in the systems thinking world (including VSM) and one foot in the enterprise architecture world. We are looking to organize something early in 2011, probably in London. Please contact me (e.g. via Linked-In) if you're interested.
Sunday, February 24, 2008
Complex Event Processing
Lots of people are talking about Complex Event Processing (CEP). As Opher Etzion points out, it's not always clear whether this means "Processing of Complex Events", or "Complex Processing of Events", or both.
If you just read the Wikipedia articles on CEP and VSM, you may not see much connection between them, so let me try and explain. In my view, the most useful contribution from VSM to CEP is the notion of a transducer. VSM describes a system of systems, with messages or signals passed between the systems. Some of the systems are relatively simple, while others are more complex, handling higher levels of variety. So you need some way of producing a high-variety stream of events from a low-variety stream of events - this is known as an amplifier. And you need some way of converting a high-variety stream of events to a low-variety stream of events - this is known as an attenuator. Both the amplifier and the attenuator convert a stream of events from one form to another - the general word for such a mechanism is transducer.
(In event-driven SOA, events are transmitted through message-oriented middleware or ESB. Some transduction can usually be performed directly by this platform; more complex transduction can be implemented by utility services sitting on the platform.)
Stafford Beer then proposes an elaborate architecture for distributing management functions (such as coordination and planning) between the systems. I don't think we necessarily have to adopt this architecture exactly as Beer lays it out, but we should certainly adopt some of Beer's architectural principles.
Processing of Complex Events:
According to Wikipedia, the goal of CEP is to identify meaningful events from an event cloud. I interpret this as detecting complex events from a mass of atomic events.Complex Processing of Events:
But in some of the examples cited by CEP experts, the events themselves don't seem to be particularly complex. The complexity comes from the need to mobilize an efficient and effective response to a large number of relatively simple events.- Tiffin Box Delivery (Paul Vincent)
Complex Systems:
A complex system is buffeted by events from the environment, and must respond in efficient, effective and flexible ways to these events. This requirement is addressed by a considerable body of work on complex systems and cybernetics - including Stafford Beer's Viable Systems Model (VSM), which I believe to be of particular relevance to CEP - but there is surprisingly little reference to this work in the CEP field. (Searching the Internet for links between CEP and VSM, I only find one person aside from myself who has made this connection - one David HC Soul, who has posted a number of cybernetics reading lists and other material to Squidoo and elsewhere.)If you just read the Wikipedia articles on CEP and VSM, you may not see much connection between them, so let me try and explain. In my view, the most useful contribution from VSM to CEP is the notion of a transducer. VSM describes a system of systems, with messages or signals passed between the systems. Some of the systems are relatively simple, while others are more complex, handling higher levels of variety. So you need some way of producing a high-variety stream of events from a low-variety stream of events - this is known as an amplifier. And you need some way of converting a high-variety stream of events to a low-variety stream of events - this is known as an attenuator. Both the amplifier and the attenuator convert a stream of events from one form to another - the general word for such a mechanism is transducer.
(In event-driven SOA, events are transmitted through message-oriented middleware or ESB. Some transduction can usually be performed directly by this platform; more complex transduction can be implemented by utility services sitting on the platform.)
Stafford Beer then proposes an elaborate architecture for distributing management functions (such as coordination and planning) between the systems. I don't think we necessarily have to adopt this architecture exactly as Beer lays it out, but we should certainly adopt some of Beer's architectural principles.
Notes:
Wikipedia: Complex Event Processing, Event Stream Processing, Event-Driven Architecture, Viable System ModelThursday, August 30, 2007
Events 2
Reposting and extending my comments to Tim Bass's posts on Event Sources and Event Transformation Services, and following my previous post on Event Processing.
Under Tim's classification scheme, a lot of the real-world business events I'm interested in are regarded as coming from "The Application". That's good enough for some purposes, but I'd like to be able to apply event-driven architecture to the application level as well, rather than having events emerge from a black hole called "applications". It would be useful to have a classification scheme that will permit us (but not force us) to deconstruct the applications as appropriate.
If we are thinking about real-world events, then we need to think about the capture and representation of these events in an event-driven system - including analog-to-digital conversion. I offered the example of automatic extraction of events from video (CCTV in an airport). Tim pointed out some of the practical limitations of current technologies, including image recognition, and suggested passport scanning and human data entry as alternative mechanisms.
It is certainly important for the system designer to understand the accuracy with which an event can be (a) captured and (b) transformed within a given system/environment. Video might be used to track a particular passenger, or merely to provide a warning that the number of passengers waiting for passport control has exceeded some safety level. There may be a trade-off between what is easier/cheaper for the system designer and what is easier/quicker for the human actors within the system. Scanning and data entry may slow down the system and cause longer queues for passport control.
I believe it is important to characterize the event separately from the event-capture, and then give the system designer a choice between alternative event-capture mechanisms (based on such factors as accuracy, cost and system performance). The state-of-the-art in event-capture may improve over time, and we may wish to adopt new mechanisms as they become available, without this forcing us to alter the overall architecture of the system.
There are some useful concepts of event processing that can be derived from VSM (Stafford Beer's Viable Systems Model).
Under Tim's classification scheme, a lot of the real-world business events I'm interested in are regarded as coming from "The Application". That's good enough for some purposes, but I'd like to be able to apply event-driven architecture to the application level as well, rather than having events emerge from a black hole called "applications". It would be useful to have a classification scheme that will permit us (but not force us) to deconstruct the applications as appropriate.
If we are thinking about real-world events, then we need to think about the capture and representation of these events in an event-driven system - including analog-to-digital conversion. I offered the example of automatic extraction of events from video (CCTV in an airport). Tim pointed out some of the practical limitations of current technologies, including image recognition, and suggested passport scanning and human data entry as alternative mechanisms.
It is certainly important for the system designer to understand the accuracy with which an event can be (a) captured and (b) transformed within a given system/environment. Video might be used to track a particular passenger, or merely to provide a warning that the number of passengers waiting for passport control has exceeded some safety level. There may be a trade-off between what is easier/cheaper for the system designer and what is easier/quicker for the human actors within the system. Scanning and data entry may slow down the system and cause longer queues for passport control.
I believe it is important to characterize the event separately from the event-capture, and then give the system designer a choice between alternative event-capture mechanisms (based on such factors as accuracy, cost and system performance). The state-of-the-art in event-capture may improve over time, and we may wish to adopt new mechanisms as they become available, without this forcing us to alter the overall architecture of the system.
There are some useful concepts of event processing that can be derived from VSM (Stafford Beer's Viable Systems Model).
- Variety - range of events to which a given system can respond
- Attenuation - reducing variety (e.g. lumping similar events together)
- Amplification - increasing variety (e.g. detecting small differences between similar events)
- Transducer - a device that converts a stream of events from one form to another (which typically results in some attenuation or amplification).
Subscribe to:
Posts (Atom)