J. on Architecture

Web 2.0 has given the individual user a voice. Now the question arises what the value of that particular voice is. One problem is identity, which I’ve written about last year and is now becoming a problem even for blogs like Information Architects Japan.

The other problem is authority. Everybody can give their two cents, but is that what your community is really waiting for? Newsweek is quick to introduce Web 3.0 as a solution to filter expert opinions, but what we really need is a central directory of verified accounts to which we can attribute the proper authority. What ‘central’ and ‘verified’ means in this context depends on the application. But whether it’s the name on a credit card or a government initiative like the Dutch DigiD, chances are that it’s an external service that you will have to incorporate in your own domain.

So if you really want to harness the power of your community, make sure you can attribute it’s input to the proper identity.

Personas, detailed examples of your future users, seem to be getting back in style. They have a function both in analysis and design. Could they also work for architecture? I think so.I’ve used them on my last project and they really helped with some of the tougher design decisions. It’s easier to make out if you’re helping ‘Jane’ with a certain decision, instead of user group ‘X’. In the end that’s what architecture is all about. Helping individuals with their actions, which is something you can loose sight of when working your way through tons of services and components.

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.