A blueprint is detailed instructions on how to implement a particular
design. Construction blueprints are modified as the building is constructed
to reflect the actual decisions the contractor made in the field.
In building construction, of course, one can have a plan that is distinct
from the artifact itself. In the software world, detailed instructions on
implementation is very often identical to writing code.
I suppose one could describe a particular SOA in terms of service inputs
and outputs and orchestrations, etc. without reference to a vendor
implementation. This is some soft of architectural document, not a blueprint.
I understand what a reference architecture is. I understand what a concrete
architecture is. I have no idea what an abstract blueprint is.
Michael
At 12:49 PM 1/23/2006, wrote:
>To All,
>
>Here is what I gather from the group as a whole:
>
>1. Need a context on what we are doing.
> - 2 cents: A problem statement would be a great start with audience,
> etc...
>
>2. Need to defining use cases to provide context on the blueprints defined
> - 2 cents: establish a use case document that can be expand on this
> and may have domain related spin offs
>
>3. Need to establish what a blueprint is.
>
>I think everyone should start adding to this list and adding opinions, etc...
>
>This may help to create a bit of focus or strategy.
>
>Thanks,
>
>Dan
