To ESB or not to ESB

http://blog.mulesource.org/2009/07/to-esb-or-not-to-esb/

Software For Your Head

http://books.google.com.au/books?id=LgHHfzec33UC&pg=RA3-PA4&lpg=RA3-PA4&dq=%22greatness+cycle%22+pattern&source=bl&ots=qBRccvZGLj&sig=hyhc-X11pqdg7w3hZZyG8UIQCEY&hl=en&ei=6J9QSo-CL4H8sQPS-ejkDw&sa=X&oi=book_result&ct=result&resnum=1

Agile is Dead

http://agilesoftwaredevelopment.com/blog/janusz-gorycki/agile-dead

Abstraction is not always a good idea

http://www.infoq.com/articles/tilkov-rest-doubts

abstraction is not always a good idea. Web services take the approach of trying to hide many very different technologies under a single abstraction layer — but abstractions tend to leak. For example, there is a huge difference between sending a message via JMS or as an HTTP request. Trying to dumb widely different options down to their least common denominator serves no-one. An analogy would be to create a common abstraction that hides a relational database and a file system under a common API. Of course this is doable, but as soon as you address aspects such as querying, the abstraction turns into a problem.

Finally, as Mark Baker once coined: “Protocol independence is a bug, not a feature”. While this may seem strange at first, you need to consider that true protocol independence is impossible to achieve — you can only decide to depend on a different protocol that may or may not be on a different level. Depending on a widely accepted, officially standardized protocol such as HTTP is not really a problem. This is especially true if it is much more wide-spread and supported than the abstraction that tries to replace it.