Charles Giancarlo and Steve Mills are on a panel with two Gartner officers. Giancarlo defines “complexity” as anything that causes customers headaches in implementation. Customers want simplicity, by which they mean that solutions are thoroughly tested for their environment, not fewer features. He points out that we simplify the mundane (networking protocols) and then build greater complexity atop the newly simplified stack. He also correctly points out that the desire for differentiation is a big source of complexity.
Mills says that complexity in software is a reflection of the desire for more autonomy from central IT control, and stems in some respect from the decentralization of IT infrastructure starting with the shift to minicomputers in the 1970s. He also says that software will continue to get more complex: “software developers, given enough resources in time, will reinvent the work of everyone who’s come before them.” He suggests that encouraging reuse and adoption of open source can help to simplify the stack by not encouraging the development of new code, and that bloat is primarily caused by a cultural issue among software programmers. Giancarlo agrees: if improvement in software code doesn’t directly drive customer benefit, then it isn’t worth doing.
Mills says that defeating the developer’s cultural tendency toward re-creating the wheel requires: time-boxing, or defining short-term incremental projects; starving the team for resources; and embracing user-centered design.
(My battery is dying; more to come.)
Later: In discussing how to improve reliability in the face of proliferating software versions, Mills talked about reducing redundancy in code and reproducing known configurations and feature paths in the test environment. Giancarlo talked about lessons learned from integrating Linksys’s consumer business in creating a balance between complexity and functionality.
Causes: infrastructure is cumulative (earlier today someone said applications never die; the consensus appears to be that retiring outdated IT offerings is almost impossible). One thing that might help is, following Drucker, to continue to push good ideas down into silicon so that they move lower in the stack. Unfortunately, says Giancarlo, complexity grows organically: today’s skunkworks project is tomorrow’s killer competitive advantage, so it adds to the complexity. The wrong thing to do is to try to remove complexity from new products; rather, look at them when they provide comparatively less value and try to remove complexity then. Also, the multiplicity of architectures can be a political issue.
Why to reduce complexity through SOA: Mills: money is lost in the cracks between all the handoffs between different legacy systems. You need to add some IT complexity in end-to-end monitoring to enable the business to reclaim the money lost in its patchwork of pre-SOA systems. Governance is one of the most important solutions for reducing complexity.