At my new client this past week, I faced a familiar question: What’s the right level of complexity? I had also been thinking about this question when reviewing the MIKE 2.0 Data Migration Complexity Estimating Model.
Now, there’s no one right answer to this question. Suffice it to say that it’s an interesting topic that I’ve addressed before while writing for my own site and others.
What is an Appropriate Level of Complexity?
Opinions vary on what constitutes an “appropriate” level of complexity for software applications and system architectures. In Software Testing Techniques, Boris Beizer writes that “software complexity (and therefore that of bugs) grows to the limits of our ability to manage that complexity.” In other words, a bare bones IT staff of two people will probably keep things simple for one reason: they don’t have the time and resources to manage anything else.
For his part, Mike Rosen of Cutter has written extensively about how many organizations’ efforts to implement new technologies never stand a chance:
Perhaps nothing is more drawn out and aggravating for an IT organization than what I call “death by architecture.” The story goes like this: the high priests and architects depart for the ivory tower and return some months or years later with “The Revealed Truth,” in the form of 1,000 pages of architecture documents. In the meantime, new applications have been developed, requirements have changed, and the architecture is out of date on delivery. Other reasons may also contribute to its being DOA: It may be irrelevant to the development organization or might not have enough buy-in to be accepted. It may be hard to understand its value or how it achieves business goals, or dozens of other reasons.
Does this sound familiar?
While no organization should build an albatross, what’s “simple and easily maintained” to one company may be unwieldy to another. I know of one organization that has customized its enterprise systems so much that it actually calls the vendor to tell them which line of code to change for future patches! Is this typical? Of course not. However, this organization has ten FT employees supporting its customized apps, aside from functional end users. Obviously, this is a far cry from a small IT staff supporting a ‘vanilla’ installation of an enterprise system.
8 Rules for Managing Complexity
Here are eight general rules for managing complexity:
- Even a moderately complex setup is bound to fail if the organization does not have sufficient human bandwidth to support it.
- More complex systems require more people (employees or consultants).
- Some people are better able to handle complexity than others.
- More complex systems, applications, and integration points and procedures make it harder for others to enter the organization and “hit the ground running.”
- Even with backup documentation, a key employee departure could sting an organization with an overly complex array of technologies.
- Don’t be afraid to challenge business end users who unknowingly insist upon doing things in an unnecessarily complicated way.
- If at all possible, err on the side of simplicity.
- Complexity increases the chance of mistakes and, as Michael Sinz once said, “Programming is like sex: one mistake and you have to support it for the rest of your life.”
Let’s face it. What a wonderful world it would be if we could just click a few buttons and our applications would work in perfect synchronicity. Maybe we’ll get there one day and there will be tight and easy integration among our enterprise applications. I just don’t expect that to be soon.
Feedback
What do you think? How do you ensure that your organization’s or clients’ systems are not “too complex”?
