Strategies and Tactics

Software architecture is about the components of a system and their relationships. It also comprises the guiding principles that lead to these components and relationships. Finally, a software architecture deals with multiple viewpoints on the same system, for instance structural and behavioral viewpoints. Hence, every software system reveals a software architecture. However, if you just enter the implementation phase skipping analysis and design you will follow an unsystematic approach which inevitably leads to an ad-hoc software architecture. For all but trivial systems a systematic approach is important to achieve software architecture quality. Quality in this context means to meet all requirements, the implicit and the explicit ones - of course, considering the viewpoints of all stakeholders. One of the most important disciplines in a project is mapping requirements to the software architecture using a systematic approach. This does not only imply drawing bubbles in graphical tools. At the end, software architecture is only a means for implementation, not less and not more. Reminds me of the famous Bertrand Meyer, who once said things like "Bubbles don't crash" and "All you need is code". All these considerations lead directly to what we call tactics and strategies. A strategy represents a guiding principle helpful to achieve a particular goal in the software system as a whole. For example, how should your application address issues such as availability or fault handling. To guarantee conceptual integrity and orthogonality strategies shouldn't overlap. Let me introduce an example for such an overlap. Assume, the architects in a project come up with the following strategies: (A) Whenever a security exception appears, a 32 bit error value must be returned. (B) For reporting and handling all kinds of errors and exceptions, structured exception handling shall be used. Both are strategies as they deal with guiding principles for the whole application. But now suppose, you are in the role of a developer. How should you deal with a security exception? Because the two strategies overlap, it is very likely that some of the developers will return error values while the others will apply exception handling. Why is this bad? Overlaps always have a negative impact on understandability and readability of the software architecture. What are tactics? In contrast to strategies, tactics are more fine-grained and closer to implementation. A tactic helps solving local problems instead of addressing a whole software system. Design patterns are very good examples for such tactics. Assume, you have implemented a temperature sensor component which needs to notify other components when specific temperature tresholds are reached. Of course, this is exactly a problem context where the GoF Observer pattern comes into play. Needless to say, that tactics shouldn't overlap either. In the ideal case tactics also help implementing strategies. By the way, architecture patterns such as Model-View-Controller are often applicable to define strategies, while tactical patterns such as Observer help implementing the architecture pattern. I guess, this gives you a better understanding what strategies and tactics are and how they relate with each other. For the job of a software architecture this classification implies a two-step, top-down approach. First define the base line architecture using the strategies that are derived from requirements and are supposed to drive the whole software architecture. In the next step, refine the software architecture base-line using tactics. Yes, but in which order should I integrate strategies and tactics? As strategies (and tactics) must be derived from requirements, let risks and priorities drive the order of architecture design. A system where performance is much more important than platform independence will reveal a completely different architecture than a system where platform independence is king. Thus, in the first case you'll first encounter strategies that deal with performance (caching, pooling, load balancing, concurrency strategies), while in the second case you will preferably apply appropriate strategies for platform independence (strict layering, wrapper-facades, reactors). A good exercise could be to look at your current or last project and figure out all the strategies and tactics applied there. Did you systematically consider and integrate strategies and tactics? In every project, you should regularly take some time and reflect about the project to keep it on the right track!

What the hell is an ESB?

When I am getting involved in discussions about SOA recently, ESB is one of those terms I often hear. ESB is another citizen of the SOA buzzword universe, comprising other TLAs such as BAM, BPM, EAI, or B2B. One of the most entertaining and fun exercises is asking senior management and other powerpoint engineers what exactly they mean by ESB. Guess, how many definitions of ESB you'll discover when asking this question? Once, business magazines such as the Wallstreet Journal start talking about SOA, you should be aware of the following facts:

• 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.

Post Mortem

Did you ever observe small children when they are learning new capabilities such as walking or biking? They are not masters from the beginning, but step by step they are able to improve their skills until they reach a level of mastership. Do they give up in the case of failure? Only in rare cases! Instead, they mostly learn from their failures.
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.

ESB

In the recent time I have been involved in investigations whether SOA represents an appropriate paradigm for buidling highly distributed enterprise and embedded systems. What makes such efforts really challenging is the fact that the SOA universe is polluted with all kinds of acronyms. If you really like to confuse innocent colleagues or customers, I'd suggest to throw terms such as BAM, BPM, WSIT, WSDL, BPEL, BI and the like at your communication partners. The either will consider you a smart guy or a professional IT pretender.