I am working for a client where most of the assignments we get are about letting the customer get online access to back-end systems and data related to their relationship with the client. This mean customer data, services etc.
We implement the front-end in a combination of (HTML) XSLT and Perl everything we call is neatly wrapped in a lot of Java, which calls some other Java, which sometimes call proprietary APIs based on a variety of back-ends.
I learned the other day that this sort of architecture is called a 'Totem pole' architecture.
Well anyway, things do however work, but I see one significant flaw in the system in general.
We want to give the user the best user experience possible. One thing is extending our part so more and more stuff can be accessed online. This is good and we are slowly progressing on this part. But sometimes when we start a new project we need to build a new totem pole. This part is improving but still implementing even smaller things take a lot of time and you grow tired of the projects before they are done.
With each layer (or head) in the totem pole, the programmers have attempted to generalize instead of specialize, this is often a good idea and sometimes interfaces can be reused. But mostly we aim for one client, namely the online framework.
I think it is a very good thing that the programmers attempt to generalize, but their APIs should be implemented in regard to the clients. We have experienced several times that APIs are simply not useful from our perspective, since even the simplest of operations require several requests, either we need to gather the data from several interfaces or even services or the APIs simply do not offer everything we could use since somebody never thought that certain data would be interesting to us - the more relevant data we have, the more informative we can be. The more client oriented APIs we get the better user-experience we can implement.
So in my opinion tighter coupling seems to be necessary in this case. We want to be able to tell the truth to the customer and show them the real picture of what is going on and yes we want to do so before they go away.
Another hard thing I have think I mentioned before it getting the back-end developers to understand the importance of the APIs and that we are the client - and the client is always right, right?
“In programming, everything we do is a special case of something more general – and often we know it too quickly.” —Alan J. Perlis, “Epigrams on Programming”
The first time you do something you have no idea how to solve the problem yet, so you just do whatever you need for the task at hand. The second time, you copy your first design and tweak it to fit the new requirements. The third time, you go back and replace special-case functionality with hooks and indirections where necessary. Designing for generality before you know what complexity need to be exposed and what complexity needs to be hidden isn’t useful; it’s merely an exercise in self-gratification (to stay clear of the more prurient synonym).
