Enterprise Software is Complex; Starting Right Makes It Simpler

Complexity is a fact of life. Many aspects of our daily lives are complex from personal relationships to tax documents to software projects — they all present us with challenges we’d probably rather avoid. I can’t help with relationships or taxes but I can shed some light on making software projects simpler.

My focus is enterprise software not small desktop applications to be used by a small workgroup. I readily agree that small software apps can be built quickly with minimal overhead and deliver lots of functionality. I’ve written them myself — low risk, little cost, limited feature set — simple.

Enterprise software is a brave new world — many risks, substantial costs, diverse feature sets — complex. A complex project needs complex management and control structures — or not.

Projects start out simply and grow in complexity.

Many software projects are conceived from a simple problem statement. For example, “as a purchasing agent, I need a software application to manage my purchase orders”. This appears to be a simple, reasonable request — until you think it through. You quickly realize that “manage” implies some or all of the following:

  • create, read, edit, cancel POs;
  • find, sort, copy POs;
  • email, print, report POs;
  • approve, reject, hold, release POs;
  • blacklist vendors (block POs to problem vendors), whitelist vendors (direct POs to preferred vendors);
  • allow/restrict access to the system or data elements within it based on user privileges.

Is your head spinning yet?

There are no simple requests when it comes to enterprise software development. But that doesn’t mean the process used to build or customize the software needs to be complex. I think we often create more complexity in the management process than is needed because we fail to do a few simple things up front.

The less you prepare before the project starts, the more management discipline and structure you will need to keep the project on track. Start off right by doing the following:

  1. Create a vision for the solution. (This is a Vision Statement.) What problem is being solved? Who are the key stakeholders? Who are the ‘primary’ users of the software? What will they do with it? What is most important to them? What does the deployment environment look like? What risks await?
  2. Prioritize the major feature sets. (Epics are a great informal way to do this; use cases are a more formal approach.) In the first (or next) enterprise deployment, what must the software do? What else can be included, if and only if, time allows?
  3. Define the critical non-functional requirements. Performance, reliability, ease-of-use, visual appeal, regulatory compliance, etc. Resist the urge to pile on every “…ility” you can think of like maintainability, upgradability, recoverability, etc. Too vague.
  4. Allocate time, money, people, space and equipment. Get management to acknowledge that as they apply constraints to these items, the solution will also be increasingly constrained.
  5. Pick any software development approach you like as long as it involves incremental deliveries of ever-increasing functionality. Shorter increments are better. Actively engaged stakeholders and end users are a must. Most importantly — assemble a strong development team and keep them focused.

Software development is not going to get simpler anytime soon but don’t make it more complex than it already is. Be agile!

Updated: July 7, 2011 — 10:07 pm