Transforming the Business of Development
Big Process, Small Process
Most enterprise developments have a 'big process'
that makes it difficult to deliver business value. This section describes - in broad brush strokes -
why today's software technology makes the big process necessary and its problems.
The next section shows how JeeWiz adds value by using a 'small process'.
The big process mentality is driven by the realities of big development projects. The logic goes something like this:
This leads to the disadvantages of big process as seen by the business 'buyers':
- It is difficult to convert requirements into working systems - i.e. to do the development phase.
- Because we are going to invest a lot in the development stage,
we must fix the requirements, and then the architecture.
- The business will constantly try to change the requirements,
but we must stop them doing that - it just derails the project.
Note that the current panacea - offshoring - does not really change the logic here.
It may cut the cost somewhat, but it will increase the other problems.
- Because the requirements are set in stone, business buyers have to guess to a large extent.
As they're guessing and changes are difficult, they tend to over-specify - just in case.
- When the developers are in their cave, they don't like to talk a lot, so it's difficult for business buyers to know
what's happening, or to control aspects of the development.
- Big development means big timescales and big costs.
- When a real user works with the software,
there are usually big opportunities for improvement, but changes in the requirements before deployment
means big cost increases and is usually resisted vigorously - "don't even think about it".
- For big projects, the length of time from first idea to deployment means that
the original need has probably changed or gone away -
so the business user will ask do we still need it?
JeeWiz and Small Process
The key to changing this state of affairs is to make it possible to get early feedback from users.
This is the big idea behind 'agile development'.
Whereas agile development advocates a process and a mindset,
JeeWiz provides a tool to support it.
The key to this is building and changing an application that a real user can work with as fast as possible.
As indicated by the timescale examples on the diagrams, JeeWiz enables users to work with early applications in days and weeks, rather than months or years.
This is because business users can model the user interface at a high level, and incompletely and have the rest of the application -
persistence, mid-tier objects - generated immediately.
This leads to the "small process":
This approach removes the main disadvantages of 'big process': it removes the guesswork, reduces cost and timescales,
keeps business users in touch and in control, and constantly adds value by refining the specification.
- Requirements are not set in stone at any point: they can constantly evolve.
In fact, the more the requirements are refined by users working with a real system, the more value is added.
- Because JeeWiz can generate so much of a system from the model,
it is possible to do the first few iterations without any of the other development steps at all.
Only when the system looks useful enough to go live do we need to add the 'custom logic' -
the business logic that isn't covered by JeeWiz patterns.
- It then makes sense to do the first live version of the system without doing
any work on the architecture or attaching to the company infrastructure!
This is only possible because
As architecture adds no business value, it makes sense to delay this cost as long as possible -
ideally until after the system has been used live in a trial.
- JeeWiz includes a standard architecture for web-based applications,
which can be deployed at a departmental level without additional work or cost
- the architecture is separated out from the
model-driven application and the custom business logic.