deltalounge

First a short note on both BPMN and BPEL. BPMN is a modeling notation for business processes. OMG on it’s BPMN pages puts it:

The primary goal of BPMN is to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes.

BPEL is an execution language. There is for example no standard graphical notation in the BPEL standard. The main focus is not on readability, it is on execution.
So BPMN and BPEL aim for different goals. It should come as no surprise that there is gap. There are several resources that describe the mapping, provide translation, or transforming BPMN to BPEL.

Guidelines

Here are some guidelines that help you bridge the BPMN to BPEL gap:

• Be as specific as possible in BPMN diagrams (In Oracle Business Process Analysis Suite you can use e.g. automated activity, notification , and human tasks.).
• Add additional information in BPMN activities. Sure this doesn’t enable automatic transformation, but it does reduce the need for additional design documentation. This will improve documentation consistency, and reduce the required governance.
• Use templates in your BPMN activities. Structure and check completeness of your descriptions.
• Use a Service repository. This will enable both designers and developer to communicate about “the same thing”
• Use a GUI components reposity, for the same reasons as you use a Service repository

.

Today I give a presentation at the Oracle NL 25 years event – Celebrating a tradition in innovation. Although there are a lot of pictures the words are in Dutch, as was the language of the audience…
The story is based around practises developed in the last five years working on SOA projects. Despite all the desillusions on SOA projects that get a lot of attention this year, good results are achieved for our customers using these practises and guidelines. I’ll elaborate on them in future blogposts.

Still searching for the correct answer on the question: What skyline is in the picture on slide 12?

In the SOA still dead blogpost based on his impression of the SOA Symposium 2009, Joe McKendrick asks the question:

Is SOA still dead?

My personal opinion is that SOA is still alive or reanimated. The declaration of the SOA Manifesto has contributed to this. The least it has done is start discussion online and offline. These discussions will lead to a better understanding for the participants and those following them. The result will be more mature and successful (in business terms not technology) SOA implementations. This would be quite an achievement if the statistics that Anne Thomas Manes presented are accurate:

fewer than 10% of companies have seen significant business value in their SOA efforts.

Although the quotes on this page seem rather negative, I’m still an optimist on the case for SOA. It brings us solid principles and guidance in developing software of better quality.

Views on the SOA Symposium

The proclamation of the SOA Manifesto has resulted in most of the blogpost on the SOA Symposium. However there are post dedicated to a broader spectrum of the SOA Symposium. These give an impression or reflect back on things.

Reading the blog of Linda Terlouw, I remembered having the same expectations on the “Service-Oriented Solution Evaluation Criteria” session: some info on how you can measure whether or not (or to which extent) a service conforms to certain principles. Instead it was a summary of the principles as they are defined by Thomas Erl.

Comments, like this one, are appreciated.

At the end of the SOA Symposium 2009 the SOA Manifesto was ready and declared. It is based on these principles.

SOA Manifesto

Service orientation is a paradigm that frames what you do. Service-oriented
architecture (SOA) is a type of architecture that results from applying service
orientation. We have been applying service orientation to help organizations
consistently deliver sustainable business value, with increased agility and
cost effectiveness, in line with changing business needs.
Through our work we have come to prioritize:

Business value over technical strategy
Strategic goals over project-specific benefits
Intrinsic interoperability over custom integration
Shared services over specific-purpose implementations
Flexibility over optimization
Evolutionary refinement over pursuit of initial perfection

That is, while we value the items on the right, we value the items on the left more.

source
You can watch the Announcement of the SOA Manifesto on Youtube.

The manifesto was signed and declared by: Ali Arsanjani, Grady Booch, Toufic Boubez, Paul C. Brown, David Chappell, John deVadoss, Thomas Erl, Nicolai Josuttis, Dirk Krafzig, Mark Little, Brian Loesgen, Anne Thomas Manes, Joe McKendrick, Steve Ross-Talbot, Stefan Tilkov, Clemens Utschig-Utschig, Herbjörn Wilhelmsen. Soon you can join them in signing the manifesto on soa-manifesto.org.

Update Oct. 26th
I found some blogposts of people participating in the creation of the SOA Manifesto: Clemens Utschig and Stefan Tilkov

October 22th

• arrived at the #soasym09
• there will be a reincarnation of SOA #soasym09 – @atmanes – focus on the hard work of architecture
• replaying The Exorcist at the EVIL SOA including the chanting: I cast thy out!!
• the exorcism of the Evil SOA wasn’t a pretty sight #soasym09
• Oh, and there is Good SOA Up – in an angeliclike shape and character – pure goodness #soasym09
• RT while others state cloud requires SOA… @bvanzomeren: “joe mckendrick: cloud is soa done right #soasym09″
• First blogpost from the #soasym09 http://bit.ly/2Tud0V
• Services are enterprise assets and have to be managed like these #soasym09
• is the gap between IT and Business just a reflection of the left – right brain difference? as discussed at #soasym09 . lets explore this
• Achieving process excellence “co-hosted” by IDS Scheer and Software AG #soasym09
• there hasn’t been a session #soasym09 that mentioned chaos in some shape or form #entropy !?
• feeling Appleless tweeting n blogging from #soasym09 – have to find a sponsor or budget
• Grady Booch joins us at #soasym09 via Second Life

October 22th

