The State-Machine in the Sky

The jokes about solving all information problems with the utopian concept of a single 'database in the sky' that knows everything are well known. But is the new utopia that some describe of centralised top-down process management just as bad, just as impractical? Service-Oriented Architecture (SOA) is often presented as wedded to this concept of centralised top-down process management, but it is not. SOA may require composition (creating services composed of other services) and choreography (sequenced interaction of service providers and consumers), but it doesn't necessarily 'depend' on centralised state-machine-type orchestration. I sometimes worry that people are chasing another conceptual utopia which is not fit-for-purpose to be applied across-the-board in the way that some seem to suggest it should be, and that's one of the ways that business-cases don't stack, and expectations are missed.

Of course this is not to say that BPM isn’t great, I'm certainly not saying that BPM doesn't have its applications, and Process Management is an important discipline. I just feel more and more that it shouldn't be touted across-the-board utopian end-state as it sometimes is. I have a strong gut-feeling that people's desire for visibility and coordination across businesses can often be served through ways other than enforcing top-down control (and by association, top-down constraints).

I had a conversation around a similar topic with Alec Sharp at a data management conference a few years ago and even though of course he used different classes of process to explain his framework, I've always found it very interesting. He described three classes of 'processes' (and I'm using my words here because I can't remember his exactly):-

1.Formalisable processes like certain well-known back-office processes (e.g. Purchase-to-Pay) or certain supply-chain processes.

2.Dynamic sub-processes like customer-interaction where actually you really needed to focus on how to respond in certain scenarios, because you either couldn't predict or formalise the end2end process, or it's not useful to do so.

3.Totally unpredictable processes where actually you just needed to focus on getting information together in front of a sufficiently skilled person who would decide what to do from it.

If I use Alec's categories I might speculate that the first class is most suitable for top-down process management (although in many industries, off-the-shelf application-centric flavours of process management may be more practical than pure BPM).

I might speculate that for the second class you really need to focus more on Event Management, and semi-formalised responses to business scenarios underpinned by information availability, rather than Process management, but there are some obvious similarities.

I might speculate that for the third class you need to focus on information management rather than anything else. And that doesn't mean data aggregation and databases. It's far more likely to mean providing means for federated groups to share their own information repositories, be able to search for it and find it in ways they can understand and aggregate. There is of course a lot of Web 2.0 implications in here, as this is more like searching, linking, tagging and subscribing, than it is like old data management solutions of consolidating databases, creating static interfaces etc.

One last kicker to this point is that conventional wisdom might split the three categories into different types of 'role', maybe something like 'procedural', 'management' and 'strategy'. But this runs the risk of underplaying the pervasiveness of the second and third classes of requirement. If you position them as just for a top few top-management, you miss the point that actually most Enterprise roles these days involve all three types and architectures for these can be just as important as, sometimes more than the one's focused on centralised process-management.

Technorati Tags: BPM Process Management SOA Service-Oriented EA Enterprise Architecture

CEP

Posit: bringing the event and services views together is at the heart a "Services Fabric" - links to event processing here:

Complex event processing (CEP) is a new technology. It can be applied to extracting and analyzing information from any kind of distributed message-based system. It is developed from the Rapide concepts of (1) causal event modeling, (2) event patterns and pattern matching, and (3) event pattern maps and constraints. Complex event processing can be applied to a wide variety of Enterprise monitoring and management problems, from low level network management to high level enterprise intelligence gathering.


Intelligent automation that saves time and improves resource utilization:

Components of business systems typically have different formats for the information they collect about events. Companies cannot visualize all events from disparate components in a cohesive way to manage their environments efficiently. For example, if an IS team needs to figure out what made a business-critical e-business application go down, they may need to understand 40 different event log formats. Root cause analysis of the problem could require input and analysis by numerous system administrators, spanning the network, web and database.

http://www.complexevents.com/

Discussion Topics

Here are some of the topics I hope to get around to discussing here:

• Unified SOA and EDA
• X-internet, agents and services (real-world awareness)
  
• Process versus Service perspectives
• Service granularity
• Simplicity and technology alignment with operational reality
  
• "Semantic Web"-enabled services
• Web 2.0 - business value
• Business strategy and behaviour described as 'Services'
• Database-centric versus Message-centric
  

Other suggestions most welcome.