Recently, Twitter #entarch has erupted in the recurring discussion about the value of enterprise architecture. I say ‘recurring’ because illustrating value is a constant challenge for IT and especially for EA practitioners. This particular Twitter value discussion falls mainly into two piles:
- Value theory
- Value realities
Value theorists describe how value “should” work in an organization. Theory would be enough if humans were rational beings. But, like the many studies related to behavioral economics have shown, humans do not always act rationally. So the biggest problem with the rational models discussed by value theorists is that it leaves out the human dimension. Yet it is the human dimension that makes the application of the theory less prescriptive and much more subjective and situational. This is best illustrated by asking how to apply the theory. The response to “how?” is predictably followed by the statement “It depends”.
The value realities camp (myself included) does not sanitize the value discussion by eliminating the human dimension. The fundamental difference being that to those who are more interested in getting things done, value perception is top of mind (how do you demonstrate value?). Getting things done lives and dies by identifying value expectations and understanding value perception. The value reality camp knows this because they have the war wounds from trying to make things happen in an organization. When you have been responsible for implementation and have lived (and fried) by value perception, it gives you a perspective that book smarts cannot fill. There is a big difference between discussing value and the generation of value. As a result, a discussion about value realities leads to a discussion of expectations, applied action, and perceptions.
Value management models are useful, but value itself is related to human perception. Value is ambiguous until defined (remember the eye of the beholder?). Defining value does not mean creating a textbook definition, but working with the humans in your organization to understand what will generate value for the organization and to understand what each person will consider a valuable outcome. If you apply “book smarts” to what people consider valuable, then you generate value. You can’t ignore the human dimension of value; it is the yardstick determining success.
This applies directly to enterprise architecture value. Most people who are not EA practitioners do not care about EA theory. They care about the results from applying EA. Sure, EA theory, like other theoretical input, provides valuable ideas for someone in EA role, but for the rest of the organization, the outcome from applying “book smarts” is the source of value. For EA practitioners this means:
- Learn to describe architecture’s business contribution and value without using EA’s secret language.
- Deliberately avoid a highly theoretical approach to EA in favor of helping produce results.
- Describe what you can do to help versus describing EA.
- Help the broader audience of business and technology professionals use the knowledge of dependencies, implications, and constraints to improve their results.
An EA practitioner may care about the theory, but when it comes to generating value it is important to be a value realist.
View Free, Relevant Gartner Research
Gartner's research helps you cut through the complexity and deliver the knowledge you need to make the right decisions quickly, and with confidence.Read Free Gartner Research
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.