Cake Solutions Limited

Architecture

Cake strongly believes the architecture and planning of an enterprise level application will normally take between 30 to 40% of the project time. This allows for for plenty of innovation/thinking time to look at possible technologies and how they are best combined. It also allows for some prototyping for any complex areas of the system to ensure the final architecture is feasible and will exceed the clients expectations in terms of performance, stability, code quality and system understanding.

Why do you need good architecture?

The system’s architecture dictates its flexibility, performance and manageability. There are two main approaches to system architecture.
The first approach calls for extensive planning and trying to design a system to be as flexible as possible. In other words, it means trying to consider and program for every possible change that the customers may request.
The second approach is to design a system so that the impact of any change is as small as possible. The trick is to design the software to minimise the dependencies between its components.

How does it look like?

The system’s architecture outlines the high-level components of the system. These components are RDBMSs, application servers, clients and web servers. We call this the logical system setup.
The architecture must also outline the physical system setup: even the programmers have to live in real world and real world computers simply do not have unlimited processing power and unlimited memory. The components of a complex applications sometimes need to be load-balanced. Load-balancing allows you to improve the performance of your system simply by throwing more hardware at it — crude, but inexpensive solution!

Let’s take a look at an example diagrams that outline the system’s architecture.

Logical architecture

Core code architecture

Let’s now take a look at some of the concepts of system architecture that will ensure that your software is easy to improve or change.

Loose coupling

In the first paragraph, we have discussed the advantages of loosely system design. The Spring Framework in our Java EE applications encourages loose coupling by externalising the component’s configuration — in English, this means that we create components in software and then write small configuration files that tell the Spring Framework how these components fit together.

Let’s illustrate this approach in building a car: it is a loosely coupled system, because no car part knows exactly what other parts it interacts with. Take the engine and transmission. The transmission “knows” that there is some kind of engine, but it does not dictate the specific type of engine. Similarly, the engine does not need the transmission at all to function. This allows the car manufacturer to offer many different types of engines and transmissions easily — without changing the design of the car.

Designing and implementing loosely coupled system takes a lot of experience and discipline, but sometimes this may not be enough on its own. We use a number of automated tools that will highlight any coupling problems in our software. Structure 101:http://www.headwaysoftware.com/products/structure101/index.php is an excellent tool that can show us how tangled our software is.

Overall application structure showing one (intentional) tangle

Clean structure of a sub-package

Other aspects of system architecture

We always try to make sure that our code is of the highest standard and as loosely coupled as possible. However, some Java EE application servers do not allow us to take this modularity to the production environment.
In short, most Java EE application servers force us to create a monolithic archive of the system’s modules. This means that at runtime, the modularity is lost.

But there is hope: the SpringSource dm Server. It is an OSGi-based Java EE application server. The dm Server allows us to keep the system modular even at runtime. The result is a more flexible and manageable system.

At the end of the architecture phase of the project Cake will deliver an architecture document and project/feature time line.

Blogs