Wednesday, July 18, 2007
Sunday, July 15, 2007
What the hell is an ESB?
- senior management may soon ask your IT department for a SOA strategy
- it may be the right time to sell shares of SOA vendors
- you'll find all those market analysts attempting like crazy to convince you of the business impact of the aforementioned TLAs
Another fun part is talking to techno nerds about SOA, especially those who believe CORBA and the like will cure all world problems. Did you ever encounter this "I may not know your problem, but I know that CORBA is the right solution" habit? On one hand, these techno nerds will point you to all performance penalties caused by SOA, because they think SOA is all about WS-* standards only. On the other, they will prove that CORBA is SOA, because it already provides the same solution concepts such as separating interface from implementations and leveraging standardized protocols.
Nonetheless, SOA makes a lot of sense from a technology and from a business perspective. When integration of heterogeneous environments is a key issue in your product and solution development, SOA may be the appropriate choice. SOA is neither a ubiquitous solution for all networked systems as business managers often think, nor is it that inefficient as techno nerds believe. The reality lies somehow in the middle between these extremes. In fact, SOA is an architectural paradigm that may even be applicable for CORBA based solutions (but fits much better with message-oriented middleware, to be honest). Of course, SOA in its WS-* instantiation is a perfect alternative to EAI and BPM approaches.
When SOA started to evolve, it was considered a set of architectural concepts that must be implemented using a stack of low-level protocols (such as SOAP, WSDL, UDDI). This resembles how CORBA and DCOM started more than 15 years ago. For instance, the first CORBA products didn't even provide interoperability. They just offered the same standardized, uniform programming interface. To guarantee interoperability, the OMG introduced the IIOP (Internet Inter-ORB Protocol). Shortly after real world projects started integrating CORBA ORBs, they required advanced services to deal with events, security, discovery or transactions. Hence, the OMG initiated efforts to come up with the so-called COSS (Common Object Services Specification). The availability of COSS, however, did not solve all issues either, because engineers had to manually deal with CORBA ORBs as well as with a whole bunch of rather complex COSS services. In addition, not all vendors provided all the required services. Hence, the CCM (CORBA Component Model) was introduced that decouples developers from lifecycle management and service issues.
In the SOA/WS-* universe this storyline re-appears. Think of SOAP and WS-I (IIOP)! And think of WS-Coordination, WS-Attachments, WS-Security (COSS)! Finally, ask yourself which part of SOA is playing the role of advanced technologies such as CCM. This is exactly where ESB enters the stage. ESB is one of the core assets of any SOA strategy. It provides a container that decouples implementation details such as communication protocols from developers. It also adds (or should add) lifecycle management, routing, transformation, security, management and discovery services. Without an ESB, engineers have to face the challenge of dealing with a bunch of different (mostly low-level) technologies they need to integrate. Unfortunately, big players such as SAP or Microsoft do currently not provide integrated (!) ESB products. And those companies selling ESB solutions often provide "heavy-weight" containers with a high degree of vendor lock-in.
What we actually need are light-weight ESB solutions that are based upon standards such as SCA or OSGi and interoperate with other platforms (such as WCF/WF/BizTalk). Such ESB solutions should cover the whole range of application domains and support enterprise applications as well as embedded applications.
We have started our journey but it will take a long time to reach the destination.
Friday, July 13, 2007
Did you ever observe software architects in projects when they are developing new products or solutions? How do they deal with failures? Interestingly, whole organizations and individual architects only seldomly learn from failure. Failures are not really impressive in any performance review or project meeting. That's the reason why they are often ignored or even forgotten. How often in your career de-ja-vouz situations appeared where you couldn't believe that the same errors were made again and again even by smart people?
Now, think about famous inventions such as the light bulb? Inventors and scientists such as Thomas Alva Edison succeed because they continuously reflect about their own activities and leverage failures in a constructive way.
So what conclusions should be drawn? If you like to find the right direction in a labyrinth use an Ariadne thread. Whenever you encounter a dead end reflect and then try a new direction. Or shortly: learn from failure!
Software architecture design is complex as you need to balance multiple and sometimes even interdependent forces. Thus, failure is a fact and not a seldom accident with respect to software development activities. There is a whole range of possible failures. In the small, some design decisions might be wrong. In the large, the whole architecture respectively project might fail. The best way to deal with such situations is analysing when and why wrong decisions were made that lead to the failure and which alternative decisions would have been the right ones. Agile processes explicitly consider the possibility of failure introducing practices such as testing and refactoring.
I made the experience that a post mortem analysis of any project (also known as architecture review) is really helpful to learn and improve my own skills and experiences as a software architect. Of course, this also holds for projects where you were not involved. Unfortunately, western culture does not really motivate writing articles about projects that failed.
The same "learning from failure" pattern does not only apply for software artifacts but also for software development activities. In the ideal case we would reflect over our results and activities daily. Correcting a wrong direction early is rather inexpensive. Correcting it lately will require substantial corrections. Shouldn't a culture of learning from failure be an important part of any (development) process?
Software architecture is the core asset of any software product and determines the quality of the result. Failure in software architecture activities has a significant impact on the implementation. Needless to say that failures must be handled with care, explicitly analysed and addressed by architects.