Database Reference
In-Depth Information
• They should be designed and developed, focusing on nonfunctional requirements
right from the start [R 8]
• They should be secure; able to protect confidentiality and the privacy of all under-
lying resources and communications [R 9]
• They should be resilient to faults, that is, capable of staying operational even in
the event of catastrophic failure of the internal components [R 10]
Note
These are actual consolidated requirements taken from more than ten projects and RFIs.
We could really continue on, but in general, these are the top-ten points of any require-
ments list, and it will be hard to go further without repeating them. Therefore, any list that
is similar to this cannot be consistent with more than 15 unique statements within it. We
suggest keeping these points up your sleeve until the end of this chapter. This is because at
the end of the chapter, we will do some practical exercises of matching listed declarations
to the capabilities of SOA. Quite often, these requirements are based on pure common
sense, and some people declare them as design principles. It is hard to argue that real
design principles should at least be based on common sense, but compliance to this simple
fact is not enough to talk about elements from the previous list as principles. At the mo-
ment, they are just declarations of good intentions, and we, after several implementations
of complex projects, know quite well what road is paved with them. We will talk about the
definition of principles a bit later in a considerable amount of detail, but now it's import-
ant to analyze these wishes and find what's common there and how it is relevant to the
service-oriented approach. It is quite simple to see that the whole list (with one small ex-
ception, which is just to confirm the general rule) can be divided into two categories.
These categories are related to effort (first, third, fourth, fifth, sixth, seventh, and eighth
items) and time (second and seventh items), with the seventh item equally relevant to both
effort and time.
Standing a bit aside, the ninth item, generally described as compliance by security
policies, is nothing more than pure money, as almost no one these days seeks fun in
simple informational vandalism. All security breaches aim to steal your information, that
is, money, and therefore, put you out of business. As a consequence, it's needless to say
that time and effort can essentially be compared to money as well. So, unsurprisingly,
everything boils down to the same logical end, that is, money, which is the key; we have
learned this many times, when talking to the bosses (CIO, CEO, project manager, and so
on). As stated previously, in IT, money comes in two general ways: either we consistently
shorten the delivery cycle or reduce operational costs.
Search WWH ::
Custom Search