• another virtual keynote at #soasym09 – Dennis Wisnosky of the DoD
• Interesting session on SOA Governance by Steve Pope (AmberPoint) will check the demo at their booth #soasym09
• very lively, enthousiast session on Smart Use Cases by @aahoogendoorn #soasym09
• received a draft manuscript of the SOA with REST book by Thomas Erl ea #soasym09
• has the ESB become a commodity? #soasym09
• RT agree @bvanzomeren: interesting talk of @lindaterlouw and A d hertog about the road enterprise architecture to portal and esb #soasym09″
• The SOA Manifesto is presented at #soasym09
• RT @soasym: “Wordle of #soasym09 http://ow.ly/waEv”
• RT @atmanes: “The SOA Manifesto is complete. It will be published shortly on http://soa-manifesto.org” #soasym09

All tweets on SOA Symposium

All tweets on th SOA Symposium can be found here. As they used the #soasym09 that is…. The Wordle is available here.

In this blogspost I’ll share a few thoughts I took from the afternoons sessions at the first day of SOA Symposium 2009.

The Techie Gap

Since architects, software engineers, and the like, are seen as techies (at least from a business perspective) Jaap Schekkerman argues that there is a gap between how these two populations actually use there brain. This is considered at least one of the reasons why IT projects fail.

But first let’s take a step back. Architecture is about:

• Style
• Functions – including aspects like adaptabillity and usefulness
• Construction – including aspects like durability and maintenance

Business people having a dominant right brain style are mostly interested in Style, and sometimes in Functions. On the other hand, architects – being mostly on the left brain dominant side of the scale – seem to have a sweet spot for Construction. This sometimes expands to Functions.
Where right brainers favor “the broad picture”, and left brainers have an analytical “brain for details” (would have used heart, but feeling don’t seem to be their thing). There comes a gap because of different interests in their communication.

A solution for smaller projects to bridge the gap is limit both scope and depth in meetings, and other interactions between these groups.

A more profound solution that is given by Jaap Schekkerman is to use a “Real Enterprise Architect”. Where he defines the role of an Enterprise Architect as:

To be a business and IT communicator.

A person in this role as he sees it has a very broad set of skills and capabilities.

Fundamentals never go out of style – Grady Booch

Grady Booch was very kind to join us via Second Life at a time that he would normally be sleeping (OK; it is an assumption from my side that he would love to sleep at 04:00 in the morning). Fortunately he still managed to give a interesting keynote.

Here are some quotes that I recognised from my own experience:

All architecture is design; not all design is architecture.

Architecture is about all the decisions that are made during a creation process. In this process thousands of small and larger choices are made. It is easy to see, how this can lead to the following:

Most architectures are accidently; Some architectures are intentionally.

With these statements in the back of our head it is good to see that fundamentals keep offering solutions. Here are some classics that can give you guidance:

• Use crisp abstractions
• Aim at a clear separation of concerns
• Distribute responsabilities
• Simplicity is the key

There were some great sessions on the first morning of the 2009 edition of the SOA Symposium. One that is again dedicated to “substance only”. The keynotes of Thomas Erl and Anne Thomas Manes basically went on where the blogpost ended, and declared “SOA is dead, long live Services”. Most people forgot to read the last part of that statement. At the same time we’ll see that Architecture will play a main role in Next Generation SOA.

The New SOA is all about Architecture.

If we are not going to use the architectural principals and patterns, we won’t be able to “clean the house”. This will leave us with the same problems as we had before… only now they have a SOA sauce on top of them. Business is not interested in this somewhat technology flavored sauce. And that is what makes it hard to sell SOA to the business!

Exorcism of the bad SOA

Before we can go to the new and improved SOA, we have to lose the old one. So a real “exorcism” based on the movie was held, as a ritual to leave the past behind. This left us with the question what the New Good SOA will look like. Here are some clues:

• SOA is something you DO, not something you buy – which is not the easiest statement with al these vendors around
• SOA doesn’t have to be large scale – This will take away some of the burdens of the enterprise wide scope, that has difficulty with timely delivery and showing business value within a reasonable time.
• It is about business value – Leaving us with the question how to measure the value of a paradigm? One of the answers lies in the search for metrics for the values of (business) Services.

A lot of other possible buzz words – Cloud, BPM, SaaS, and Mashup – depend on the success of the Good SOA. This will leave SOA a prerequisite for the future.

With the growing presence and maturity of Service-Oriented Architectures (SOA) in the IT industry, the question how to effectively implement a SOA grows louder. As does the need for good reference implementations. Patterns can fill an important role here. The simplest way to describe a pattern is that it provides a proven solution to a common problem individually documented in a consistent format and usually as part of a larger collection. This article will give you some starting points to jump start into the world of SOA Patterns.

Buy the book

SOA author Thomas Erl has in cooperation with experts and practitioners throughout the SOA community written a 865 page book called SOA Design Patterns .
This book helped me not only to get a better understanding of SOA Patterns, but also of SOA “in general”. Not exactly a cover to cover read, but with some good picks of patterns using the index, this read has enabled me to enhance the quality of my advice to our customers.

Podcasts and Web

Partially due to nostalgic reasons I still love to hold a (large) pile of paper while reading. However, while not as extensive as the book, the community site SOA Patterns that comes with the book offers a great reference. Besides that you can find a series of podcasts based on the book. I increased the knowledge transfer efficiency by listening to these podcasts while commuting.

Both of the starting point will give you a head start working with SOA Patterns. The book offers the most thorough and in-depth information. While the podcast plus web offers a great efficiency of knowledge transfer and a solid reference. This article from SOA World magazine will give you a good introduction.

Update May 28th 2009: As Clemens Utschig points out there is a series of podcasts in the OTN Arch2Arch community on the involvement of Oracle (employees) in Thomas Erl’s book. Part 1 Part 2 Part 3