It is a small world. (but I am not your school teacher :-) )
- Michael
----- Original Message ----
From: Steve Jones <[EMAIL PROTECTED]>
To: [email protected]
Sent: Thursday, March 20, 2008 11:46:15 PM
Subject: Re: [service-orientated-architecture] [ZapFlash] Why Service Consumers
and Service Providers Should Never Directly Communicate
Ooooooh Spooky :) It was indeed.
Steve
On 20/03/2008, Michael Poulin <[EMAIL PROTECTED] com> wrote:
Steve wrote: "I completely agree. To quote my father at an XML conference in
2001". Intersting, if it was XMLOne, I had to meet with your father - I was
there.
- Michael
----- Original Message ----
From: Steve Jones <jones.steveg@ gmail.com>
To: service-orientated- architecture@ yahoogroups. com
Sent: Thursday, March 20, 2008 12:36:41 PM
Subject: Re: [service-orientated -architecture] [ZapFlash] Why Service
Consumers and Service Providers Should Never Directly Communicate
On 20/03/2008, Stuart Charlton <stuartcharlton@ yahoo.com> wrote:
>
>
>
>
>
>
>
> --- Steve Jones <jones.steveg@ gmail.com> wrote:
>
> > Now here I have to disagree on both points. The "Business SOA" stuff
> > is actually something that is more about people from the computer
> > science & Software Engineering disciplines (as opposed to simply
> > technology) actually reading and learning about business concepts
> > (for
> > instance business process re-enginnering, Six Sigma et al) and
> > looking
> > to see the best way of deliver IT that matches those business
> > expectations.
>
> The industry hype about SOA => business agility surely has to be more
> than getting IT to read a few more books and attend some more seminars.
> ;-)
>
> I've been curious for years how Six Sigma, BPR, or even Lean, are
> related to "Services Oriented Architecture" . I've been pushing the
> connection in my presentations and engagements for years, and one can
> stretch to find linkages and alignments, but frankly, I don't think
> "Services" are a necessary element. They may help or hinder depending
> on what you do, but there are other ways to organize one's business
> architecture.
Well if you look at the "top" of Six Sigma and Lean there are two
basic elements (over simplifying obviously)
1) What are the big flows and big optimisations
2) What are the local flows and local optimisations
So its about enabling an environment in which both of these elements
can happen independently. So the guy on the line can suggest an
improvement and the guy in the boardroom can commission a whole new
way of working at a strategic level.
This is where Services really come in as they provide the mechanism
for this broad brush separation. By not focusing on the detail of
steps at this stage you focus on the _areas_ of control (the
services).
>
> Services (in the sense we mean) and SOA certainly would be a foreign
> word for practitioners in these areas. "Business Architecture" ,
> perhaps, is the more appropriate term for getting IT folks to think
> about business concepts.
I use Business Service Architecture, and my experience in working with
pure BPR/Six Sigma/LEAN folks is that actually its pretty much what
they do at the start of their work as well, they just often call them
something different, but we all have the same blobs and the blobs have
the same actions/capabilitie s/goals etc.
>
> > Now that is something that business does give a shit about as its
> > about realising business concepts through IT not about yet another IT
> > TLA that just means another $10m burnt for little actual benefit.
>
> Which, it turns out, is what technical SOA-in-practice seems to be
> turning into. Maybe BPM next ;-)
BPM 2.0 ;) People burnt $10m doing the 1.0 version with EAI in the
late 90s early 00s.
Its like saying "Now with XML" makes stuff magically work.
>
> > I'd say that there are different flavours of Business SOA out there,
> > but not all of them are fluffy without defined terms and approaches.
>
> I agree with this, and it's valuable to engage with those that have
> sold terms & approaches. But that wasn't my point. There is no
> critical mass among any of these definitions, and I can't see any on
> the horizon.
I know :( Its depressing.
>
> For example, Deloitte's definition of SOA (at least a year or so ago),
> for example, was "Reusable Business Processes". CapGemini's
> defintion, I assume, follows yours. Accenture's definition, I've
> lost, but I recall it tends towards the more technical.
Very depressing :(
>
> How can SOA be this become a long-lasting, productive business trend if
> the basic essentials are a mess of conflicting perceptions and
> priorities? SOA seems to lack a respected champion. If you look at
> Six Sigma, it had Motorola, then GE, then its army of Black Belts
> championing the essentials. With Lean, it was Toyota and Taichii
> Ohno, and then Womack, Liker, etc. With BPR it was Hammer & Champy.
Agreed, there are companies out there who are starting down the road
but the champions will only come after the success.
>
> Who are the tablet holders of the SOA playbook? Gartner? ZapThink???
> ;-) The problem, of course, is that analysts don't _do_, they
> analyze. What happens when they invent or elaborate things beyond
> mainstream practice?
I've always wondered, does that put them in relation to people who teach ;)
>
> I guess what I'm saying is that there is incredible divergence here on
> specifics, even if the expected macro-benefits (agility, incremental
> capital, etc.) are in general agreement. The term has ceased to have
> meaning, and because it seems there is plenty of salvageable merit,
> it's time to specifically figure out what that is, and drive those
> specifics to critical mass.
I'm on board, one of the first and simple things to do (which is very
tiny but from small acorns...) is to agree on what we capture at the
top level. Not worry about the process (yet) but worry about that
very first and critical thing. Its too big to do everything but if we
can agree on that start point then we can move on.
>
> > I completely agree, but what we have also found in these technology
> > changes is that it is almost always the changing of thought, most
> > often from outside IT, that results in the biggest shifts. So the
> > way
> > the departmental people started to (ab)use the PC for point systems
> > caused a massive shift in IT, which the IT people often missed as
> > they
> > felt the PC couldn't compete with their powerful mini-computers.
>
> Sure. That to me is an example of a reflexive relationship - the PC
> was a new technology - the business adopted it and changed the way they
> worked - that changed IT. The business change was catalyzed by
> technology (likely going to happen eventually via pent up demand).
>
> > > I don't even care if they use the Web -- just please, use
> > something at
> > > least as useful and aligned to your goals, not something that's
> > the
> > > practical equivalent of a straight jacket!
> >
> > Unless of course you need a straight jacket. Seriously, there are
> > often good reasons to pick a restrictive and limited approach as that
> > delivers the right behavioural changes and the right business
> > outcome.
> > Its why vanilla package is a better bet than customised package.
>
> I concur. But surely a lot of interest is in the
> not-a-straight- jacket area, if only because trade in straight jackets
> is a buyer's market.
Agreed, which is the point of a decent business SOA approach. The
flexibility comes from knowing when to allow things to flow and where
to put the straight jacket on. I'd argue that at the technology level
you want a straight jacket (the BSB idea) in order to release the
business.
>
> > The big problem I have with most articles is they seem to assume that
> > today's _technology_ view (whether that be REST, WS-*, ESB, etc)
> > represents some sort of pinnacle and that all previous technology
> > should be ditched and nothing in the future could be improved.
>
> Well, I have a big problem with those articles too, though I tend to
> ignore them. I do, however, believe that technological changes are a
> powerful (and unpredictable) catalytic force, and as such are a source
> of opportunity, and so I'm happy to advocate one technology over the
> other in certain contexts. I'd also advocate one business approach
> over another in the right context too.
Agreed, its the context which is important not the buzzword.
>
> > > Technical services architecture helps enable business agility to
> > the
> > > same degree that Enterprise JavaBeans did.
> >
> > Which is (IMO) a bad example if you are implying that EJBs didn't
> > help businesses.
>
> That wasn't my intended implication. In some ways EJBs did help
> businesses; they also hurt quite a few.
>
> > One of the reasons that they helped hugely is that you
> > can get access to a very large averagely skilled workforce in EJBs,
> > now this might not be as "good" as doing everything specific with
> > highly skilled resources but it is at least manageable and to a
> > decent degree predictable.
>
> That usually was how I defended EJB's during their heyday. ;-)
Remember that in terms of effort EJBs are probably bigger now than a
few years ago, just because new systems don't use it doesn't mean the
effort is going down. Support is where the bulk is, and EJBs might
have their issues but at least its a consistent set of issues.
>
> > So I'd argue that EJBs did give business agility,
> > if not technical agility, as they enabled different contractual
> > frameworks to be considered that would not have been possible in a
> > less commoditised arena.
>
> My point is that all Technical Services Architecture is not catalyzing
> change in technology architecture much beyond where it was in 1998 --
> it's still, basically, component software, just now focused on
> protocols of runtimes.
I completely agree. To quote my father at an XML conference in 2001
"Oh look its now time to do it all again... this time in ASCII"
Now I know its strictly Unicode but you get the point.
>
> One still may glean some level of agility out of such an approach, but
> there are alternatives that are a source of opportunity.
I agree.
Steve
>
> Cheers
> Stu
>
>
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try
it now.
<!--
#ygrp-mkp{
border:1px solid #d8d8d8;font-family:Arial;margin:14px 0px;padding:0px 14px;}
#ygrp-mkp hr{
border:1px solid #d8d8d8;}
#ygrp-mkp #hd{
color:#628c2a;font-size:85%;font-weight:bold;line-height:122%;margin:10px 0px;}
#ygrp-mkp #ads{
margin-bottom:10px;}
#ygrp-mkp .ad{
padding:0 0;}
#ygrp-mkp .ad a{
color:#0000ff;text-decoration:none;}
-->
<!--
#ygrp-sponsor #ygrp-lc{
font-family:Arial;}
#ygrp-sponsor #ygrp-lc #hd{
margin:10px 0px;font-weight:bold;font-size:78%;line-height:122%;}
#ygrp-sponsor #ygrp-lc .ad{
margin-bottom:10px;padding:0 0;}
-->
<!--
#ygrp-mlmsg {font-size:13px;font-family:arial, helvetica, clean,
sans-serif;}
#ygrp-mlmsg table {font-size:inherit;font:100%;}
#ygrp-mlmsg select, input, textarea {font:99% arial, helvetica, clean,
sans-serif;}
#ygrp-mlmsg pre, code {font:115% monospace;}
#ygrp-mlmsg * {line-height:1.22em;}
#ygrp-text{
font-family:Georgia;
}
#ygrp-text p{
margin:0 0 1em 0;}
#ygrp-tpmsgs{
font-family:Arial;
clear:both;}
#ygrp-vitnav{
padding-top:10px;font-family:Verdana;font-size:77%;margin:0;}
#ygrp-vitnav a{
padding:0 1px;}
#ygrp-actbar{
clear:both;margin:25px 0;white-space:nowrap;color:#666;text-align:right;}
#ygrp-actbar .left{
float:left;white-space:nowrap;}
..bld{font-weight:bold;}
#ygrp-grft{
font-family:Verdana;font-size:77%;padding:15px 0;}
#ygrp-ft{
font-family:verdana;font-size:77%;border-top:1px solid #666;
padding:5px 0;
}
#ygrp-mlmsg #logo{
padding-bottom:10px;}
#ygrp-reco {
margin-bottom:20px;padding:0px;}
#ygrp-reco #reco-head {
font-weight:bold;color:#ff7900;}
#reco-grpname{
font-weight:bold;margin-top:10px;}
#reco-category{
font-size:77%;}
#reco-desc{
font-size:77%;}
#ygrp-vital{
background-color:#e0ecee;margin-bottom:20px;padding:2px 0 8px 8px;}
#ygrp-vital #vithd{
font-size:77%;font-family:Verdana;font-weight:bold;color:#333;text-transform:uppercase;}
#ygrp-vital ul{
padding:0;margin:2px 0;}
#ygrp-vital ul li{
list-style-type:none;clear:both;border:1px solid #e0ecee;
}
#ygrp-vital ul li .ct{
font-weight:bold;color:#ff7900;float:right;width:2em;text-align:right;padding-right:.5em;}
#ygrp-vital ul li .cat{
font-weight:bold;}
#ygrp-vital a{
text-decoration:none;}
#ygrp-vital a:hover{
text-decoration:underline;}
#ygrp-sponsor #hd{
color:#999;font-size:77%;}
#ygrp-sponsor #ov{
padding:6px 13px;background-color:#e0ecee;margin-bottom:20px;}
#ygrp-sponsor #ov ul{
padding:0 0 0 8px;margin:0;}
#ygrp-sponsor #ov li{
list-style-type:square;padding:6px 0;font-size:77%;}
#ygrp-sponsor #ov li a{
text-decoration:none;font-size:130%;}
#ygrp-sponsor #nc{
background-color:#eee;margin-bottom:20px;padding:0 8px;}
#ygrp-sponsor .ad{
padding:8px 0;}
#ygrp-sponsor .ad #hd1{
font-family:Arial;font-weight:bold;color:#628c2a;font-size:100%;line-height:122%;}
#ygrp-sponsor .ad a{
text-decoration:none;}
#ygrp-sponsor .ad a:hover{
text-decoration:underline;}
#ygrp-sponsor .ad p{
margin:0;}
o{font-size:0;}
..MsoNormal{
margin:0 0 0 0;}
#ygrp-text tt{
font-size:120%;}
blockquote{margin:0 0 0 4px;}
..replbq{margin:4;}
-->
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
