Geexoo

Geexoo is a new site that aggregates latest feeds from top blogs for over 30 tech topics at one place. They update feeds from the top blogs 2-3 times a day.

I appreciate they included my blog on the SOA entry.

Why I Believe in the Unbelievable

At this moment in time we are the witnesses of the most overwhelming cultural shift in the world ever. Watch how our world has started an incredible change...

For more see http://shifthappens.wikispaces.com/

SaaS explained

Are you not yet familiar with the idea of SaaS? Then watch this clip...

Invisible IT

According to York Earwaker's Weblog we are entering the era of invisible IT. He published a picture which tells us so. Unfortunately he didn't mention the source of the picture (might be his own) and he doesn't go into depth on the aspect of invisible IT. But it makes me think of my expected SaaS evolvement and cloud computing.

This is the picture...

A little explanation on events

One of the readers of my blog has sent me an e-mail with some questions on EDA. This event triggered me to publish this (hopefully) elucidative posting.

He started with the statement that many of the events seem to be based on the state of documents. Wrong! Events are not based on the state of documents, but it is the way around; the state of documents is based on events. An event occurs; the state of a document is not an event, but represents an event that happened (and is therefore often denoted as the event itself).

A business event is a specific occurrence that your business planned to react on. The process step where the event occurs will publish a document with the respective state. The next step in the flow will have a subscription on documents with this state.

As the state of a document represents (the occurrence of) a business event it is technically appropriate to use the publishing of the document as the trigger to activate the next process step (which is implemented as a software component). The publishing of the document is a detectable event that may (and will) creatively be used to represent the business event itself. But in fact it is a different kind of event.

This mechanism can be implemented by JMS-topics (if you use middleware). Or it may be implemented by instantiating objects (OO) of a class that represents a specific document state (if you build the mechanism in your applicationcode).

Example

The trigger of an order handling process is probably a customer placing an order. That is a business event, something your business planned to react on.

At that point you may start the flow. You could control the process flow based on the different states of the order. The order may have states like OrderAccepted, OrderRejected, OrderShipped, OrderInvoiced, OrderPayed etc.

A step in the process may be interested in orders with the state OrderAccepted. This step is interested because it probably is responsible for shipping the orders. The fact that the order is shipped is a business event that changes the state of the order to OrderShipped. Another process step is interested in orders with the state OrderShipped. This step will possibly create invoices.

The fact that an invoice is created for an order is a business event that results in the state OrderInvoiced and will trigger the invoice process flow. You may - by design - want to control a flow based on the states of the invoice, like InvoiceCancelled and InvoicePaymentReceived. So here starts the invoice as a document to control and track the state of the invoice handling flow that is branched of from the order handling flow.

About a Loser's Model

Today I read a posting on Joe McKendrick's blog called Is Cloud computing too good to be true for enterprises. His blog entry was inspired by postings of some of his colleague bloggers on ZDNet. It is a nice article discussing the pros and (a bit more) cons of cloud computing for the enterprise from the perspective of SaaS, PaaS, Google and Amazon. So be it.

Reading the article two things came to my mind.

Firstly

The following quote attracted my attention:

In many cases, even 20-year-old mainframe programs contain custom processes and logic that provide market advantages.

I wouldn't put my cards on a company that relies for its market advantage on 20 years old IT-systems... It is a loser's model nowadays! Modern IT evolvements are currently inclining the world explosively. Not the least reason because of the introduction of ultimate connectivity; every home nowadays has multiple IP-addresses (I even carry one with me every day in my pocket), to mention just one of todays IT-characteristics that didn't exist 10 years ago. Knowledge of the occurrence of even the smallest event spreads around the world within a few seconds (by everyone, from every home, at no cost, and with audio and moving pictures!) to mention just another of today's characteristics. Relying on software (and supported processes), build in an age when these characteristics were laughed away as irrational fantasies, needs not be a big issue. But if your business depends on it for its current market advantage... o boy!

Secondly

Of course cloud computing is the way to go!

I do cloud computing myself every day by handling my financials via a web browser connected over the Internet to an external service provider - my bank - whose systems (and data centers) I don't know, whose personnel I've never met, whose office I've never visited, and whom I yet allow to safeguard my money. This is an extreme example of outsourcing sensitive processes to an external service provider. This external service provider deals with my most risk sensitive assets like my salary - and pays my bills from my own money partly even without any of my interference. And I control the process via the cloud. What the heck security issues and no future for cloud computing... It is just going to happen and you'd better be prepared if you want to stay in business.

Levels in IT-architecture - nice picture

