The beauty of an information system

Whenever you ask a typical programmer about the beauty of a system, he or she will probably start rambling about the latest technologies and methodologies used during the project. Ruby ninjas will start a discussion about language syntax and start bashing every other language out there (especially Java.)

The beauty of a computer system. Is this - next to delivering a system within the set timeframe and budget - a priority? Even harder, how do we determine the beauty of such a system? Budgets and deadlines can be expressed in numbers, beauty can not. Who sets the standard for beauty and from which perspective? The perspective of the builders, the ops team, management or from the perspective of the end user?

There's one thing all parties seem to care about: a sensible system. Development teams like to have a codebase which allows quick iterations, operations likes a system which requires doesn't t complicated environment, the executive likes a system that boosts efficiency, while internal project leads just seem to like things that make themselves look good. Eventually there's the end user.

Maybe a sensible system equals a beautiful system. When every party involved comes to a consensus, a system which accounts for everybody's needs and wishes should come out at the other end. (When the system is build according to spec, that is.) This covers the functional beauty of a system.

But what about that feeling of beauty? Admittedly, that's not one of the strongest points of our industry. There's (at least) one tech company that succeeded in putting a certain feeling into its products and that's Apple. The way of presenting new products and attention to detail is something lots of consumers fall for. Many tried (and failed) to find the secret sauce to get such loyal customers.

My guess is that it all comes down to the detail. It has been proven that creating a feature-rich system isn't that hard. The hard thing is making it work for the users. It's the small things.

The educated reader might have noticed we covered two of the three qualities of good architecture according to Vitruvius, which leaves us with solidness or durability. This may be the toughest quality of all, especially for the tech world. When you check out IT departments at banks and insurance companies and see COBOL systems from the 70's you might think that we're covered, but the opposite is true.

IT systems a inflexible and rigid. A durable system should be build with growth in mind and should be able to adjust to new situations. This should be achievable without rewriting the entire core. Service-oriented architectures, business process repositories and NoSQL database systems are the buzz words here.

So what has to changes before we start seeing these kind of systems. The first thing is that clients should understand that investments in such a system pays off in the long run. Secondly the technologies which allows these kind of systems should be developed further and lastly someone who ties it all together; a digital architect.