We do a bad job of building Enterprise software, primarily because we don't even know what "Enterprise" means. Today we will lay out six facets of Enterprise development. In subsequent posts we will evaluate each facet in more detail, working toward a shared notion of "Enterprise" that just might make projects more successful.
The Enterprise Hammer, Today
Hammering a few nails is a personal project. Hammering thousands of nails on the side of a building is an Enterprise challenge. Here's one solution, in six parts:
- Up-front design: Carefully map the position of the nails that need to be hammered.
- Enterprise Specification: Build a frame that matches the design
- Components: Attach special hammer adapters to the frame, at each point that a nail needs to be hammered.
- Engine: Attach the frame to an engine that can drive all the special hammers at once.
- Scalability: The engine handles a big task (hammering all the nails on one side of large building) very quickly.
- Build to Standards:You can improve quality of service by attaching a different engine. Or, you can build a different kind of building by using a different frame.
The Trouble with Components
The Enterprise Hammer I just described is J2EE:
- Hammer = Java code
- Special Hammer Adapters = EJB
- Engine = J2EE Container
- Frame = J2EE Specification
By now, the Java community has realized that this is a poor way to build software. They have focused their ire on item 3 (component models, especially EJB). I will reiterate the primary arguments against EJB very briefly here:
- The special hammer adapters are more expensive to build and maintain than plain old hammers, and offer no compensating benefit.
- The special hammer adapters are difficult to test, undermining reliability. Entire (sometimes interesting) technologies have sprung up to deal with this. I guess that's a form of peace dividend.
- Terrible performance is easily achieved.
Rather than put up with this nonsense, developers who want to get work done have built their owncontainers around Plain Old Java Objects (POJOs).
But All the Other Facets are Broken, Too!
Java developers have rejected EJB in favor of more pragmatic approaches such as Spring and Hibernate. But it is time to take the next step, and realize that the other five facets above are equally problematic, and need to be reconsidered. POJOs are not a sufficient solution to the component problem, either. So let's start over, and replace all six facets of the Enterprise Hammer with the following ideas for Enterprise development:
- The three things that distinguish real enterprise development are flexibility, adaptability, and maintainability -- not scalability!
- Standards should evolve from working code. The role of standards bodies is to filter the best and simplest.
- The transition from EJBs to POJOs is only a halfway point. We now need to leave Plain Old Static languages (POSs) behind.
- Engines should be testable and open source.
- Specifications should be flexible, and encourage developers to focus on key concerns.
- The goal of up-front design should be maximum flexibility, not complete solution of the problem.
Subsequent posts will take up each of these ideas in turn.
