Database Reference
In-Depth Information
An example of architecting for tactical
goals
Tip
Please be forewarned as the following example is a recipe for a perfect disaster. We have to
put this disclaimer as some could take it as direct architectural advice. It is also sadly real-
istic, since all that we have described next was taken from real implementations. We will
use this example in the later chapters.
So, what are the tactical goals? The essence here is time, usually limited by a timeframe of
a project or several milestones of non-correlated projects. It is always good to stay on
budget and deliver on time what was promised. This is a common scenario for a component
or a single application development process. Isolation, focus on performance, and reliabil-
ity as primary targets have their obvious benefits. As a solution architect, do not bother
your team much with interoperability, as you probably have another
enterprise applica-
tion integration
(
EAI
) team that is especially dedicated to this purpose; they are some-
where nearby and are capable of performing the tricks. Skillful EAI means that some integ-
ration platforms are in place already, providing hub-and-spoke capabilities with all the ne-
cessary transformations, translations, protocol bridges, and so on. Honestly, nothing's
wrong with that. At least, not yet.
All that you need is a capable integration team and be lucky enough not to be at the end in
the row of endless regression tests. Also, it would be prudent to maintain a very thorough
events/error log for your product, just in case you need to identify where all your inbound/
outbound messages have gone. You must be able to prove that you (your application) have
sent all the required outgoing messages, and they are definitely now on the integration plat-
form's side (just search better); alternatively, if you haven't received what you need, the
flaw is definitely on the part of the EAI's design.
As time is of the essence, moving further, you can take the liberty to define all your APIs
and XSDs as close to your technical implementations as possible, based on the DB struc-
ture and the logic of the classes. Modern development platforms and SDK/XDK are truly
advanced, so this task can really be done in no time by a right-mouse click. Following this
path, you can provide newer versions of your application almost instantly after receiving
new requirements, and it's purely EAI's responsibility to maintain concurrent APIs pub-
lished on an integration platform. Again, just be the first in the list of regression tests.
Search WWH ::
Custom Search