I love simplicity. But I also love completeness. I love correctness and consistency. I love elegance and art. That is why I am an architect.

I came across the picture below (click to enlarge). It is complete, it is correct, it is consistent, it is elegant, and above all, it is simple.

(Picture taken from Wikipedia)

BPM and DFD, and the art of designing systems

Never heard of DFD? And in charge of designing processes in BPM? Then read this blog posting.

Living in the era of SOA and BPM, I come across a lot of books, articles and blogs that try to tell me how wonderful the world can be. When using a BPM-tool you are able to model and manage the business processes of your company. Flexibility is the keyword. Not only cutting and pasting on a canvas, but also copying to fulfill the popular "reuse" paradigm.

Of course these tools are nothing more than pencil and paper. The art of designing systems is quite another matter. The books, articles and blogs of these days don't tell you very much about the art of designing. We are suffering some amnesia...

Back in the 70s everybody knew that programming was not about writing code, but about the art of designing algoritms. Edsger (Edgar) Dijkstra used the term "elegance" for correctly designed algoritms and everybody knew exactly what he meant. Every programmer and designer knew about Structured Analysis, Structured Design and Structured Programming as rationally described (so not intuitive) approaches to develop systems. Part of these approaches is the Data Flow Diagram technique (DFD). And exactly this technique is extremely useful in the context of todays BPM.

Watch these slides the get a notion:

[click the right-bottom icon to be able to switch to full screen mode]

If you are interested in a more extensive slide presentation then browse through this one:

For you who are the hard cores there is this educational documentation of Ed Yourdon (famous in the 70s and nowadays still actively promoting his timeless methods).

One remark I should make is that you may replace the term "function" by "service" only if applying an additional constraint: the function must be autonomous; the function must be insensitive for its context. That means that the function must be able to execute getting its input from different contexts and delivering its output to different contexts. That makes the function much like a "service" (...don't shoot me!). Mind that Yourdon uses the terms function and process as synonyms (nobody is perfect...).

BPM already offered as SaaS

A few days ago I posted about the Marriage of BPM and SaaS. A fellow-blogger - Roeland Loggen, whom I happened to meet last Friday in Amsterdam and who happened to be a BPM expert - commented on my posting telling me that BPM is already offered as SaaS.

The links Roeland added are very interesting. See how e.g. Lombardi offers a process design tool as SaaS:

• Features

• Flash demo (with sound)

The resulting process models can be exported to be run by leading BPM execution suites.

I don't intend to push forward Lombardi. I just use this company as an easy showcase of my previous posting. I hope they don't care (...)

The marriage of BPM and SaaS

From a very basic point of view you might say that with BPM-tools you are programming the application landscape. The current standard programming language for application landscape programming is BPEL.

Of course you want to use BPM to flexibly and rapidly model business processes. So it is a good idea to reshape the application landscape by service enabling or break down the applications in a smart way. The services should map to elementary business functions to be used as sharable building blocks in business process models, SOA...

On the other hand SaaS (Software as a Service) is evolving. Providers offer functionality to be consumed by their clients. Different providers deliver different services. This is a growing market, because it relieves companies from maintaining and supporting their own software solutions. But current SaaS products have a monolithic nature and are commonly delivered by ordinary web-interfaces.

Companies currently have to maintain a complex and cumbersome IT-stack to keep the application landscape - or SOA - running. Many companies try sourcing strategies to get rid of the burden of the lower layers of the stack. But the complexity of expensive service level agreements and procedures creates new burdens and limitations. The world would be a lot easier if companies could support their business processes with functionality fetched and glued from and within "the cloud".

If SaaS providers would offer service interfaces at the business logic tier of their products, the functionality could be addressed by the BPM-tools of consuming organizations. After all, well designed services are stateless, autonomous and sharable; just the perfect characteristics to be delivered as SaaS. Companies could build business processes from services delivered by different SaaS providers. The underlaying process server that executes the BPEL could be a SaaS product as well. And what if the user interface (UI) of the SaaS products would be delivered by UI-services based on WSRP. These UI-services could be consumed by the company's portal - which also could be a SaaS product. Organizations could run their business processes in their own house-style and completely based on SaaS, yet being able to compose their own processes with BPM. Programming the application landscape without any worries about software and the supporting stack underneath it! Wouldn't that be a wonderful world?

Today I attended a seminar about BPM and ESB. The seminar was organized by BEA, the middleware company that is planned to reincarnate into the body of Oracle this afternoon. BEA was talking about ESB, BPM and SOA. But they were also talking - as a middleware company - about getting started with SaaS (Genesis). Very interesting!

CEP simply explained

It is April 1st
Picture stolen from here...