J. on Architecture

Architects are usually bend on creating flexible and stable solutions that last. The problem is that flexibility comes at a price. Whether it’s an adapter here, or an ESB there, you will always need something extra to make an architecture flexible. But is it always necessary to add that little extra? That depends on the planning horizon of your client.

Architectures will always be realised within projects and projects need to realise the desired goal within the planning horizon. If they don’t, then the project will be a failure and that will make the architecture a failure. This is especially difficult within commercial companies where the planning horizon is getting shorter and shorter. In some companies it’s already less than a year.

But it is architecture still useful then, within these time periods? Yes, it is, because you will still need to make sure that the required qualities are met. Just make sure that you don’t introduce any new ’required’ qualities, while creating the architecture. 

Most companies, while they are different, have similar processes and ways to accomplish their goals. But when they are caught up in everyday operations, they might get the feeling that they are unique in every way and as such have unique problems to solve.
It’s the job of an architect to discover the common patterns within these unique problems and to come up with best practices that have helped other companies cope with the same pattern in their unique situations. That is why it’s important for an architect to be able to generalize and to have knowledge of a broad spectrum of patterns and matching best practices.
A tool that can support in this process is the Integrated Architecture Framework (IAF). It dissects a company into elements and their structures, which makes it easier to discover the patterns governing those structures. From there it’s only a small step to match the patterns with a proper solution.

Contrary to other art forms architecture also serves a practical purpose. It has to support business and, where possible, help to improve it. It is of great importance which improvements it can support, because that is the key to the acceptance of the architecture.

When creating an IT architecture you are usually busy enabling aspects like scalability and maintainability in one way or another. These types of flexibility take time to create and often come at a steep price. Take for example components like an ESB and a proper SOA environment in general. But all these aspects are hygiene factors for the client. It is important that the proposed architecture enables the expected response times and that maintenance costs remain acceptable, but in the end this is not what the client really ‘wants’.

The client wants to work more efficiently, get more control over his key processes or attain a larger market share. And that is exactly what will motivate him to accept your architecture. Flexibility is just a crucial extra.