VPEC-T analysis (value, policies, events, content and trust) is a thinking framework comprising a collection of mental filters or guides. It provides a "simplified 'language' for preventing loss in translation from business needs to IT solutions" [1] and is used when analyzing the expectations of multiple parties having different views of a system in which they all have an interest in common, but have different priorities and different responsibilities. System, here is used in the broad sense of a set of interacting or interdependent entities, real or abstract, forming an integrated whole. It is applied to 'systems' that range from those as small as a performance appraisal,[2] to ones as large as a criminal justice system.

VPEC-T ("vee-pec-tee") is used where interaction between agents and communication between parties can easily result in ambiguity. This form of analysis is particularly applicable where it is likely that the interaction and communication context is unordered, complex or chaotic, and liable to result in misunderstanding. It is identified as a new way of carrying out enterprise architecture,[3] and also identified as a way to design services.[4]

VPEC-T was first conceived as a framework to aid those studying information systems, where the conflicting viewpoints of the parties involved could be a barrier to proper understanding. Examples of such situations are frequently found at the business/information technology (I.T.) divide.[5] Since the 1990s, I.T. has stolen the place of Information Systems but I.S. and I.T. are not the same. I.T. is about computers and programs. I.S. encompasses everything that will surround I.T. for the tasks to be properly completed - people, processes and information.[6]

The principles on which VPEC-T is founded

VPEC-T is named after the initial letters of the five elements on which it focuses: value, policies, events, content and trust. These elements are present in all information systems and most will be present in some form even in simpler communications.

Each of the parties involved in describing, discussing or seeking to understand a system, actual or planned, will view it in the conceptual framework with which they are familiar. Each party will usually have a different view of the values of the system; their knowledge of the policies embodied in it will vary according to their responsibilities; they may know of only a subset of the events handled by the system; and they are unlikely to know of all content required, as content will not always be formal and recognized. Finally, there is the important question of trust that the parties have for one another, and trust that the system will meet its expected outcomes. A lack of trust between the parties can affect the success of the system in cases where information is not revealed, commitment to using the system is not whole-hearted or maintaining 'shadow systems'.[5]

For example, where the analysis in question is a preliminary step in understanding an information system, the parties involved will include both the business and the Information Technology (IT) functions of an organization.

Of necessity the language of business users of an information system embraces ambiguity, tacit knowledge and willingness to change: Business must operate in the environment of a constantly changing market. Of necessity the language of the IT function embraces high specification, certainty and avoidance of change: The IT function must minimize change to systems that require cost, time and risk to implement.[5]

The different conceptual frameworks and associated language of these two groups can cause difficulties in unambiguous communication. This will likely surface as conflict at some time during an information system's life cycle.

It has been described as "based on a profoundly radical philosophy of plurality"[7] being of value "where expect to find a range of different (overlapping, conflicting) value systems. Instead of a single coherent set of policies, we expect to find complex interaction between different kinds of policies (commercial, security, safety, corporate responsibility, and so on)."

VPEC-T components

The terms values, policy, events, content and trust are the principal means through which communication concerning a topic is viewed. Ensuring that these dimensions are all considered, while avoiding technological issues at an early stage helps to create a balanced and complete view of the system.[5]

Values

The Value filter helps in understanding the value of the desired outcomes to both the individual and the business. While the value of a system to a business is commonly thought of in terms of profit and income, market share and cash flow, Values in VPEC-T extends this to include meeting ethical constraints and other types of goals such as environmental concerns, as well as considering personal values of parties involved as well as employee satisfaction and retention.[5]

Values constitute the objectives, beliefs and concerns of all parties participating. They may be financial, social, tangible and intangible.

Examples of values include faster turnaround of orders, more reliable handling of complaints, reduced costs, and the full range of benefits normally claimed for information systems. VPEC-T seeks further and deeper meanings of value. For example, a VPEC-T study might conclude that one value of a system is to move control of a business area from one part of the organization to another, or to gain experience in a new and growing field of enterprise that might affect the business concerned at a later date.

Policies

Policies are mandates and agreements, including internal policies, legal requirements, commercial contracts and other constraints that govern what may be done and the manner in which it may be done. Policies may be internal or external, explicit or implicit.

One of the tasks of VPEC-T analysis is to bring implicit policies to the surface for consideration.[5]

Examples of policies would be limits on credit allowance, limits on value of order based on given criteria, constraints on the use of personal information, 'know the customer' regulations for financial institutions, export controls, and weight limits for packages. VPEC-T goes beyond this by pushing on into policies that may be unwritten, and are implied in departmental customs ("we defer processing of orders for perishable items received after 14:00 on Friday until Monday morning, and then they have priority") and other informal agreements or instructions.

Events

In the context of information systems, Events would be business-relevant occurrences. They are real-world proceedings that stimulate activity.[5]

Examples of events are the receipt of a purchase order, a phone call or email querying a delivery, a customer signing off on completion of the receipt of a service, or the oral or written authorization of a transaction.

Content

Content is the meaningful portion of the documents, conversations, messages, etc. that are produced and used by all aspects of business activity. Content is the means by which plans, actions, previous references, etc. are used to determine decisions.[5]

Content in VPEC-T explicitly encompasses a broader spectrum of communication than is generally classified as "data" in computer-based systems, though business data is certainly included as well.

Content may include:

  • Information that is a pre-requisite for the occurrence of an event.
  • Information that is required, processed and acted on by actions resulting from an event.
  • Information that is spawned from an event occurrence.

Examples would be phone calls to check a credit history, emails about usual delivery patterns and the content of stores requisitions and purchase orders.

Trust

Studies of and design for information systems will often include consideration of trust between users of the system and their right to access and change information within it. This aspect of trust should be covered by Policies of the organization operating the system or providing the service on which it runs.[5]

