Gregg wrote: "The SOA chiefs want to
ignore technology whereas the SOA warriors have to consider it at every step
and just can't seem to understand why the chiefs think it doesn't matter"
While this statement may be a 'matter of speech', I think it is not 100%
accurate.
If the statement is correct, those 'SOA chiefs' should have a short 'life
cycle' because the SOA warriors would rather ignore such SOA chiefs and soon it
would be obvious that the SOA chiefs are useless, their roles will be
eliminated.
If the statement is correct, it may be incorrect in several ways. Firstly, the
SOA chiefs do not ignore technology but abstract it to use architectural
concepts, patterns, and make decisions that the SOA warriors are unfamiliar
with, or cannot comprehend easily. Secondly, the SOA chiefs do not ignore
technology but SOA warriors ignore chief's decisions and do not want to
comprehended
follow them referencing to 'realistic world' constraints without knowing all
constraints and drivers. Thirdly, SOA chiefs do not ignore technology but their
architectural decisions have no realistic grounds and becomes useless for daily
practice.
In my practice, I saw the Second case much more frequently than others. A lot
of SOA warriors believe that HOW is more important than WHAT/WHY because HOW
can demonstrate immediate results. Are these results needed? Such questions are
considered 'above warrior's salary'. I trust that SOA chiefs can and do produce
proper service-oriented architecture decision and solutions (otherwise I do not
accept their 'chief' title). The next step is for SO Governance and SO
Management: Governance has to clear and strictly define WHAT/WHY/WHO has to do
SO implementation daily and Management has to control preservation of this rule.
I use 'Management' in this case at large - as a physical manager and as a Scrum
team's governed decisions.
I had a good conversation with Eric Evans about DDD, SOA and DOSOM. We
certainly agreed that DDD should be driven by model and that this part is
frequently skipped or forgotten. This happens because design starts by
'warriors' while model belongs conceptually to the 'chief's' duties. DOSOM
requires
methodical shift for the point where the domain work ('design') starts - it is
shifted into the service-oriented modelling. Eric agreed that SO is fully
capable of setting the scope for domain design. Having this scope-centric
approach, DOSOM becomes the 'point of contact' between SOA chiefs and SOA
warriors.
Thus, technology matters for service orientation but differently to different
players.
- Michael
________________________________
From: Gregg Wonderly <[email protected]>
To: [email protected]
Sent: Wednesday, April 1, 2009 9:13:39 PM
Subject: Re: [service-orientated-architecture] Re: Fielding says It is okay to
use POST
Rob Eamon wrote:
> Dave Cutler springs to mind as well. And in a completely different
> field, Clarence "Kelly" Johnson.
One of the compelling feeling that I get about people like Kelly Johnson, are
that when someone can, and will take up a task to be done, and has the
technical
knowledge to manage the task, including managing the development of work items
and the execution of the work items, good stuff gets done.
What is happening with SOA, from my perspective, is that the breadth of the
subject is so wide, that no one technology, person, or thought process is
actually sufficient, without reducing choices to be made. For example, if you
remove the choice of application protocol, that "simplifies" a lot of things by
reducing what any related software has to deal with. If you removed
programming
language as a choice for software, that removes additional complication.
So, we see people who continue to focus on smaller parts as in the choice of
"application protocol" such as WS-* vs REST, so that they can deal with the
complications of just that choice alone and restrict the number of issues to
deal with.
The SOA chiefs want to ignore technology whereas the SOA warriors have to
consider it at every step and just can't seem to understand why the chiefs
think
it doesn't matter.
Sure, it doesn't matter when you are at the 40k ft view, you see the SR-71 and
see that it can carry out its mission. The people who are making sure the
elevons move when the control stick goes back and forth don't care about the
40k
ft view, because its not where "works or doesn't work" is meaningful; i.e you
can't get to 40k ft without working controls...
Gregg Wonderly
