Warning: Long blurb about what is in my head right now
Ok so I have been pondering the role of architecture and its
current relevance. In some organizations it is ignored in others it is a
hindrance. It is very hard to measure its impact. This is a thought that came
from that exercise.
Development should not be difficult; so keep it simple for
the majority of things and hide the complexity. One of the key things business
wants is to be more agile and get what will add business value as quick as
possible. This allows them to have a completive edge over the competition.
As for maintenance it is a hidden cost at time of
development and will cost many times more than the cost of the initial
development over time. This is kind of where my passion lies bringing down the
cost of maintenance and upping the speed of development.
One of the tools I use to address the above is Framework
based development where you don’t just provide a blueprint but a working fully
functional framework for you development team to use that provides an increase
in development speed and increased maintainability.
The responsibility for the creation of the framework once
tools have been decided falls to the team. You generally don’t have much choice
when it comes to toolset (.Net, Java, Oracle blah) so it is best to accept it
and create the best and most productive tools around the chosen technology to
make everyone’s life easier. I have never come across a tool/ product which was
so mature and such a good fit that no custom development / reporting etc was
needed. That custom development should
take the guise of a framework for want of a better word. A set of tools,
generators, standards and code that guide a developer into creating the 80% (of
the 80/20 rule) of the application and that allow development to be a simple
process.
Take note: The following points will take a decidedly Java
flavor but you can replace these ideas in any technology.
Prototype – You start out with a prototype that proves your
ideas and structure. This is a key element to any framework because it first
provides the base for what will come and addresses any technical problems. Also
it allows the team to understand and embrace any new technology.
Project structure – What does your application look like
what code is common and how is it structured. Do you have separate teams that
work on separate parts of the system? How will it be deployed? You need to
address all of these kinds of questions to get the right fit for you team and
how you work.
Standards – Naming standards and code usage patterns must
all be documented on a wiki.
Tools – What can you create to make the developers life
easier?
Build, CI, Unit tests – Imperative to set this up as part of
your framework. This will allow you to test any changes to your framework with
confidence.
Persistence, Visualization etc developer tools – Object
structure to abstract the complex repetitive code. Templates to allow
uniformity in UI, Custom tags. This is where the meat of any framework lies the
patterns an abstractions that allow for speedy development. Things like how can you have a standard interface into your model layer. How can you ensure that Bean code is generilaized enough that a developer has to do the least amount of work.
Data store – Do you check in packages and procedures and sql
stuff into version control and how is this managed.
Team structure and process – Everyone should understand the
framework and why documented in wiki and how the moving parts fit together.
Code reviews are helpfully keeping everything on the right track.
Comments
Post a Comment