Defining the architecture of an application is, by far, one of the most important tasks when working in software development, if you want to build a system that is easy to develop, maintain and should have a long lifetime. It does not really matter if you are building a system from scratch or simply adding functionality to an existing product, or if the project is small or huge.
With this understanding, we need to ask ourselves how we get to understand the architecture of an application, and how we describe it. This tends to be a rather complicated task because of how abstract most applications really are.
There are a lot of modeling techniques out there for describing a system in its different aspects and get an overall picture of how parts of an application work. UML is one of these techniques, which you can use to create different kinds of diagrams to describe a system on different levels and aspects. Then there are other types of diagrams like Entity Relationship Diagrams, Flowcharts and such that could replace or complement UML in certain areas.
In the discovery phase of our projects, we often use these kinds of tools to describe — to ourselves and clients — what we are going to build, and how it is going to work below the surface, in activity diagrams, flowcharts and different kind of structural diagrams of the data model. This really helps us breaking down complex problems into smaller, tangible pieces, which are much easier to accurately estimate. It also helps us identifying potential problems that could occur during e.g. an integration with another system or to discover things that someone has not thought about yet.
When implementing the software, because of our work breaking down the functionalities that are going to be developed, we have avoided wasting a great deal of time, since we know what we are going to do, and can just work really effectively from a list, checking one issue at a time.
These tools also become handy when implementing more complex components, since you are able to do your thinking on paper first before starting to code. This makes it much easier to test different solutions and tackle a problem on paper first, instead of being forced to rewrite large parts of the code upon discovering that you’ve thought wrong from the start.
After the implementation phase is over, the output from our workflow using these techniques is great documentation of the systems, which could be understood by any stakeholder with some technical skills.
But really, why is this stuff so important? As long as the systems work and do their jobs for the end user, does what lies behind matter? Well, its easy to think this way if you don’t have as much experience with software development, and haven’t seen how larger projects develop over time, when adding functionality piece by piece.
We can compare two projects that have the same goals, same requirements but are developed by two different companies with different kinds of people and different kinds of processes and try to get to understand the consequences of different approaches:
Project A, which has some experienced developers on board, who take a lot of time in the beginning and during the projects to investigate dependencies between the requirements, trying to create reusable, testable code, use different kinds of patterns to solve problems, use frameworks and bundle functionality into components.
Project B has less experienced developers, that don’t really care about what they are doing and simply want to make it work. They don’t invest time thinking about what they are suppose to do before they start, and just solve one issue at the time instead of looking at the bigger picture. They aren’t keen on using frameworks and writing reusable code, but instead copy and paste bits of code to patch up their solutions.
It is possible that Project B is cheaper in its initial cost. But in the long term, it will take much more effort to maintain and add new features to Project B, which means that Project B ends up at a much higher cost than Project A, simply because of how poorly it has been implemented.
When working with software projects at an enterprise level, the software’s quality becomes more critical, as development work takes longer and the delivered code is supposed to last longer, be more flexible and extensible. If it’s been poorly thought out, you’re half way to disaster.
After completing many projects over the years of various complexities, DRI’s development processes have evolved to fit all types of needs, and we always strive to get better, every day. It feels really great to be a part of this company and to work with all these skilled people.