J. on Architecture

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.

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.

As an architect you may sometimes have the feeling that you’re creating the architecture all by yourself, but we all know that it is in fact the stakeholders that shape the architecture. The architect is only the medium that gives it form, but to do this you will need the stakeholders requirements.

A good method for gathering these requirements is by having a brainstorm session with a group of stakeholders, prefferably those with different viewpoints. Putting the people together in one room isn’t enough though. Neither is asking them to just give you the requirements, because chances are that you will come out of the room with only vague directions in which the architecture should go.

If you really want a brainstorm session to be fruitful you will need to set clear boundaries and ask the right questions. This is to get everybody in the right frame of mind, because architectures are always about some form of change. People usually find it difficult to envision the new situation after this change in such a way that they can answer concrete questions about this situation. They either answer from their current frame of mind, or they get stuck forming a picture of the new situation because of all the unknowns that come with it.

You can help by first setting the boundaries of the discussion. You can do this by telling the the attendees in advance what the scope of the architecture will be. If it’s a project architecture, you will need to provide the project scope. If it’s a enterprise architecture, you will need to provide the mission and goals of the organisation. These are a given and shouldn’t be the subject of discussion.

Then at the start of the session you should provide specific questions to guide the discussion. These targeted questions should focus on a particular subject in the new situation that you want clarity about. These subjects are usually the critical elements that form the architecture. An example question for an enterprise architecture would be how management thinks the new target group, as defined in the goals of the organisation, would best be facilitated. This avoids the discussion whether or not the group is the right one to target. That station was passed defining the goal. Instead you can focus on the new situation and how it will take shape.

So ask the right questions and the architecture will be created for you. You only have to put it in writing.

If you ask an IT architect to visualise an architecture, you usually get a beautiful A0 poster with all kinds of objects and their intricate relations. Depending on the type of architect this diagram will either be filled with business terms or technical terms, but the nature of the diagram will basically be the same. This is to be expected of course since this is the language of the architect, but is it also the language of the business manager who has to validate the architecture? Usually it is not.

Don’t get me wrong. The type of diagrams that I am referring to serve a very useful function. They provide very clear guidelines for designers and programmers to build what is needed, in the same way that the blueprints of architects in the building world provide direction to construction workers. They do not however convey the qualities and principles that the client is really asking for. This can only be done using a model or a sketch. And since the object to architect is not a building, but a software system, the only part that you can really visualise is the computer screen. That is where the interaction takes place and it is there that a client can get a feel for what the software does and how it does it.

This is where we come into the field of user experience design. It helps a great deal if you can sketch a few screens with the basic interface and the elements that it should or should not contain. If you can combine this with a simple wire model of how the screens relate to eachother, then you’ve got the basics of storyboarding.

It is ofcourse on viable to sketch all the possible screens in advance. You should only concentrate on those that can have an impact on the underlying architecture. ‘Do you want this information (coming from one system) together with that information (coming from another) in one screen?’ ‘Who will use this screen the most and why?’ ‘Can everybody see the information in this screen or should it be restricted?’ Those are the kinds of questions that you can get an answer to using the storyboard. It will not directly provide of all functional and non-functional requirements, but it does give you a clear impression which way it should be heading and what the critical elements are. But most of all, it gives the client a means of imagining the end result.