Author: Carla D. Kendrick, PhD

Simply stated, a “value proposition” is why a customer will choose one company’s product over another if it satisfies a need or solves a problem. For an EA Practitioner, it is the reason “why” decision makers or stakeholders use EA to solve problems, answer questions or resolve needs. Each value proposition (EA use) consists of a selected group of products that are developed or derived from architecture data, based upon desired outcomes and known business requirements. Business requirements describe the business needs of the organization or customer. Overarching business requirements are derived from the business strategy and are needed to drive the overall EA effort. It may be helpful for stakeholders to document business requirements in the form of use cases. Ideally, business requirements and outcomes are captured during the EA planning phase.

The measure of success for EA is the extent to which the EA has contributed to achieving those outcomes. The expected value of the EA and the business outcomes supported should be established and communicated to stakeholders early in the EA lifecycle. Communicating the purpose and value of EA is a basic concept, but oftentimes overlooked. It is not a “one and done” activity and there should be no fear of over communicating. If not consistently informed, different stakeholders that are engaged throughout the EA effort can easily have different expectations of the EA value proposition. Another key step in defining value is to establish an approach that measures architecture’s worth based upon the EA intended purpose and strategic goals. An integral part of this approach is identifying the data, and the means for collecting and reporting that data which measures architecture outcomes and benefits. The collected metrics data assists validation of the value proposition and is a mechanism for determining architecture product improvements.

There are many artifacts that may be developed and/or customized as part of the “selected group of products” for the value proposition. For example, a Business Architecture provides information on the business activities and processes for an organization. Other examples are:

• Information Architecture – describes the organization’s data and data assets.
• Reference or Segment Architecture – provides standardization/documentation for a capability.
• Solution or Application Architecture – provides information on the applications and systems within an organization.
• Technology Architecture – describes the technology infrastructure of an organization.

Regardless of the architecture/architecture data produced, the end state is to ensure that the data necessary for decision makers or stakeholders to solve problem(s), answer question(s) or resolve needs is accessible and understandable. The value proposition then becomes an EA success story that should be communicated to the organization.

References

1. Bernard, Scott A. (2012). An Introduction to Enterprise Architecture, third edition (international). Bloomington, IN: AuthorHouse.
2. Minoli, D. (2008). Enterprise Architecture A to Z. Boca Raton, FL: Auerbach Publications.
3. Osterwalder, A. and Pigneur, Y. (2010). Business Model Generation. Hoboken, NJ: Wiley & Sons, Inc.
4. North, W., North, J., Benade, S., (2004) Information Management and Enterprise Architecture Planning, Problems and Perspectives in Management.
5. U.S. Government Accountability Office (2012). Organizational Transformation: Enterprise Architecture Value Needs to Be Measured and Reported. GAO-12-791.