J. on Architecture

…and does the customer want to be known? These are two very important questions you have got to ask yourself, when considering CRM. First make sure that you are really going to use the information that you request from you customers, because obtaining and maintaining the data is non-trivial.

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.

In civil architecture it is custom to analyse the works of others. By studying actual buildings, architects can see for themselves what works and what doesn’t. Especially with the blueprints in hand, walking through the building can be a great learning experience.

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.

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.