I am proud to be part of the team that will strech the edge of how to present and navigate in semantic search result entities.

Stay tuned. 

When you look at the main stream cloud computing stack, you usualy find IaaS,PaaS,Saas.  For me, this looks very much just as the beginning of some far bigger "thing", as some still very (imature) foundational work. Necessary, but not an end point.  

I would like to suggest the next layer: Business as as Service.  

In order to clarify what I mean by this I would like to leave the cloud computing arena and although not too bad in english, I will switch to my native German tongue (and maybe translate to english later on). And as usual, as this is in my free time, I do not have too much time to detail everything out right now. So this will only be the rough idea, critics welcome !

-----------------

BaaS bezeichnet einen weiteren Abstraktionslayer im Rahmen sowohl der Cloud Computing Kategorisierung (IT Sicht), als auch im Bereiche Enterprise/Business Architecture (Business Sicht)

Definition BaaS: Abstraktions Schicht zur Automatisierung von Wirtschaftssystemen. 

Atomare Entität auf diesem Layer ist die Geschäftstransaktionen = Austausch von Waren/Dienstleistung/monetäre Werten in einem für diesen Einzelfall festgelegten Tauschverhältnis
Ware gegen Ware oder Dientleistung gegen Dienstleistung oder monetärer Wert gegen monetärer Wert stellen auch legitime Tauschformen dar.

BaaS Geschäftstransaktion: Geschäftstransaktion, welche durch (teil-)autonome Systeme zwischen Geschäftsentitäten rechtsverbindlich getätigt und abgewickelt wird, wobei alle notwendigen Bedingungen einzelvertraglich gekapselt enthalten sind und keine weitere Kommunikation erfolgt, insbesonderer keine humane Interaktion mit systemen.
Mehrere diese Transaktionen können einen inneren Zusammenhang aufweisen, z.B. in Form einer Wertschöpfungskette, also einer vorher-nacher Relation, oder eine Subtyping/Supertyping Relation. 

Die Definition des Transaktions(tausch)gegenstandes und somit die Möglichkeit diesen Anzubieten und Nachzufragen, erfolgt in einer Geschäftsfeld-einheitlichen Domain Specific Language, welche wiederum auf einer universellen DSL basiert.  Wo Bedarf besteht, können automatisierte Interpretermechanismen DSL Anfragen eines Geschäftfeldes (z.B. einer Branche) in DSL Anfragen eines anderen Geschäftfeldes übersetzen.

Angebot und Nachfrage werden dezentral über universelle Discovery Mechanismen ohne zentrale Platform facilitiert, z.B. durch das Erzeugen und Reagieren auf Events. (Events im Sinne von Event Driven Architecture)  

Ein Verweis auf brancheneinheitliche Standards- und  Rahmenbedingungen ist möglich, sofern diese ein-eindeutig sind. (Beispiel Handel: INCOTERMS) 

Rahmenverträge können als Kontext für andere Geschäftstransaktionen geschlossen werden. Die Abbildung erfolgt ebenfalls als eine Geschäftstransaktion, auf welche ein-eindeutig referenziert werden kann. 

Was ermöglicht diese Sichtweise?

Ich bin der Überzeugung, daß branchenweite DSL Ansätze (welche durch Gremien standartisiert werden), kombiniert mit universellen Discovery Mechanismen,  eine sowohl notwendige als auch hinreichende Voraussetzung dafür sein werden daß:

- grosse Bereiche des Wirtschaftens zu einem signifikant höherern Teil automatisiert werden kann 

Hiermit meine ich insbesondere jene Bereiche, welche derzeit noch durch Sachbearbeiter "bearbeitet" (also letztendlich Einzelfall-ausführend entscheiden) werden. 

Stichworte : KI in Business, Rolle von Branchenverbänden und Standartisierungsgremien, Rolle Politik, Volkwirtschaftliche Ressourcenallokations-optimierung, Beschleunigung Bedarf-Angebot Abdeckung, .. 

------------------------------

So, time is up, far too fast, as usual, I will need to find a job where i can research into this during working hours :-)

My boss.boss.boss.....boss (well, actually i don't know exactly how many hierachy levels up, but he owns the top node) made a very inspiring apearance on an internal video.  He talked about ambitions.  (Ambitions are a big thing in our organisation as we try to help our customers with their ambitions.) At the end of the video he suggested that we write down our personal ambitions, and thats what i did.

It took suprisingly little effort to articulate them, i think that is a good thing on its own.  So world, here they are !  

My personal ambitions are to never stop developing myself further and to be/become: 

- an inspiring Team Leader and Manager, respected for his work results and his proven positive "can do" attitude,  creating value with the team for the customer, for the company, maybe even occacionally for the people, all of mankind and also the marsians.

- a Consultant, able to really listen to every individual in every conversation, finding the right questions for creating that joint "FLOW" state again and again that leads to excellence.

- a well recognised Architect of information-centric solutions that delights customers and users - combining state-of-the-technology with ahead-thinking and outside the box solutions for the really complex cases, at the forefont of what is (un)thinkable in the present; shaping a desireable future state.

- a trustworthy advisor, rightly asked for advice that is based on expirience and knowledge

- a mentor for the talented next generations, humble enough to realize that things are changing and the future is not the past, helping others to grow and to find and realize their own ambitions

- and also in the future:  stay a happy person

 Wow, looks good, looks like me :)

