SOA Pitfalls - Integrating your Legacy Apps

The Past: I can still remember the time when television was mostly black and white and color TVs were not widely available. One company constantly kept claiming in newspaper advertisements they had developed a color filter you just needed to place on your B+W TV set to transform it to a full Color TV set. What an easy solution! And the product did a perfect job given you enjoy random and constantly changing colors such as magenta faces or green skies. Sounds funny, but, of course, no one of us techno geeks would ever be so naive, right?

40 years later - The Present: Very often I am now involved in SOA projects.  And in many cases, even developers believe it is sufficient to simply wrap  existing application APIs using WS-* based  interfaces to open and integrate all applications into SOA wonderland. However, you might ask, if that is so simple, why do so many SOA integration endeavors fail?

The Future: SOA integration is not as simple as providing plain adapters. If business processes are the main reason for SOA-enabling an enterprise, it is much more effective to identify an appropriate partitioning of functionality into separate services that are then subject to orchestration. As a first step you need to obtain a consistent and prioritized list of business requirements from which you then define your enterprise architecture in a top-down manner. This might typically begin with simple company internal workflows and end in complex B2B scenarios. You'll need to refactor or even reengineer existing applications if securing investments is important in your company. This implies opening applications by providing service interfaces (in a bottom-up approach). Of course, qualities such as operational and developmental ones introduce additional levels of complexity. For example, opening up an existing intranet application for a B2B partnership scenario requires a whole lot of security considerations.

In summary, the adapter pattern might be simple but its concrete application can incur a whole lot of complexity. Building SOA applications naively will save a lot of time and resources in the short term, but imply a large amount of additional costs  in the mid- and long term.

What is Software Architecture

Like Andrew Tanenbaum, I could argue that there are so many definitions for software architecture that it is difficult to choose from them. You may also define it as follows: Software architecture is taken into consideration only when it hurts.
One possible definition for software architecture could be as follows:Software architecture denotes the set of artifacts and practices required to build a software system so that it achieves its implicit and explicit qualities. It includes the systematic partitioning of the software system into appropriate subsystems and relationships as well as the guiding principles used for that purpose. The partitioning of responsibilities and interactions need to be modelled using an interrelated set of viewpoints to address the functional and non-functional qualities.
Note that I am using "systematic" as an important attribute here as I don't consider ad-hoc systems (for example just hacking a Java program) as software architecture. From this personal definition follows that software architecture is both an entity and an act.
I am wondering what your favourite of software architecture is. Maybe one of the dozens available at the CMU SEI webpages?

Beware of DSLs

At ooPSLA 2007 in Montreal there had been a very entertaining (and educating) panel on object-oriented programming languages and Simula 67 as their common ancestor. And the panelists were pretty excellent: Anders Hejlsberg (C#), James Gosling (Java), Guy Steele (Lisp/Scheme/Fortress), Bertrand Meyer (Eiffel), Ole Lerman Madsen (Beta). Now you might ask how this is related to software architecture.

First of all, programming languages have some influence on the way we think about architecture. Don't believe those experts that want to make you believe architecture design is completely unrelated to paradigms and languages. For example, one of the goals of Simula 67 was to provide a means for modeling systems which often got lost in state-of-the-art languages.

And secondly, we are currently facing a lot of discussions about DSLs (Domain specific languages). The panelists expressed their  concern that now people are starting to develop DSLs who have no experience in language design. It is not trivial to design a language that is complete and consistent as well as usable.  Believe me, I worked on such topics during my time at university.

The conclusions the panelists drew was that they prefer to add more modeling capabilities to programming languages over DSLs. Ruby is one of the examples in this area, but ,of course, it is only the beginning. Upcoming languages such as Scala, offer a lot of cool features for this purpose.

I discussed that issue with Markus (Völter), one of the gurus in Model-Driven Software Development and he shared this conclusion.

My conclusion and observation: Bad DSL design can cause more harm than value. Only language experts should become DSL designers. Designing DSLs on top of programming languages might be an appropriate approach. I already discussed Integrated DSLs in a previous posting.

Project Diary

Did you ever experience those never ending and and continuous discussions about project topics and decisions which you thought had been already addressed? 

Did you ever read an architecture document feeling a little bit confused or lost, because you couldn't remember the rationale of all those decisions?

I am sure, you know what I mean. The problem with software development projects is that there are basically two sources of information besides personal communication:

• Meeting Minutes
• Architecture Documents

Unfortunately, most architecture documents only describe the what, but not the how or why. Meeting Minutes strive for brevity and often don't include all those discussions. In addition, spontaneous meetings of project (sub) teams are often not documented at all.

Your gut feeling may tell you that something is missing here.

What I propose for development projects is an additional document, which I call "Project Diary". This document does not need to be very formal. It should not describe what is already available in other documents (meeting minutes, architecture documents) but instead refer to these sources. And, of course, architecture documents and meeting minutes, should also refer to the project diary. Its sole purpose is to complement these aforementioned documents by adding information such as alternatives discussed for solving a particular problem and the reason why a specific decision was preferred.

The organization of such project diaries may be by date or by topic or by both.

I don't recommend any specific template to use. My experience with all kind of project documents tells me that it is more important to come up with a uniform, complete and consistent style than to  strictly follow a specific template. Just take your style of choice. 

Sometimes, project members don't like the additional efforts of a project diary, especially in very small teams. In these cases I often have written a project diary without telling anyone. As soon as critical situations or fruitless discussions appeared, I would then just read from my project diary. This way, I could convince many people that a project diary offers more value than costs.

Corny Joke - somehow adapted

After their death three IT persons arrived in hell. Among them a senior manager, a consultant and a software architect. One of the devils was in charge of taking care of these unfortunates. However, hell population has the same kind of feelings towards IT experts like the rest of mankind. Thus, the devil offered a deal to the newcomers.  "There is a chimpanzee around this corner. Each of you you will need to make the chimpanzee first laugh, then cry, and finally make him return back to his cage. If you succeed, we'll send you back to earth." First the senior manager approached the chimpanzee. No matter what he said or did, the monkey showed absolutely no reaction. Then the consultant tried his luck. After an hour he also gave up. Finally, it was the turn of the software architect. After a few seconds the chimpanzee started screaming with laughter. After some more seconds he was moved to tears. And as soon as the architect had spoken some additional words, the monkey started panicking, returned immediately to his cage, locked the door and threw away the key. "Ok" the devil said, "I will keep my word, but could you, please, tell me what exactly you said to the chimpanzee?" "Of course!", the architect responded, "First, I told him what job I have which made him laugh. Then I told him what income I get which made him cry. Finally, I told him that we are still searching for new architects!"