Trust in VPEC-T is concerned with the trusting (or otherwise) relationship between all parties engaged in a value system where Trust will be based on intimacy of the parties, one party's credibility in the eyes of another, and the risks involved. Trust values change with time and circumstances.

Examples might be the discovery that a Purchasing Officer maintained parallel records in a spreadsheet, or the realization that a member of the project team had an agenda relating more to the authority of a particular business unit than to the improvement of information available to the business.

Use

A visual guide to enablers, roadblocks and applicable areas, produced by one of the originators of VPEC-T.

These five filters are applied continuously during the early stages of considering an information system. As the analyst increasingly comprehends the actual situation, the new findings will again be viewed through the five filters.

VPEC-T has also been recommended as a technique for business-architecture assessment in development of enterprise architectures. T. Graves in The Service-Oriented Enterprise p. 96 proposes: "Use values-mapping and requirements-modelling techniques to identify enterprise values and their commonalities and conflicts. Document the results in the 'universals' part of the framework. Techniques such as VPEC-T, SCORE and even classic SWOT analysis will be helpful in identifying the impacts of any values-conflicts."[8]

Graves also cites his use of VPEC-T in Doing Enterprise Architecture p. 152 where he says "For this work, the practice will always be iterative ..."[9]

VPEC-T is used not only for information systems, but also in mediation, communication and group interaction.

History

According to Claudio Ciborra[10] among others, Information Systems failures are mostly caused by the inability of our current methods to identify and analyse the complex Social-Technical issues that have to be addressed in order to be successful.

In a session at Enterprise Architecture Conference Europe 2009, David Hunt, Senior Lecturer, & Liz Bacon, Head of Computing and Mathematical Sciences, University of Greenwich looked at how VPEC-T has been successfully used on a number of substantial real life projects to overcome some of the issues identified above.[11] In particular they addressed:

  • How VPEC-T promotes a behaviourcentric view of EA and the benefits this can bring to both the technology delivery and governance of an Enterprise Architecture;
  • how this can be used to deliver a pragmatic approach to EA, delivering early business benefit;
  • the current limits of the approach and pointed to future directions of work that will further enhance the delivery of Information Systems and Information Systems Strategy.

VPEC-T was created by Nigel Green and Carl Bate, who developed it and used it in its first major projects while working at Capgemini. Originally developed for use in enterprise and solution architecture engagements concerning information systems VPEC-T is now also used in other domains and contexts not associated with computing.

Some examples of use are:

  • The pre-design stage preparations for a new Criminal Justice Information System in the United Kingdom;
  • preparation for staff-appraisal interviews;
  • establishing the business requirements of an affiliate selling system from the separate points of view of all parties involved;
  • resolution of structural problems in a company with several groups performing similar business functions but with different policies on charging for their services;
  • development of business goal and adoption oriented Enterprise Architecture principles (applied in Financial Services, Transportation and Government sectors);
  • development of event-based, Information Systems architectures centered around business behaviour (rather than technology);
  • testing the likely success of options to change a business and overturning bad decisions as a result;
  • assessing the current state of consulting engagements and planning next steps.

VIPER

In late 2019, an improvement to the acronym was introduced by Nigel Green and Matt Pearce after many sessions with business clients. The new acronym, VIPER, stands for: values, information*, policies, events, and reliance*. Information has the same meaning as Content, as does Reliance and Trust. Although these improvements do not change any of the core framework, it is easier to memorize and more accurately describes the original concept.[12]

See also

References

  1. ↑ Gøtze, John (3 April 2009). "Review of Lost in Translation". Retrieved 13 September 2009.
  2. ↑ Jangbrand, Anders (23 April 2009). "VPEC-T when preparing Feedback". Retrieved 19 September 2009.
  3. ↑ Green, Nigel. "Two Phrases You Wouldn't Expect to See Together: Reduced Complexity & Enterprise 2.0". Archived from the original on 20 September 2008. Retrieved 14 September 2009.
  4. ↑ Mulholland, Andy. "Building 'Services' etc to Enterprise Quality". Archived from the original on 11 January 2009. Retrieved 14 September 2009.
  5. 1 2 3 4 5 6 7 8 9 Nigel Green, Carl Bate, (2007) Lost in Translation: A handbook for information systems in the 21st century. (Evolved Technologist Press) ISBN 0-9789218-4-4
  6. ↑ Hidas, Peter (14 April 2009). "Folk forstår ikke it-språket". Computerworld Norway (in Norwegian). Retrieved 14 September 2009.
  7. ↑ Richard Veryard Systems thinking for demanding change 11 June 2010. Retrieved 29 December 2016.
  8. ↑ Graves, Tom (December 2008). The Service-Oriented Enterprise: enterprise architecture and viable services. Tetradian Books. ISBN 9781906681166. Retrieved 18 September 2009.
  9. ↑ Graves, Tom (March 2009). Doing Enterprise Architecture: process and practice in the real enterprise. Tetradian Books. ISBN 9781906681180. Retrieved 18 September 2009.
  10. ↑ Ciborra, Claudio; Rob Kling; Leigh Star; et al. (May 1997). "Human Centered Systems in the Perspective of Organizational and Social Informatics". Human centered systems, for the National Science Foundation. Rob Kling Center for Social Informatics Indiana University). Retrieved 26 May 2010.
  11. ↑ Hunt, David; Bacon, Liz (8 June 2009). "VPEC-T: A Way to Bridge the Gap Between Business and IT" (PDF). Enterprise Architecture Conference Europe 2009. Retrieved 14 September 2009.
  12. ↑ Green, Nigel (23 August 2020). "VIPER - Getting Started". adaptivechangedesign. Retrieved 29 December 2022.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.