deltalounge

In October 2009 I posted about the announcement of the SOA Manifesto during the SOA Symposium 2009. For those of you interested, InfoQ has interviewed the original author’s and in some cases pulled in their comments on the manifesto from the web to get insight into the motivations and the process behind the initiative. The answers are gathered under the name SOA Manifesto – 4 months after. The article looks into the following subjects:

• The philosophy
• The process
• The goals

Find the complete article here.

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.

October 22-23 the SOA Symposium 2009 will be hosted in the World Trade Center – Rotterdam, The Netherlands. Besides the Second Annual International SOA Symposium, the International Cloud Symposium will be launched at the same time, as a bonus co-located conference. There will be over 80 speakers including recognized thought leaders, such as Thomas Erl, Grady Booch, Anne Thomas Manes, Joe McKendrick, David Chappell, Dirk Krafzig, Jim Webber, Nicolai Josuttis, Paul Brown, Mark Little, Clemens Utschig, and Torsten Winterberg.

The theme of the symposium – Next Generation SOA – is explained by Thomas Erl in SOA Magazine of April 2009 :

Next Generation SOA represents how the evolution of service-oriented computing has reached a point where we have not just mature technology platforms and sophisticated modern service technology innovations at our disposal, but also proven practices, patterns, principles, and a clear vision of the target state represented by service-oriented computing.

During the symposium the latest title – Next Generation SOA: A Real-World Guide to Modern Service-Oriented Computing – in The Prentice Hall Service-Oriented Computing Series will be launched.

SOA Manifesto announcement

This event is chosen by leading SOA experts as the location at which the SOA Manifesto will be finalized and, for the first time, announced. The SOA Manifesto is:

A formal declaration of the principles, intentions and ambitions of service-orientation and the service-oriented architectural model.

This announcement will be video recorded and the video file, along with the first draft of the SOA Manifesto, will be published on this site. The final manifesto may be entitled the “Next Generation SOA Manifesto”. Which perfectly fits the theme of the SOA Symposium.

Will we meet there?

I would like to meet you there. Use this site to register. Note that several partners of 10% discount (Oracle, Via Nova Architectura, and DNV).
If you won’t be able to make it, follow this blog. There will be several posts during the event.

Last years resources

In the meantime you can use last years resources and visit the 2008 presentations on slideshare.

Once again Mike van Alst got me thinking on some aspects of implementing and managing SOA environments. In his blog post Mike states that he is moving away from the idea that SOA is process driven. I recognize the problems with long running process he describes. These have a great effect on maintainability and manageability of the (BPEL) processes and SOA software infrastructure.

At this time I’m still favoring a process driven approach over an event or message driven approach. The process driven approach has an intrinsic value that none of the other come even close to. It is as close to the day to day operation of an organization as you can get. This implicitly closes a potential gap between business and IT. When choosing a message or event driven approach other mechanisms have to be introduced to bridge this.

To get perspective on the matter, it is important to realize that the arguments presented aren’t on the design, but on the management part of the cycle. Besides that they deal with a subset of all business processes: long running business processes, and especially those that have a high volume of instances.

Decomposing the process, and arranging the parts using another approach than a process orchestration tool moves us away from the Process Centralization pattern. In short this reopens the problem that process logic is not stored in a central location. Which also has a negative impact on management and maintenance of the solution to be implemented.
So there’s the challenge to separate the concern for the process logic, and on the other hand have a platform the accomedates upgrading both your (BPEL) processes and the underlying software infrastructure.

First of all, in the title REST and SOAP is explicitly chosen for the word AND. I do not see any reason why there should be an exclusive or. There are already enough ((almost) religious) wars in IT, and in the world in general.

Besides that it can be hard to compare these two. How should one compare a software architecture (REST) with a protocol (SOAP)? Frankly, I don’t know. What I do know is that both are ways to implement a Service. And sometime during the A(architecture) part while implementing a SOA there have to be guidelines when to use SOAP and in what cases to use REST. In the mean time SOA as an architectural model stays neutral to technology platforms.

REST

REST (the origin of REST) is closer to the web’s protocols. Or the other way around, the larger part of the World Wide Web conforms to the REST principles. RESTful services do not require WSDL operation specs. Since standard methods of HTTP (GET, PUT, POST, DELETE) are used, the number of operations is predictable.
The principles underlying REST result in advantages including:

• Less software has to be written on the client side;
• There will be less dependence on software (vendor) specific implementation;
• It is easy to understand, due to hyperlink representation.

SOAP

SOAP is a protocol working in a RPC way for exchanging structured information. SOAP, WSDL and XML based messages, solved a part of the problem of how to (self) describe messages for the exchange of information. That was a great step. And when we started to work with these standards, we noticed that it was not secure. To solve this developers started to add information to the header. And over time a (WS) standard came that solved the security issues.

In the enterprise world, security wasn’t the only lack. There were a lot of other issues that had to be solved. This resulted in the WS-* stack. Which is, at this point in time, quite extensive. And that makes it hard to oversee it all. This has led to the point of view that SOAP and WS-* are complex and hard to implement. And WS-* can be hard to implement. However the complication is not due to the WS-* stack, but due to the fact that we live in a complex world and are trying to solve complex problems! OK, there is one part where it could be due to the WS-* stack: The fact that there is not a single managed set of specifications, that is consistent, will get a lot of people confused. This resulted in specifications that overlap and compete. Which doesn’t benefit it’s cause.

Web services based on SOAP and WS-* enable a lot of companies to exchange information and perform business functions, also meeting the non-functional requirements. Some examples: functional requirements (like the ones resulting in transactions) and implementation and architectural decisions (eg composite services) are better implemented with SOAP than with REST.

Coexist

Both in everyday use where Amazon offers both REST and SOAP web services, as in a more theoretical view, the Dual Protocol Pattern, it can be seen that these two can coexist. Offering the same capability, and offering a capability for which a specific implementation fits best.