SOA governance, what's in a name?

"...it's architecture that drives agility first, not reuse that drives development. Write that on your hand."

"...focus on architecture, which brings agility, and less on reuse."

On Infoworld Dave Linthicum posted two very short articles on the state of SOA governance tools. He is not very amused...(part I, part II)

Linthicum stresses that SOA governance vendors focus too much on software development support and too little on an architecture that brings agility, too little on the ability to leverage foreign services and too little on standards.

I believe he is right. But I want to add yet another viewpoint: SOA governance should also support organizational aspects of the SOA life-cycle. If your company has a centralized software development department with profound mandate, things may go smooth. But in a federated organization with redundant systems, highly delegated ownerships, multi development/deployment departments and full departemental autonomy, things may not go as smooth as you would like. In order to implement an SOA, all departments have to agree together on functionality of common services, on ownership, on mechanisms for semantic harmonization, on security implementations, on performance, on accountability, on coordination processes, on common infrastructures, on error handling and routing and so on. All of these requirements must be fulfilled, otherwise you will not be able to build enterprise wide SOAs, if that's your ambition at all (well, I think it should be). To organize these aspects in a decentralized organization is a tremendous political effort which goes far beyond the capabilities of many CIOs. In practice it's not so much about bringing order in an environment of high entropy, but it's more about surviving in such an environment.

How can SOA governance tools support the requirements of highly decentralized organizations? So, maintaining local autonomy and at the same time leveraging SOA? I think by delivering methodologies, guidelines, standards, sample processes, best practices and development mechanisms that support federation. What might be a good starting point is the idea of merchandizing business events between the autonomous departments and - at this level - focus on synchronisation rather than on reuse of software components.

What do you think?

Noah takes a photo of himself everyday for 6 years

This posting is completely off-topic. But I'm so fascinated by what this guy produced that I just want to share it. It shows how genius and creativity go together with ultimate simplicity.

Watch the video an listen to the matching music. It's hypnotizing.

Why not start with simple events?

There are SOA evangelists and there are EDA evangelists. Some SOA evangelists are starting to discover EDA and some EDA evangelists are starting to discover SOA. Most EDA evangelists concentrate on complex event processing (CEP: recognizing patterns in events) and event stream processing (ESP: take time related actions on patterns in fast streaming event-flows), with David Luckham as their Godfather. Most SOA evangelists struggle with the idea of decoupled one-way communications; "what the heck is an event?" and "don't I loose control?".

But I don't see a focus on the big advantages of using simple events, yet. Forget for a while about explicit correlations between events and pattern recognitions. After you are familiar with events, you can always add complexity to do more sophisticated and exciting things. You don't always need to recognize patterns in event-flows or to process huge numbers of events in very short time-frames. The contrary is true. In most cases simple events will already give a lot of opportunities and above all: ease.

Let me tell you a story

We implemented an ESB infrastructure as a platform to start building SOAs. We are creating roadmaps to implement SOAs. We are looking for pilot projects. We are evangelizing the concepts. But we don't have an SOA yet.
We are also implementing an employee-portal. And the portal uses an enterprise directory to control access, among other things. We also have an SAP-system in which we maintain employee data. And it seemed to us that it would be a good idea to feed the enterprise directory with employee data from SAP when a new employee is employed or when an employee gets retired. What we do now - using our common sense - is publishing the new employee data as a one-way SOAP-message in our ESB. And we also publish a one-way SOAP-message in the ESB when an employee retires. Not a big deal, is it? But guess what... Other departments in our company are starting to ask: "Wow, can we use these published employee data as well? It would save us a lot of work if we didn't need to handle and check all those FTP-files every week. And our database would always be up-to-date." Another department (maintaining work-schedules) asked us if it could be possible to publish the employees that are sick and to publish when they recover. Well, of course, at your service.

You see what happens? We don't have an SOA, but we see arise an EDA without even mentioning the acronym. Isn't that wonderful?

And I have another interesting story

We would like to know the occupation of our trains. These figures are interesting for several reasons. For instance to optimize material planning, but also to recognize trends which may trigger new business opportunities. We designed sensors in the trains to count the number of passengers boarding and leaving the train. These data are parameters to a piece of software that calculates the occupation of the train. The data is planned to be stored in a data warehouse.
But... in stead of collecting records to a file to be loaded into the data warehouse, we designed to publish the calculated occupations directly in real-time as one-way SOAP-messages in an ESB. The data warehouse will be wrapped to collect and store the published data. (You must know that we are working on a mobile infrastructure which gets ESB-components onto the train, which makes it possible to have the software on the trains participating in our global application-infrastructure.)
What is the big deal now? Well, of course I explained that the transport of data using this generic application-infrastructure in place would be much cheaper than any other form of transport. But when I explained that the messages floating in the ESB can be captured by any other application wherever in the organization, for instance by an easy to program little tool to display the occupation of every train in real-time, it became quiet. "So, when there is an obstruction on the railroad, we can see how many passengers will strand at the station... in advance?" Yes sir, you can! It's a free spin off.
"Wow..."

This is all about EDA with simple events. It just happens and it will continue...