
This entry is one of many entries that I’m writing for a journal assignment in my Systems Integration course through Carnegie Mellon. The idea is to answer the question “Why is this particular concept important?” I decided to bring some Web 2.0 to this assignment and leverage my blog. Besides … journaling is for filesystems.
In one of the lectures, we discussed the idea of architectural mismatch that can occur between two applications; the gist of the idea being that sub-components or inner workings of applications/systems are sometimes too coupled or aligned differently to take apart and make a integrated application. If I could just offer up a favorite analogy of mine, it would better illustrate my point. As much as the inner child of a system integrator would like to, you can’t just take apart two applications like Legos and make an awesome new spaceship application.
This image further illustrates the point. In this image we see two applications, A and B, with overlapping functionality. The sub-components of A and B are represented by the different color regions. You can see that if you wanted to create and integrated application C using a mix of sub-components of A and B, it would not be easy because of the architectural mismatch.
Again academia tends to abstract things to primitive shapes — boxes, links, nodes etc. So perhaps a more concrete example is in order. As discussed in our lecture, one of the problems that can occur from integrating two applications is platform compatibility issues, specifically system calls on different platforms can be different. I am immediately reminded of two diagrams I saw on Slashdot.org that outlined the system calls of two web servers, Apache and IIS, running on different platforms, Windows and Linux.
System call mapping of Apache running on Linux
Now imagine trying to take sub-components of these two web servers and creating a single integrated web server. To me, it almost looks like trying to integrate spaghetti with lasagna.
Of course it is still possible to make that ultimate pasta dish of Lasaghetti — an integrated mixture, or system if you’d like, of creamy sauce, cheese, noodles and pasta. The possible solutions for integrating applications with overlapping functionality still holds. You can certainly refactor — or along my favorite analogy you can file the components to fit like Legos — create APIs, write wrappers and marshaling objects, or just simply start from scratch. However, as you can imagine, sorting components out to fit or starting over can be quite costly and time consuming.
As you can see from the diagrams, it is very important to consider the sub-components or the “guts” — so to speak — of applications with overlapping functionality when trying to consolidate or integrate. As much as programmers are trained to document and keep things modular, it’s just not the case sometimes with legacy applications or systems. In a perfect world component code modules would be written like Lego blocks, both interchangeable and reusable, but alas we often live in a world of lost documentation and bad design.
Note to Dr. Butler: Feel free to leave my feedback and grade via the commenting system below. Good or bad, I don’t mind.

Sean
October 13th, 2008
Shawn A. Butler, Ph.D.
October 15th, 2008