Ooooooh Spooky :) It was indeed. Steve
On 20/03/2008, Michael Poulin <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > To: [email protected] > 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<stuartcharlton%40yahoo.com>> > wrote: > > > > > > > > > > > > > > > > --- Steve Jones <jones.steveg@ gmail.com <jones.steveg%40gmail.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.<http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ> > > >
