On 25/03/2008, Stuart Charlton <[EMAIL PROTECTED]> wrote: > > > > > > > --- Steve Jones <[EMAIL PROTECTED]> wrote: > > > 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). > > I'll buy that - this is why I like to call Large-B "Business Services" > an evolution good-old Business Functions, just with good old boundaries > and graph-dependencies (instead of just trees). We're talking about a > unit of organizational design.
Yup. What I like to think is that Business Services provide a more end-to-end framework than functions did, but the fundamental concept is the same. > > > 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. > > For some reason I just saw a commercial for Tide laundry detergent, > "now with XML, for those whiter whites". ;) > > > > 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 :( > > Indeed. :( This is partly why I've left BEA and moved to a cloud > computing startup -- something a bit less depressing while still > contributing to the improvement of IT. Watch out though, "now with Clouds" could be the next XML! I've seen things recently that seem to think that if it moves into the cloud it automatically ceases to be a problem. > > > > 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. > > Right; services and their boundaries arguably should be goal or > motivation driven, something a bit more concrete than means-ends > analysis. And I've seen some level of agreement there among > architects I've dealt with, though I'm not sure the vendor community > will accept it as it's hard to build a product around something so > abstract, beyond yet-another EA modeling framework/tool/environment. I'm not sure its a difficult tool, after all we are talking about very powerful, simple, abstract models. Its a bunch of circles a bunch of lines and a bunch of attributes on the lines and circles. The problem is that if you can model this part simply, why is the detail stuff so expensive and complex? This is especially true when talking of standardised areas. Steve > > Cheers > Stu > >
