I posted my own response on my blog, as well, but since I pretty much  
said the same thing that Anne did, I didn't send it out to group.   
All of you are subscribers to my blog, anyway, right?  :)

Anyway, Rob's question is an interesting one.  The only technology  
that comes to mind for me, which is probably direct analogous to your  
manual versus automatic transmission, is the orchestration engine  
versus the application server.  At the architectural stage, you need  
to be able to break the problem down so you know when a BPM/ 
orchestration engine should be used, and where you should be writing  
Java/C# code.  While both activities are service development  
activities, the models of how you go from development to production  
are quite different, as well as the long term cost of maintaining and  
updating it.  Outside of this one, however, I can't come up with any  
other examples.  Everything else winds up being more about how we  
partition the functional capabilities rather than the technology used  
to implement those functional capabilities.

-tb
http://www.biske.com/blog/

On Sep 5, 2007, at 9:40 AM, Rob Eamon wrote:

> Interesting thoughts. Technology impacts that detailed design. Sounds
> reasonable.
>
> At what point, if ever, does a technology have an impact on the high-
> level design? The example that pops into my head, albeit probably a
> poor one, is a manual transmission vs. an automatic transmission in a
> car. Obviously at a high level the difference can be abstracted away
> as simply "the car will have a transmission, which transfers the
> engine power...." Auto vs. stick being deferred to later design
> phases.
>
> But I wonder if the differences between auto and manual transmission
> were ever at a point that they needed to be accounted for much
> earlier in the analysis/design? Are there any IT technologies that
> have a such an impact that they impact the highest levels of a design-
> -e.g. the architecture?
>
> Conversely, would the use of certain technologies cause some to
> dismiss a solution as not being "true SOA" (whatever "true SOA" is)?
> For example, if I choose, for whatever reason, to use flat-files, FTP
> and file directory interaction as the "stuff in the middle", would
> that be considered non-SOA?
>
> -Rob
>
> --- In [email protected], "Anne Thomas
> Manes" <[EMAIL PROTECTED]> wrote:
>>
>> My response is here:
>> http://apsblog.burtongroup.com/2007/09/when-technology.html
>>
>> Anne
>>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
> [EMAIL PROTECTED]
>

Reply via email to