Fwd: From Chris Bird a Brit-EA living in Texas..
6 views
Skip to first unread message
nigel green
Oct 31, 2008, 5:37:57 AM10/31/08
to vpe...@googlegroups.com
---------- Forwarded message ----------
From: Sally Bean <sa...@sallybean.com>
Date: Fri, Oct 31, 2008 at 9:11 AM
Subject: RE: From Chris Bird a Brit-EA living in Texas..
To: ro...@objectwatch.com, ch...@thenetworkeffect.net, John F Schlesinger <jschle...@computer.org>, nigel green <nigelp...@googlemail.com>, Charles Edwards <charles...@processwave.com>, Roy Grubb <royg...@gandanet.com.hk>
True, Roger.
There is 'soft' complexity, that arises from multiple stakeholders having
different backgrounds, values and viewpoints, and 'hard' complexity that
comes from large size and multiple interconnections.
For those familiar with Dave Snowden's Cynefin model, soft complexity is
the upper left quadrant (COMPLEX: invisible, un-ordered, unable to predict
cause and effect), and hard complexity is the upper right quadrant
(COMPLICATED: invisible, ordered, able to predict cause and effect given the
right assumptions and information)
This link takes you to his original paper, though he's tweaked the
terminology since then
http://cognitive-edge.com/articledetails.php?articleid=14
I would say from my initial understanding of these ideas, that SIP addresses
mainly the complicated domain (hard complexity), and VPEC-T (5D lens)
addresses the complex domain. Not so sure about VPEC-T (threads and beads) -
perhaps that applies to both?
Sally
-----Original Message-----
From: Roger Sessions [mailto:ro...@objectwatch.com]
Sent: 30 October 2008 21:10
To: ch...@thenetworkeffect.net; 'John F Schlesinger'
Cc: 'nigel green'; 'Charles Edwards'; 'Roy Grubb'; Sally Bean
From: Sally Bean <sa...@sallybean.com>
Date: Fri, Oct 31, 2008 at 9:11 AM
Subject: RE: From Chris Bird a Brit-EA living in Texas..
To: ro...@objectwatch.com, ch...@thenetworkeffect.net, John F Schlesinger <jschle...@computer.org>, nigel green <nigelp...@googlemail.com>, Charles Edwards <charles...@processwave.com>, Roy Grubb <royg...@gandanet.com.hk>
True, Roger.
There is 'soft' complexity, that arises from multiple stakeholders having
different backgrounds, values and viewpoints, and 'hard' complexity that
comes from large size and multiple interconnections.
For those familiar with Dave Snowden's Cynefin model, soft complexity is
the upper left quadrant (COMPLEX: invisible, un-ordered, unable to predict
cause and effect), and hard complexity is the upper right quadrant
(COMPLICATED: invisible, ordered, able to predict cause and effect given the
right assumptions and information)
This link takes you to his original paper, though he's tweaked the
terminology since then
http://cognitive-edge.com/articledetails.php?articleid=14
I would say from my initial understanding of these ideas, that SIP addresses
mainly the complicated domain (hard complexity), and VPEC-T (5D lens)
addresses the complex domain. Not so sure about VPEC-T (threads and beads) -
perhaps that applies to both?
Sally
-----Original Message-----
From: Roger Sessions [mailto:ro...@objectwatch.com]
Sent: 30 October 2008 21:10
To: ch...@thenetworkeffect.net; 'John F Schlesinger'
Cc: 'nigel green'; 'Charles Edwards'; 'Roy Grubb'; Sally Bean
Subject: RE: From Chris Bird a Brit-EA living in Texas..
Not to take anything away from VPEC-T, but I feel I need to put in a word
for complexity control. I believe that the more progress we can make on
synergistic partitioning the easier it will be to have fruitful VPEC-T
discussions. Conversely, the sooner we have VPEC-T discussions, the sooner
we can have fruitful partitioning analysis. This is why I see so much value
in using both SIP (with its focus on complexity control) and VPEC-T (with
its focus on collaboration) together. They compliment each other nicely.
I think you are all having too much fun there without me!
Best wishes from Houston,
Roger
------------------------------
Roger Sessions
CTO, ObjectWatch
ro...@objectwatch.com 979/836-2244
www.objectwatch.com
blog: simplearchitectures.blogspot.com
-----Original Message-----
From: Christopher Bird [mailto:ch...@thenetworkeffect.net]
Sent: Thursday, October 30, 2008 3:04 PM
To: John F Schlesinger
Cc: nigel green; Charles Edwards; Roy Grubb; Sally Bean;
ro...@objectwatch.com; ch...@thenetworkeffect.net
Subject: Re: From Chris Bird a Brit-EA living in Texas..
Yup, that pretty much covers it!
With apologies to Nigel, I am going to paste in a reply I wrote to him
before I saw you all weighing in!
No doubt that scoping and scope creep are the same for 5D as they are for
other methods - including SWOT.
Where I was coming from was a kind of expectation management angle. When we
start applying 5D, we need to have sonderstanding of what is the "problem"
that we are addressing. Not necessarily the outcome - in fact unless the
outcome is a business outcome it should not be here at all.
But somebody with sufficient USD, GBP, EUR, etc. presumably has some
thought of what needs to be done. That provides some degree of guidance to
us as we apply any/all methods.
Now that guidance is largely directional, but there are likely to be some
hard edged constraints around it. Those constraints will likely be Policy,
but may be Values. ("Don't be evil" for example is a Value, not a Policy).
However that Value isn't enough to decide where any focus should be.
Admittedly it would be a fascinating exercise to take that one Value and
look at all the ways it could unpack through VPEC-T. However, what I suspect
would happen is that we would realize that there are multiple "sub-VPEC-Ts"
that we would need because we could never get a consistent set of Policies,
Events and Content across the full Value system. So somewhere there has to
be some coherence. There may have to be some leveling too. Making sure that,
for example, the Events are at the same level as the Policy. So you don't
(probably) want an ATM withdrawal Event when you are working at the level of
the bank's strategy.
All this demands skillful handling of these powerful concepts - skills that
are and should be absolutely within the tool-kit of any consultant worth
their salt.
My specific comments in the first email were about the book and not the
method. The book - as a first time introduction - made me move around the
levels (what kind of problem we are addressing) too much. I had to
deliberately ignore the swing example while I was thinking about bigger
picture problems. Yes to those of you who are experienced with the
approach/technique, you can move seamlessly up and down the
abstraction/scope or whatever one calls it levels. For neophytes, managing
the levels and the concepts at the same time was one moving part too many, I
felt. But that is pretty minor criticism.
Now to apply it on some juicy problems!
> Interesting question. The scope of the Bank of Ireland engagement was
> the entire enterprise, in particular the parts covered by the four
> elements of their 2012 strategy! These were: channels; payments; core
> banking; and finance. That didn't leave a lot over.
>
> John Schlesinger
> Home Phone +44 20 7833 5930
> Mobile Phone +44 7794 353 356
>
>
>
>
> ________________________________
> From: nigel green <nigelp...@googlemail.com>
> To: Charles Edwards <charles...@processwave.com>; Roy Grubb
> <royg...@gandanet.com.hk>; Sally Bean <sa...@sallybean.com>;
> ro...@objectwatch.com; John Schlesinger <jschle...@computer.org>;
> ch...@thenetworkeffect.net
> Sent: Thursday, October 30, 2008 4:49:06 PM
> Subject: Re: From Chris Bird a Brit-EA living in Texas..
>
> I think we might be on to something here - something to do with
> Iteration and Agility.... but...
>
> I still think it depends on the nature of the engagement - I've seen
> VPEC-T to help discover/describe architectural principles to
> challenge/re-think decisions to explore/nail-down shared-services and
> to untangle knotty legacy IT/IT dept attitude issues without hearing
> about any Scope issues - and in an External Consulting context. In
> each case the scope is defined by the contract which then constrains
> the VPEC-T work in one way or another. It's interesting that VPEC-T
> was born in a government contract (CJS)!.
>
> John - how was scope handled when you and Dave used a VPEC-T approach
> as external consultants?
>
> n.
>
>
> On Thu, Oct 30, 2008 at 2:45 PM, Charles Edwards
> <charles...@processwave.com> wrote:
>
> In my past when I used to run my own company Consulting to companies
> on Software Development projects (which included VPEC-T like Business
> RAD sessions), we would structure the contact around a set of iterations.
>
> - Fixed Price for the first n (2-4) weeks of Inception workshops with
> rough indicative time and money estimates for the remaining
> iterations; At any point they were free to take the outcome of the
> fixed price bit and get alternative quotes for the remainder. (they
> never did)
> - Then Fixed price for next Elaboration iteration (n weeks/months)
> based upon outcomes again with revised rough indicative time and money
> estimates for the remaining iterations; (or another Inception 2 weeks
> if big issues / deltas emerged)
> - and so on, each time refining the quotes and scope until the client
> ended up with a working system that completely fitted into the Business.
>
> Admittedly - the Government Departments could never take on this
> approach
> - and we simply avoided all dealings with them - but then again I
> would argue they are the most likely to have the worst of the failed
projects...
>
> "I like hitting my head against the wall, because it feels so nice
> when I stop!"
>
> regards Charles
>
>
> Quoting Roy Grubb <royg...@gandanet.com.hk>:
>
>
> Nigel,
>
> We've chewed that fat over this during a convivial dinner, but writing
> it down lets me think more clearly.
>
> VPEC-T addresses issues not formally covered by approaches I've
> encountered in the past, of course.
>
> Principally, stretching...
> ... Value out beyond the obvious value to the business, ... Content
> beyond formally specified data, and ... explicitly examining Trust.
>
> One of VPEC-T's beauties, IMO, is that it goes 'looking for trouble'
> with the dual effect of increasing the chances of success (by not
> ignoring those things that might otherwise only be discovered too late
> or not be recognized at all) and, by definition, increasing the
> possibility of the unexpected being found.
>
> Then, it will depend greatly on the organization under study, and who
> is doing the study. Speaking from the perspective of an external
> consultant, scope is critical. Yes, I acknowledge you are an e.c. as
> well Nigel, but in a different context.
>
> As someone who has carried out assignments for flexible organizations
> (like DHL as it was some years ago) and over-rigid ones (HK
> government departments and quangos), the ability of the project
> sponsor to accept unexpected results of the discovery process differs
> as does chalk and cheese.
>
> The discovery that a project as originally conceived has too narrow a
> scope can be severely problematic if the client is not realistic. If you
> have a civil servant looking at a contract, concerned only with not
> having to explain to his superior that he has had to agree to deviate
> from the original contract, then no matter how good the reason, it
> can be a painful and time-consuming process to avoid a loss-making
> assignment for the business analyst.
>
> Charles' phrase 'in a collaborative environment' sums it up, I think.
> I would never propose a VPEC-T study to a HK government department
> unless I felt the projects sponsor understood what could come out of
> it, and the contract reflected that understanding.
>
> Roy
> ----- Original Message -----
> From: nigel green
> To: Roy Grubb ; Sally Bean ; ro...@objectwatch.com ; Charles Edwards
> ; John Schlesinger ; ch...@thenetworkeffect.net
> Sent: Thursday, 30 October 2008 17:17
> Subject: Re: From Chris Bird a Brit-EA living in Texas..
>
>
> All,
> I think this whole scope thing is interesting - particularly because
> I'm struggling to see the problem, For me, 'scope' and 'scope creep'
> are the same for the 5D Lens method as they are for SWOT or
> Force-field or any other type of non-EA business analysis method. In
> these techniques the topic of the analysis defines the scope. Do we
> get too hung-up about scope in EA and if so why? Have we overreacted
> to
the'boil-the-ocean'
> accusations of the past?
>
>
> VPEC-T in Threads and Beads style analysis is more nailed-down to a
> particular business 'process' or theme and is more like traditional
> process analysis - does this help the scope worriers amongst us :-)
>
>
> Or am I still missing something!
>
>
> nigel.
>
>
> On Wed, Oct 29, 2008 at 10:46 AM, Roy Grubb
> <royg...@gandanet.com.hk>
> wrote:
>
> Nigel,
>
> The scope thing again... As I mentioned, seems to me that
> scope-creep is built in. It's essential not to place an artificial
> boundary in the way of getting the job done, and at the same time the
> business needs to trust the business analysts to recognize, realize
> and admit realistic boundaries when they are reached. So Trust
> spreads there as well. 'Realistic', now there's a weasel word.
>
> Good stuff.
>
> Roy
> ----- Original Message -----
> From: nigel green
> To: Roy Grubb ; Sally Bean ; ro...@objectwatch.com ; Charles
> Edwards ; John Schlesinger
> Sent: Wednesday, 29 October 2008 17:26
> Subject: From Chris Bird a Brit-EA living in Texas..
>
>
> fyi
>
>
> ---------- Forwarded message ----------
> From: Christopher Bird <seab...@gmail.com>
> Date: Tue, Oct 28, 2008 at 3:55 PM
> Subject: Fwd: Trying to remember to keep the address this time!
> To: nigelp...@googlemail.com
>
>
> Oops, I misspelled the first time
>
>
> ---------- Forwarded message ----------
> From: Christopher Bird <seab...@gmail.com>
> Date: Tue, Oct 28, 2008 at 11:52 AM
> Subject: Trying to remember to keep the address this time!
> To: nigep...@googlemail.com
>
>
> Hi Nigel,
>
> The twitter format is just too small for the kind of conversation
> that we could have about taoofit and LIT.
>
> The first observation from LIT is that I wasn't sure where it was
> being targeted. Application/Architecture/Strategy or what. There are
> some notions of each. And since the distinction itself is rather
> blurred it isn't surprising. Because you use the swing example (or the
> very nice example on the web site) to show the miscommunication, that
> feels like an application level discussion, yet the approach is in
> some ways more valuable at the strategic and architectural levels.
>
> The second observation is that It can sometimes be hard to break
> in
> - essentially to identify what you want to have the concept about.
> That driver or scoping statement perhaps provides some organizing of
> the thinking model. Otherwise I can see boundaries being expanded and
> scope creeping wildly. Not necessarily a bad thing when doing
> discovery (the time when you are widening the problem to make sure
> you have it all), but less helpful when narrowing for implementation.
>
> As I mentioned in the tweet and you responded with the blog
> entry, I am thinking that the Soft Systems stuff (Lancaster, not
> Leicester, I
> apologize) can maybe provide some guidance into the VPEC-T thinking
> model. Really trying to get some ideas/checklists of places to go to
> get the values/policies, etc.
>
> The event model is so critical. I loved the piece in the book
> that talks about bending to the will of IT, whereas we should be
> encouraging IT to enable the business. The loose coupling eof events
> is critical - followed quickly by reconciliation mechanisms as
> identified under Trust. In my reading the Trust piece really helps us
> with the whole "security" angle - but tied back into Policy. To some
> extent Policy determines the "openness" that we anticipate. "We ensure
> that nothing we keep about our customers will ever be leaked to
> unauthorized parties" as a policy statement. So now we have something
> concrete for Trust to worry about. That's Trust in a narrow sense -
> there are broader senses we have to deal with too.
> The dog that didn't bark is as important as the dog that did. Of
> course then we have the content....
>
> Content separated from Event. Now that is hard for many people as
> you observe, but again, critical. The dog not barking, vs the tone of
> the bark when it does... Much information can be deduced from
> frequency analysis/traffic analysis (code breaking - especially
> Purple) - even if you can't break the code, you know that something is
> up....
>
> Trust. The all pervasive. Trust but verify feeds us back into
> reconciliation which is a Policy statement.
>
> So it hangs together - but you knew that! I was just expressing
> what I got out.
>
> So back to my first thought - how to apply for different purposes.
> For example, Phyllis has a job to do to redefine the role of the TV
> station in the University where she teaches. No IT involved. Yes
> there is technology, but that is the technology of the medium, not
> really information technology. We are looking at changing where it
> reports, how it can be used, who benefits from its existence, what a
> State University is allowed to do, how the various interacting
> departments trust each other...So I am going to give it a VPEC-T go
> and see what happens. Then there is a "product" I am thinking of
> developing on the side. Simple, cool (I hope), valuable and cheap.
> What's not to like? Again a project level VPEC-T set of thinking
>
> I'll keep you in the loop
>
> C
>
> +1 (469) 438 3098
>
>
> --
> My kitchen blog
> http://seabirdskitchen.blogspot.com
>
>
>
>
> --
> My kitchen blog
> http://seabirdskitchen.blogspot.com
>
>
>
>
> --
> Mobile: +44 789 1150 181
> Twitter:taoofit
>
> Please visit:
> http://www.LIThandbook.com
> http://servicefab.blogspot.com
>
>
>
>
> --
> Mobile: +44 789 1150 181
> Twitter:taoofit
>
> Please visit:
> http://www.LIThandbook.com
> http://servicefab.blogspot.com
>
>
>
>
>
>
> --
> Mobile: +44 789 1150 181
> Twitter:taoofit
>
> Please visit:
> http://www.LIThandbook.com
> http://servicefab.blogspot.com
>
--
http://seabirdskitchen.blogspot.com
Not to take anything away from VPEC-T, but I feel I need to put in a word
for complexity control. I believe that the more progress we can make on
synergistic partitioning the easier it will be to have fruitful VPEC-T
discussions. Conversely, the sooner we have VPEC-T discussions, the sooner
we can have fruitful partitioning analysis. This is why I see so much value
in using both SIP (with its focus on complexity control) and VPEC-T (with
its focus on collaboration) together. They compliment each other nicely.
I think you are all having too much fun there without me!
Best wishes from Houston,
Roger
------------------------------
Roger Sessions
CTO, ObjectWatch
ro...@objectwatch.com 979/836-2244
www.objectwatch.com
blog: simplearchitectures.blogspot.com
-----Original Message-----
From: Christopher Bird [mailto:ch...@thenetworkeffect.net]
Sent: Thursday, October 30, 2008 3:04 PM
To: John F Schlesinger
Cc: nigel green; Charles Edwards; Roy Grubb; Sally Bean;
ro...@objectwatch.com; ch...@thenetworkeffect.net
Subject: Re: From Chris Bird a Brit-EA living in Texas..
Yup, that pretty much covers it!
With apologies to Nigel, I am going to paste in a reply I wrote to him
before I saw you all weighing in!
No doubt that scoping and scope creep are the same for 5D as they are for
other methods - including SWOT.
Where I was coming from was a kind of expectation management angle. When we
start applying 5D, we need to have sonderstanding of what is the "problem"
that we are addressing. Not necessarily the outcome - in fact unless the
outcome is a business outcome it should not be here at all.
But somebody with sufficient USD, GBP, EUR, etc. presumably has some
thought of what needs to be done. That provides some degree of guidance to
us as we apply any/all methods.
Now that guidance is largely directional, but there are likely to be some
hard edged constraints around it. Those constraints will likely be Policy,
but may be Values. ("Don't be evil" for example is a Value, not a Policy).
However that Value isn't enough to decide where any focus should be.
Admittedly it would be a fascinating exercise to take that one Value and
look at all the ways it could unpack through VPEC-T. However, what I suspect
would happen is that we would realize that there are multiple "sub-VPEC-Ts"
that we would need because we could never get a consistent set of Policies,
Events and Content across the full Value system. So somewhere there has to
be some coherence. There may have to be some leveling too. Making sure that,
for example, the Events are at the same level as the Policy. So you don't
(probably) want an ATM withdrawal Event when you are working at the level of
the bank's strategy.
All this demands skillful handling of these powerful concepts - skills that
are and should be absolutely within the tool-kit of any consultant worth
their salt.
My specific comments in the first email were about the book and not the
method. The book - as a first time introduction - made me move around the
levels (what kind of problem we are addressing) too much. I had to
deliberately ignore the swing example while I was thinking about bigger
picture problems. Yes to those of you who are experienced with the
approach/technique, you can move seamlessly up and down the
abstraction/scope or whatever one calls it levels. For neophytes, managing
the levels and the concepts at the same time was one moving part too many, I
felt. But that is pretty minor criticism.
Now to apply it on some juicy problems!
> Interesting question. The scope of the Bank of Ireland engagement was
> the entire enterprise, in particular the parts covered by the four
> elements of their 2012 strategy! These were: channels; payments; core
> banking; and finance. That didn't leave a lot over.
>
> John Schlesinger
> Home Phone +44 20 7833 5930
> Mobile Phone +44 7794 353 356
>
>
>
>
> ________________________________
> From: nigel green <nigelp...@googlemail.com>
> To: Charles Edwards <charles...@processwave.com>; Roy Grubb
> <royg...@gandanet.com.hk>; Sally Bean <sa...@sallybean.com>;
> ro...@objectwatch.com; John Schlesinger <jschle...@computer.org>;
> ch...@thenetworkeffect.net
> Sent: Thursday, October 30, 2008 4:49:06 PM
> Subject: Re: From Chris Bird a Brit-EA living in Texas..
>
> I think we might be on to something here - something to do with
> Iteration and Agility.... but...
>
> I still think it depends on the nature of the engagement - I've seen
> VPEC-T to help discover/describe architectural principles to
> challenge/re-think decisions to explore/nail-down shared-services and
> to untangle knotty legacy IT/IT dept attitude issues without hearing
> about any Scope issues - and in an External Consulting context. In
> each case the scope is defined by the contract which then constrains
> the VPEC-T work in one way or another. It's interesting that VPEC-T
> was born in a government contract (CJS)!.
>
> John - how was scope handled when you and Dave used a VPEC-T approach
> as external consultants?
>
> n.
>
>
> On Thu, Oct 30, 2008 at 2:45 PM, Charles Edwards
> <charles...@processwave.com> wrote:
>
> In my past when I used to run my own company Consulting to companies
> on Software Development projects (which included VPEC-T like Business
> RAD sessions), we would structure the contact around a set of iterations.
>
> - Fixed Price for the first n (2-4) weeks of Inception workshops with
> rough indicative time and money estimates for the remaining
> iterations; At any point they were free to take the outcome of the
> fixed price bit and get alternative quotes for the remainder. (they
> never did)
> - Then Fixed price for next Elaboration iteration (n weeks/months)
> based upon outcomes again with revised rough indicative time and money
> estimates for the remaining iterations; (or another Inception 2 weeks
> if big issues / deltas emerged)
> - and so on, each time refining the quotes and scope until the client
> ended up with a working system that completely fitted into the Business.
>
> Admittedly - the Government Departments could never take on this
> approach
> - and we simply avoided all dealings with them - but then again I
> would argue they are the most likely to have the worst of the failed
projects...
>
> "I like hitting my head against the wall, because it feels so nice
> when I stop!"
>
> regards Charles
>
>
> Quoting Roy Grubb <royg...@gandanet.com.hk>:
>
>
> Nigel,
>
> We've chewed that fat over this during a convivial dinner, but writing
> it down lets me think more clearly.
>
> VPEC-T addresses issues not formally covered by approaches I've
> encountered in the past, of course.
>
> Principally, stretching...
> ... Value out beyond the obvious value to the business, ... Content
> beyond formally specified data, and ... explicitly examining Trust.
>
> One of VPEC-T's beauties, IMO, is that it goes 'looking for trouble'
> with the dual effect of increasing the chances of success (by not
> ignoring those things that might otherwise only be discovered too late
> or not be recognized at all) and, by definition, increasing the
> possibility of the unexpected being found.
>
> Then, it will depend greatly on the organization under study, and who
> is doing the study. Speaking from the perspective of an external
> consultant, scope is critical. Yes, I acknowledge you are an e.c. as
> well Nigel, but in a different context.
>
> As someone who has carried out assignments for flexible organizations
> (like DHL as it was some years ago) and over-rigid ones (HK
> government departments and quangos), the ability of the project
> sponsor to accept unexpected results of the discovery process differs
> as does chalk and cheese.
>
> The discovery that a project as originally conceived has too narrow a
> scope can be severely problematic if the client is not realistic. If you
> have a civil servant looking at a contract, concerned only with not
> having to explain to his superior that he has had to agree to deviate
> from the original contract, then no matter how good the reason, it
> can be a painful and time-consuming process to avoid a loss-making
> assignment for the business analyst.
>
> Charles' phrase 'in a collaborative environment' sums it up, I think.
> I would never propose a VPEC-T study to a HK government department
> unless I felt the projects sponsor understood what could come out of
> it, and the contract reflected that understanding.
>
> Roy
> ----- Original Message -----
> From: nigel green
> To: Roy Grubb ; Sally Bean ; ro...@objectwatch.com ; Charles Edwards
> ; John Schlesinger ; ch...@thenetworkeffect.net
> Sent: Thursday, 30 October 2008 17:17
> Subject: Re: From Chris Bird a Brit-EA living in Texas..
>
>
> All,
> I think this whole scope thing is interesting - particularly because
> I'm struggling to see the problem, For me, 'scope' and 'scope creep'
> are the same for the 5D Lens method as they are for SWOT or
> Force-field or any other type of non-EA business analysis method. In
> these techniques the topic of the analysis defines the scope. Do we
> get too hung-up about scope in EA and if so why? Have we overreacted
> to
the'boil-the-ocean'
> accusations of the past?
>
>
> VPEC-T in Threads and Beads style analysis is more nailed-down to a
> particular business 'process' or theme and is more like traditional
> process analysis - does this help the scope worriers amongst us :-)
>
>
> Or am I still missing something!
>
>
> nigel.
>
>
> On Wed, Oct 29, 2008 at 10:46 AM, Roy Grubb
> <royg...@gandanet.com.hk>
> wrote:
>
> Nigel,
>
> The scope thing again... As I mentioned, seems to me that
> scope-creep is built in. It's essential not to place an artificial
> boundary in the way of getting the job done, and at the same time the
> business needs to trust the business analysts to recognize, realize
> and admit realistic boundaries when they are reached. So Trust
> spreads there as well. 'Realistic', now there's a weasel word.
>
> Good stuff.
>
> Roy
> ----- Original Message -----
> From: nigel green
> To: Roy Grubb ; Sally Bean ; ro...@objectwatch.com ; Charles
> Edwards ; John Schlesinger
> Sent: Wednesday, 29 October 2008 17:26
> Subject: From Chris Bird a Brit-EA living in Texas..
>
>
> fyi
>
>
> ---------- Forwarded message ----------
> From: Christopher Bird <seab...@gmail.com>
> Date: Tue, Oct 28, 2008 at 3:55 PM
> Subject: Fwd: Trying to remember to keep the address this time!
> To: nigelp...@googlemail.com
>
>
> Oops, I misspelled the first time
>
>
> ---------- Forwarded message ----------
> From: Christopher Bird <seab...@gmail.com>
> Date: Tue, Oct 28, 2008 at 11:52 AM
> Subject: Trying to remember to keep the address this time!
> To: nigep...@googlemail.com
>
>
> Hi Nigel,
>
> The twitter format is just too small for the kind of conversation
> that we could have about taoofit and LIT.
>
> The first observation from LIT is that I wasn't sure where it was
> being targeted. Application/Architecture/Strategy or what. There are
> some notions of each. And since the distinction itself is rather
> blurred it isn't surprising. Because you use the swing example (or the
> very nice example on the web site) to show the miscommunication, that
> feels like an application level discussion, yet the approach is in
> some ways more valuable at the strategic and architectural levels.
>
> The second observation is that It can sometimes be hard to break
> in
> - essentially to identify what you want to have the concept about.
> That driver or scoping statement perhaps provides some organizing of
> the thinking model. Otherwise I can see boundaries being expanded and
> scope creeping wildly. Not necessarily a bad thing when doing
> discovery (the time when you are widening the problem to make sure
> you have it all), but less helpful when narrowing for implementation.
>
> As I mentioned in the tweet and you responded with the blog
> entry, I am thinking that the Soft Systems stuff (Lancaster, not
> Leicester, I
> apologize) can maybe provide some guidance into the VPEC-T thinking
> model. Really trying to get some ideas/checklists of places to go to
> get the values/policies, etc.
>
> The event model is so critical. I loved the piece in the book
> that talks about bending to the will of IT, whereas we should be
> encouraging IT to enable the business. The loose coupling eof events
> is critical - followed quickly by reconciliation mechanisms as
> identified under Trust. In my reading the Trust piece really helps us
> with the whole "security" angle - but tied back into Policy. To some
> extent Policy determines the "openness" that we anticipate. "We ensure
> that nothing we keep about our customers will ever be leaked to
> unauthorized parties" as a policy statement. So now we have something
> concrete for Trust to worry about. That's Trust in a narrow sense -
> there are broader senses we have to deal with too.
> The dog that didn't bark is as important as the dog that did. Of
> course then we have the content....
>
> Content separated from Event. Now that is hard for many people as
> you observe, but again, critical. The dog not barking, vs the tone of
> the bark when it does... Much information can be deduced from
> frequency analysis/traffic analysis (code breaking - especially
> Purple) - even if you can't break the code, you know that something is
> up....
>
> Trust. The all pervasive. Trust but verify feeds us back into
> reconciliation which is a Policy statement.
>
> So it hangs together - but you knew that! I was just expressing
> what I got out.
>
> So back to my first thought - how to apply for different purposes.
> For example, Phyllis has a job to do to redefine the role of the TV
> station in the University where she teaches. No IT involved. Yes
> there is technology, but that is the technology of the medium, not
> really information technology. We are looking at changing where it
> reports, how it can be used, who benefits from its existence, what a
> State University is allowed to do, how the various interacting
> departments trust each other...So I am going to give it a VPEC-T go
> and see what happens. Then there is a "product" I am thinking of
> developing on the side. Simple, cool (I hope), valuable and cheap.
> What's not to like? Again a project level VPEC-T set of thinking
>
> I'll keep you in the loop
>
> C
>
> +1 (469) 438 3098
>
>
> --
> My kitchen blog
> http://seabirdskitchen.blogspot.com
>
>
>
>
> --
> My kitchen blog
> http://seabirdskitchen.blogspot.com
>
>
>
>
> --
> Mobile: +44 789 1150 181
> Twitter:taoofit
>
> Please visit:
> http://www.LIThandbook.com
> http://servicefab.blogspot.com
>
>
>
>
> --
> Mobile: +44 789 1150 181
> Twitter:taoofit
>
> Please visit:
> http://www.LIThandbook.com
> http://servicefab.blogspot.com
>
>
>
>
>
>
> --
> Mobile: +44 789 1150 181
> Twitter:taoofit
>
> Please visit:
> http://www.LIThandbook.com
> http://servicefab.blogspot.com
>
--
http://seabirdskitchen.blogspot.com
--
Mobile: +44 789 1150 181
Twitter:taoofit
Please visit:
http://www.LIThandbook.com
http://servicefab.blogspot.com
aapt...@gmail.com
Nov 1, 2008, 5:48:09 AM11/1/08
to VPEC-T
Reading this thread reminds me of a thread on LiT:
http://www.lithandbook.com/?p=33#comment-68
In addressing complexity it seems to me that the 'cut' or partitioning
can be made along different dimensions, function being one of them or
by clustering of various dimenisons into cohesive elements.
To explain what I mean, in information engineering there is the
established approach of clustering based on examining the relationship
between function and data. This provides a very logical partitioning
(and from what I've read of SIP it extends this type of approach in a
more rigorous way), however it doesn't always relate to the real world
and the politics of information.
This is where I think the VPEC-T dimensions can help us understand the
difference between this logical partitioning and the complexity we
observe in the real world (i.e. overlay the effects of V,P and T on
the clustering of E and C), and help us get to the critical space
between partitions.
On Oct 31, 10:37 am, "nigel green" <nigelpsgr...@googlemail.com>
wrote:
> > From: nigel green <nigelpsgr...@googlemail.com>
> > To: Charles Edwards <charles.edwa...@processwave.com>; Roy Grubb
> > <roygr...@gandanet.com.hk>; Sally Bean <sa...@sallybean.com>;
> > ro...@objectwatch.com; John Schlesinger <jschlesin...@computer.org>;
> > <roygr...@gandanet.com.hk>
> --http://seabirdskitchen.blogspot.com
http://www.lithandbook.com/?p=33#comment-68
In addressing complexity it seems to me that the 'cut' or partitioning
can be made along different dimensions, function being one of them or
by clustering of various dimenisons into cohesive elements.
To explain what I mean, in information engineering there is the
established approach of clustering based on examining the relationship
between function and data. This provides a very logical partitioning
(and from what I've read of SIP it extends this type of approach in a
more rigorous way), however it doesn't always relate to the real world
and the politics of information.
This is where I think the VPEC-T dimensions can help us understand the
difference between this logical partitioning and the complexity we
observe in the real world (i.e. overlay the effects of V,P and T on
the clustering of E and C), and help us get to the critical space
between partitions.
On Oct 31, 10:37 am, "nigel green" <nigelpsgr...@googlemail.com>
wrote:
> ---------- Forwarded message ----------
> From: Sally Bean <sa...@sallybean.com>
> Date: Fri, Oct 31, 2008 at 9:11 AM
> Subject: RE: From Chris Bird a Brit-EA living in Texas..
> To: ro...@objectwatch.com, ch...@thenetworkeffect.net, John F Schlesinger <
> jschlesin...@computer.org>, nigel green <nigelpsgr...@googlemail.com>,
> Charles Edwards <charles.edwa...@processwave.com>, Roy Grubb <
> roygr...@gandanet.com.hk>
>
> True, Roger.
> There is 'soft' complexity, that arises from multiple stakeholders having
> different backgrounds, values and viewpoints, and 'hard' complexity that
> comes from large size and multiple interconnections.
>
> For those familiar with Dave Snowden's Cynefin model, soft complexity is
> the upper left quadrant (COMPLEX: invisible, un-ordered, unable to predict
> cause and effect), and hard complexity is the upper right quadrant
> (COMPLICATED: invisible, ordered, able to predict cause and effect given the
> right assumptions and information)
> This link takes you to his original paper, though he's tweaked the
> terminology since thenhttp://cognitive-edge.com/articledetails.php?articleid=14
> From: Sally Bean <sa...@sallybean.com>
> Date: Fri, Oct 31, 2008 at 9:11 AM
> Subject: RE: From Chris Bird a Brit-EA living in Texas..
> To: ro...@objectwatch.com, ch...@thenetworkeffect.net, John F Schlesinger <
> jschlesin...@computer.org>, nigel green <nigelpsgr...@googlemail.com>,
> Charles Edwards <charles.edwa...@processwave.com>, Roy Grubb <
> roygr...@gandanet.com.hk>
>
> True, Roger.
> There is 'soft' complexity, that arises from multiple stakeholders having
> different backgrounds, values and viewpoints, and 'hard' complexity that
> comes from large size and multiple interconnections.
>
> For those familiar with Dave Snowden's Cynefin model, soft complexity is
> the upper left quadrant (COMPLEX: invisible, un-ordered, unable to predict
> cause and effect), and hard complexity is the upper right quadrant
> (COMPLICATED: invisible, ordered, able to predict cause and effect given the
> right assumptions and information)
> This link takes you to his original paper, though he's tweaked the
> > To: Charles Edwards <charles.edwa...@processwave.com>; Roy Grubb
> > <roygr...@gandanet.com.hk>; Sally Bean <sa...@sallybean.com>;
> > ro...@objectwatch.com; John Schlesinger <jschlesin...@computer.org>;
Reply all
Reply to author
Forward
0 new messages