Enterprise achitecture is a facinating, a-full-working-day-filling complex matter. But compared to MEBA it is still quite a well scoped thing. Imagine EA as planning and building skycrapers (... and then start to refurbish while all offices are rented on long term contracts). What is my point here ? You have one border you can rely on, the skyscraper's outer walls. Maybe you need to put bigger, better doors (interfaces) in it or different levels want to rely on a fast elevator (ESB) and so on, I think you get the point.

I asked myself how would MEBA fit into this metaphor ? Well, easy you might say, its about what happens between these skyscrapers. Good thougth !, well at first.

I went down that road a while ago and it lead to a really really interesting idea of looking into and transposing patterns from the field of ...Cityplanning /Citydevelopment, hope that's the correct english term (German: Stadtentwicklung).

These guys are working in the real world, trying to find out how cities will/should evolve, for example they need methods to cope with real car traffic congestion issues and how it will work in the future of let's say NY or Berlin or Mumbai. They have -no suprise - developed their own language to describe specific effects and I tell you, you would be suprised how easy you can understand their concepts having an EA background. Actually I would be more than happy to meet more often with some of them because there are far more waistfull possibilites to spend your training/conference budget than going to at least one of their conferences to dive into their pattern world.... and I woud love to see some of their brighter guys getting a speaker slot at let's say a Cloud Camp Conference which are so much en-vouge these days, seeking for direction/structure/control of the whole 'cloud thing'. 

BUT, (yes there is a but) although I am totally convinced that there are quite some interesting patterns to grab for transposing them to EA, for example to information architecture and/or busines architecture and/or governance realities of Enterprises, ... with respect to MEBA it is just not enough. 

MEBA as a concept, a viewpoint should not be shrinked to a way of - only - describing "what-happens-between-(existing)-enterprises-(today)", there is much more.

Think.

While I tried to get my head around the more obvious implications of MEBA I was able to invent quite some nice new n-letter acronyms. This is normally a good sign for me that I am speeding up... and haven't read all available info sources because normaly somebody else allready sticked it's Flag in that territory (unknown to me still).

Want one acronym ?  MEBVSPA ->   Multiple Enterprise Business Value Stream Participation Architecture 

Quite mentionable:  it really gets interesting if you try to visualise MEBA in an architectural context, showing classicallytop down : BA(capabilities, processes, IA) and below TA (Data, App, Infrastructure Architecture). At first glance it looks like everything is clear and you put MEBA on top.. but wrong.

... maybe i dare to publish some Diagrams on this in an later stage.

One more acronym at the end of this, a short one maybe ?  ICGI -> Industry Comunity Governance Influence 

 The Back of the Napkin: Solving Problems and Selling Ideas with Pictures by Dan Roam
 ISBN-13: 978-1591841999

In 'The Architecual Journal', issue 17, David Chou wrote about 'Using Events in Highly Distributed Architectures', great article !

I would like to add something with regards to the 'Scope of the data' stated in the article.

Quote:

'..., in other words, just an adequate amount of data to help event receiver decide how to react to the event'

End Quote

Furhtermore he suggests that if an downstream systems need more than that, the system could use alternative means such as synchronous Web service communication to get the rest of the data needed for it own unit of information processing.

I do not share this point of view.  Of course, the above is the logical minimum of information that has to be there to make it an event. Also, the suggested (second) comunication is a valid way for getting additional informaton, BUT i don't think this should be the standard behaviour in an Event Driven Architecture.

Most often you will have a 1:n relation between one event sending system and multiple subscribing systems. If strictly following his suggestion, one event will lead to multiple additional requests for more information from the subscribing systems back to the sending system. This takes more time and resources than necessay and you will most probably have some redundancy in theses secondary communication.

I think with a more sophisticated event message modell having for example a clear POX (plain old XML) based, 3-part Event Notification message structure it would be possible to avoid most of the secondary 'chatter' communication.

• Event Part 1: Event ID and other info for Pub/Sub purposes.
  
• Event Part 2: Identifiers : 'meaningful data uniquely identifying the occurance'
  
• Event Part 3: 'Payloads', (multiple) Additional data packed not necessary for Part1 & 2, but avoiding all/many/some secondary communication uitilizing Standard Business Objects for carrying information necessary for subscribing systems. 
  

For Part1 and Part 2 all arguments are valid with regards that a 'enterprise-level view of events have to be defined and maintained'.

Part 3: Most of the participating systems should be able to deal with Standard Business Objects (defined and governed on a Enterprise Level) so there is no Problem in Terms of causing New Logical Dependencies. In case a System cannot deal with them, it still can retrieve the Data in a secondary Communication.