--- 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. > 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. > > 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. Cheers Stu
