This is not to say that the architect can dispense with the complexity. Far from it. It’s the job of an architect to maintain both the complex reality and simplified presentation in a coherent way, adding both an extra level of complexity and giving the guarantee that decisions based on the simplified presentation have the same effect on the complex reality.

In the digital world (i.e. on a website) this process is atomic and rigid, because there is no interaction. The customer has to provide all the information in the predefined format of the customer (web) application and has to do so in one go. Of course the information exchange can be broken down into logical steps, but the transaction as a whole has to be done in one take. If the customer doesn’t provide all the information; no transaction. If the customer has questions; no transaction.

So how can you unify these two dynamics in a multi channel environment? This is a question that is especially relevant for government organizations that are bound by law to provide their services over multiple channels. The answer is services.

If you brake the process down into logical steps and form separate services for each of these steps, you can use these in the predefined way that the customer application is designed, or you can let the employee use them at their own discretion in a flexible employee application. That is the essence of service oriented architecture.

This pertains not only to the architecture you are designing, but also to the object being created. Let me give you an example. You can design an amazing skyscraper with a sound foundation and a smart layout, but if the client wants to build it in a little village instead of a large city, you have to ask if the need for the skyscraper itself makes any sense.

Of course this is a simple example, but the point is clear. It’s better to question the ideas of your client, than to make a good architecture that is useless. In the end your client will thank you for it, because it always leads to better value for money.

Is their name really important? If you want to address them in your marketing campaign it is, but for cross-selling it is not. Address information is relevant for delivery, but usually not for personalization. Information is only relevant in certain aspects of CRM, but certainly not all of them. So you have to decide on how you want to interact with your customer and get the necessary information accordingly.

This brings us to obtaining the data. People are generally reluctant to provide personal information, so don’t bother them unless you have to. One way you can do this is by analyzing behavior on your website. This can be done automatically and provides a wealth of information. Another way is to offer after-sales services, in return for some contact details. That way they get real value for their information currency. Never ask for personal information up front, or for no reason. People value their privacy.

So only take what you need from you custeromer and use really it. That will keep your customers happy and your systems light.

So why don’t we do the same with IT architecture? Lately we tend to focus more and more on the process, with IT Governance being a hot topic at the moment. But I think we should also look at the result and evaluate it. Does the proposed architecture work as expected? Are there new patterns that can be identified? How can we use the best practices?

Only through reflection can you become better.

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.

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. 

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.