J. on Architecture

Daniel McGinn wrote an article about the need for more architectural flexibility in housing. This need comes from the increasing desire to integrate our gadgets and devices into our homes, like integrated speakers and TV’s. Unless you are willing to buy a whole new house every time you switch TV or Stereo, you will have to do some renovation to replace these devices.

Apparently people are choosing the ‘whole new house’ option, since the costs for retrofitting can be very high.

The same is happening in IT. Companies want to buy whole new systems and infrastructures, because the current ones are outdated. Unfortunately companies can’t take a few weeks off to move to a new IT infrastructure. So they are left with the only alternative; retrofitting.

To help companies with this, architects need to do two things. First they have to specify a proper replacement. This means that if a company want to replace it’s VCR, the architect has to make sure that it is replaced with a DVD player and not with another VCR, nor a CD player.

Second they have to make sure that the next replacement, let’s say from DVD to Blu-Ray, will take minimal effort. So has to make sure that removable panels are put in place when installing the DVD, but without replacing a whole wall or even the whole house. That sounds easy enough, but companies have often gotten the advice to put in an SOA architecture with a complete ESB, service adapters on all ‘legacy’ systems and a completely new user interface for the whole enterprise, when all they wanted was a new accounting application. That’s like building a removable house when installing a new DVD player.

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.

“Freedom [is] about drawing the right boundaries, not living without them.” – West Crosse, The Architect.

There are a million interrelated possibilities and choices in life, but instead of embracing this wealth, people tend to get paralyzed by it. Afraid that they will make the wrong choice and place themselves in a deadlock.

As creatures of habit we usually respond to this by choosing not to change and we can get really fierce defending this unspoken decision. The problem is that we don’t admit to this. We make plans for all kinds of changes, but when it comes to action we stick to our initial decision: No change.

This is where the architect comes in. Under the guise of creating flexibility, his job is actually to do the opposite. He makes all the obvious and logical choices for us, so that we are limited to only one or two critical choices. This gives us the freedom to make a clear decision between either left or right and then stick to that decision wholeheartedly.

An architect is often expected to lead a company into the future by making decisions on what to change and how. This is however a responsibility that lies in the hands of management and cannot be delegated to an architect or anyone else for that matter.

The management of an organization has the duty choose a direction and to translate this direction into specific changes which have to be made within the organization. This is easier said than done, especially because a substantial part of the changes will nowadays take place in the virtual world of ICT. This is a world that has little tangible elements, while having very real costs attached to it.

To be able to make sound decisions and concrete plans in this situation, management will need insight. Insight in the current situation and an understanding of the size and impact of the changes that will have to take place, once a specific direction has been taken. It is this insight that the architect can provide to management.

But how does the architect come to this insight? By getting the required information form the organization itself. To have a proper sense of direction, management will need to make it’s vision and strategy explicit. The architect can help in this process by facilitating workshops for management where they can come to an unequivocal description of that vision and strategy. After this step it’s the architect’s job to learn the state of the current organization and identify the parts that need change in both the business as well as the supporting ICT. This too is something that he cannot think up himself, but what he must distill from interviews and documentation.

When all this information is put into one big picture, management gains full insight, into the possible direction of the organization and the resulting changes that need to be made. They are then able to make sound decisions, which the architect facilitated with his clear picture.