- log in
Posted by Jost Hoppermann on April 15, 2010
Recently, I discussed complexity with a banker working on measuring and managing complexity in a North American bank. His approach is very interesting: He found a way to operationalize complexity measurement and thus to provide concrete data to manage it. While I’m not in a position to disclose any more details, we also talked about the nature of complexity. In absence of any other definition of complexity, I offered a draft definition which I have assembled over time based on a number of “official” definitions. Complexity is the condition of:
- Having many interrelated and interdependent entities (such as employees, customers, partners, organization units, IT systems) . . .
- . . . in a given system (such as a branch, a business division, the entire bank OR an IT system OR the entire application landscape — as well as numerous combinations) . . .
- . . . connected via many interconnections (such as business processes, informal communication, application integration, workflow between apps).
The level of complexity is associated with the number of entities and interconnections in a given system as well as the effect of the entities on the system.
Please note that entities and systems are not necessarily distinct. For example, a “business division” may be a system for divisional functions and could be a (complex) entity within the system “bank.” Consequently, a system’s level of complexity is also associated with the level of complexity of each of the system’s entities (which may be systems by themselves).
Systems may include external entities that do not directly belong (organizationally or technology-wise) to the system. In a bank, examples are customers and partners as well as bank-external IT systems (see the figure).
- Apparent complexity: Appears to be complex but is simple “under the hood.”
- Number-driven complexity: Large numbers of different entities.
- Interconnection-driven complexity: Large numbers of possible different interconnections.
- Combined complexity: nos. 2 and 3 plus branches, feedback loops, etc.
Further differences are related to the reasons of complexity which can be can be intrinsic and artificial: The very nature of a system may make it complex — or its designers.
Let me know what you think. Is this a suitable definition of complexity — at least as a starting point — or is it completely useless in real life?
Thanks a lot for your feedback.
Search Forrester's Blogs
The dynamics that will shape the future in the age of the customer »
Planning for innovation and risk in the wake of Brexit »
Forrester's CX Index
Predict how actions to improve CX will affect revenue performance.
Measure the customer experiences that matter most »
- Anjali Yakkundi (34)
- Art Schoeller (2)
- Boris Evelson (164)
- Claire Schooley (2)
- Danielle Geoffroy (1)
- Diego Lo Giudice (24)
- Dominique Whittaker (4)
- Duncan Jones (1)
- Gene Cao (1)
- George Lawrie (19)
- Holger Kisker (38)
- Ian Jacobs (13)
- Jeffrey Hammond (31)
- Jennifer Belissent, Ph.D. (2)
- John Bruno (3)
- John R. Rymer (46)
- John Wargo (11)
- Jost Hoppermann (34)
- Kate Leggett (150)
- Kyle McNabb (12)
- Leonard Couture (1)
- Liz Herbert (3)
- Margo Visitacion (9)
- Mark Grannan (11)
- Martha Bennett (13)
- Michael Barnes (21)
- Michael Facemire (19)
- Mike Gualtieri (122)
- Nick Barber (19)
- Noel Yuhanna (10)
- Paul Hamerman (2)
- Philipp Karcher (1)
- Randy Heffner (15)
- Rowan Curran (2)
- Stephen Powers (23)
- Ted Schadler (35)