At my workplace’s Book Club, while reading the TOGAF book (The Open Group, 2014) one of my colleagues sent me this very nice picture regarding the reviewing chapter for that week:
The phrase is mentioned under the Approach subtitle of Chapter 16 (Phase H: Architecture Change Management), which specifies the following objectives for the mentioned facet:
- Ensure that the architecture lifecycle is maintained
- Ensure that the Architecture Governance Framework is executed
- Ensure that the enterprise Architecture Capability meets current requirements
“In Phase H it is critical that the governance body establish criteria to judge whether a Change Request warrants just an architecture update or whether it warrants starting a new cycle of the Architecture Development Method (ADM). It is especially important to avoid “creeping elegance”, and the governance body must continue to look for changes that relate directly to business value.” (The Open Group, 2014).
Consulting to my best friend Google, I have found this definition: “In software development, creeping elegance, related to creeping featurism and second-system effect, is the tendency of programmers to disproportionately emphasize elegance in software at the expense of other requirements such as functionality, shipping schedule, and usability.
Creeping elegance is also forced by customers and sales personnel in the last stages of software development. Often one comes up with “just another feature” before the delivery date, and the software developer is left with the hopeless case of prioritizing between delivery on time according to schedule or to fully satisfy customers and/or sales department.” (Wikipedia, 2011).
The application of good governance based on (TOGAF, n.d.):
- Discipline: adhere to procedures, processes and authority.
- Transparency: availability for inspections by authorized parties.
- Independence: avoid conflict of interests.
- Accountability: actions and decisions must be accountable.
- Responsibility: acting responsible toward the organization and stakeholders.
- Fairness: do not create advantages for any party involved.
Will avoid this kind of issues and will help to keep the focus on the value added to the business, because Enterprise Architecture does not operate in a vacuum.
References
Ross, J. W., Weill, P., & Robertson, D. S. (2006). Enterprise Architecture as Strategy. Boston: Harvard Business Review Press.
The Open Group. (2014). TOGAF Version 9.1. Van Haren Publishing.
TOGAF. (n.d.). Architecture Governance. Retrieved from Open Group: http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap26.html
Wierda, G. (2015). Chess and the art of Enterprise Architecture. R & A.
Wikipedia. (2011, February). Creeping_elegance. Retrieved from Wikipedia: https://en.wikipedia.org/wiki/Creeping_elegance
Woodworth, P. A. (2013). A Reference Architecture for Enterprise Architecture. Kindle Edition.
Jorge Luis Rodriguez Blog 
Thanks for a great, new phrase; “creeping elegance” is one that I’ll be using in the future. I really think this is something that afflicts IT professionals, especially software developers, who try too hard to anticipate the future and build for it today without knowing if value will ever be realized. I think the antidote is simply wisdom and experience. A wise colleague, who was also the lead enterprise architect, would frequently say “no solution before its time” every time he was approached with something that “might” be valuable someday in the future. If there was no clear and legitimate path to value, then he would simply say “no solution before its time”. It’s a great philosophy to carry forward, into the realm of Enterprise Architecture. Thanks, Scott.
LikeLike