Published in TDAN.com July 2003
This is a look at the technical and development challenges in architecture using the analogy of a dry stone wall rather than a building or city. I always like to see three things achieved with the
technical architecture: keeping the developers happy; meeting the current challenges the business generates; not adding blocks to the challenges the business will generate.
Are you still building a dry stone wall because the business won’t pay for everything to be ripped out and replaced? Under the current economic climate this approach is entirely
understandable but still leaves us with the need to make changes to systems. I choose a dry stone wall analogy because many older systems seem reminiscent of the dry stone walls that cover the
countryside. Each system is a carefully crafted set of code modules linked together in various ways, like stones placed carefully onto one another. It is difficult to change one module just as it
is difficult to change one stone in the middle of a wall. If you need to extend the system then it is about as difficult as adding modern bricks to an old stone wall. A lot of effort has to go in
to making the new and old compatible. But even worse, it seems that in attempting to build new systems we end up with new systems in new languages on new platforms that leave us with the same
problems when we next need to make changes. What should be done?
The first thing to do is too assess the current situation. Often a lack of detail about how the existing wall is built is the greatest issue. Only by understanding what type of
stone you have and the construction technique of the wall can you start to figure out how to change it. This parallels issues with lack of information on older systems, or even new systems. If you
want to build the wall higher or longer or add a gateway you need to understand your starting point, what materials you can use, what type of person you need to help with the work and most
importantly how long it will take and how much it cost.
The same applies to software development. We need to find an expert for the system. They know how the system works and have formed opinions on what can be done. They know how expensive changes are.
We need to assess the current techniques and vendor offerings. Don’t forget the many platforms often complicating the problem. This brings network and operational complexity. Finally (or
firstly) we also take account of the cost. Are we going to use commonly available bricks or specially made ones? It is not quite the same but we also need to factor in how often we will be tearing
down and rebuilding the wall – this will depend on the rate of change in the business.
Integrating new components into the existing architecture. Where do old and new walls meet? What skills are needed to do the work? Before we can answer these questions we should
understand what our new components look like. How do we build software bricks? I like to think of the software bricks as TARDIS bricks. They are all the same from the outside but inside can be as
big as needed. I also like to remember that when building a wall it’s easier to lift small bricks.
How can we integrate old modules with new components? Almost without doubt we will need to create interfaces between the old and the new. This is much like the cement we would add to link dry stone
and cemented brick walls.
Fortunately for us developing software, we don’t need to plan ahead as much as we would when building a wall. We can make the wall as high as we want without building any foundations. We can
lay a second wall right beside an existing wall without any affect. Our problem lies it the connection between bricks, between components. It seems much more useful to have bricks that can be used
at any stage in the wall building rather than a set of bricks for the first layer, another set of bricks for the second layer and so on. We need the same interface on every component. It would also
be nice to design an interface that lasts over time.
We also need to remember that a brick can be placed anywhere. In essence it is reusable in it’s own right. We should try to make component fulfil this as well. As far as possible component
need to be self-contained. If a component has a network of dependencies then reuse is going to be difficult and you have built a brick that only fits in one place much more like a puzzle than a
wall.
Managing the seams – interfaces are the key to success
Ultimately, to be able to use a component anywhere and to reuse it, it’s interfaces need to designed with this in mind. We should also keep in mind some general thoughts:
- How the interface performs under normal production running conditions
- How uncoupled the component is
- How we test the interface
- How we can discover the fixes for problems
These days we need to consider not only reuse on the same platform but increasingly use on multiple nodes and from different platforms and technologies.
We also need to remember that components like bricks are not one-dimensional. As well as the interface to support the business requirements we should create other component interfaces for the
non-functional requirements such as:
- systems management
- error handling
- security
- transaction control
- process or workflow interaction
- testing – it also makes sense to build testing to the same definitions.
If all of these are different then can we ever really reuse a component out of the box? By making as much as possible the same we push down the level of knowledge and experience required and push
up the productivity. By simplifying the landscape, developers have less to learn and fewer factors each time a new project is started or when they join a new team the time saved from learning and
training must be counted as productive time instead.
There are a number of standards for some for the above: SNMP or WBEM for systems management, LDAP for directory, etc. But these are not the same – each has it’s own interface. Some
progress seems to being made in the area of Web Services where some of these interfaces are being defined commonly.
Make sure you avoid the problems of the past in the solutions of the future. To build reusable components the interfaces must be correct. To reuse outside of a single system more
organisation must take place. It is often a balance between how much the architecture should be dictated and how much freedom should be left with the developers. I for one believe wider
“architecting” of interfaces would make development easier.
