VPEC-T was originally conceived as a tool to help business analysis
and to help with traceability into design and further still, to
operation. The P-E-C part came about first as a Design Pattern based
around federated information systems - Trading Partners in a Supply
Chain for example. It emerged from the design of a asynchronous
message-based parcel tracking solution and associated pub/sub pattern
we developed back in the '90s. I became fascinated by the difference
in thinking required to design and deploy such a solution compared to
more database-centric applications that were more popular at the time.
So, P-E-C has clear connections to design and this shows through in
the way that folk like Chris Bird and John Schelsinger are using VPEC-
T.
The V and T parts were added when we Carl and I were working with the
CJS. We found they complemented the P-E-C part by highlighting aspects
that were often missed in business analysis. But we also found they
play into the solution - hence we talk about the concept of Adoption
Engineering which talks about the notion of 'Designing-in' 'V and T'.
This includes building trust through incrementalism and designing to
directly support different 'Value Systems' (e.g. different views and
attractors). This approach aligns with a Cynefin Complex-Adaptive
style of design and development, which also aligns with Agile software
development methods.
In summary, I find VPEC-T works best when it spans analysis and
design. I describe the solution I develop using the VPEC-T lens. To
get another PoV on this, Dave Hunt and John Schlesinger have
experience of joining-up analysis and design using VPEC-T - can I
suggest you contact them directly Richard?
Nigel.