Architecture (ar' chi tec' ture): n   1. The structure and themes of a system.

What would you call a beautiful Cape Cod style house to which you added a sunroom, a two-car garage, another bedroom, a second kitchen for the in-laws, and a three season porch? Ugly. While it happens, most people would see such a building as an abomination. Furthermore, as you add more, you find that the underpinings and infrastructure -- plumbing, heating, and electrical systems -- can't do what's needed. To keep adding, you have to rebuild all that -- at great expense, since most of what needs rebuilding is inaccessible. And you still not get what you need.

What's unfortunate about systems is that their parts and workings are largely invisible. It's not easy for a management team or business community to see the effects of "just adding this feature" or "integrating these two applications" or "just disabling that function". What are the effects? Whole sections of dead code, unused data structures, convoluted logic, and -- for integrated applications -- imperfect synchronization. Sooner or later, enhancement becomes effectively impossible. And systems can be born with architecture as byzantine as those that have degraded over time.

In the world of applications, the point of architecture is to meet clearly defined objectives. Often the objectives (sometimes listed as "requirements") are mush. "Must be maintainable." "Must be reliable." "Must be user-friendly." Unless there's an objectively measurable requirement, there's really no way to understand how it affects the archiectural choices.

Let's take an example. You're building a new application.

• (Functionality) It must support the process of acquiring leads and managing opportunities.
• (Maintainability) It must be flexible in that the steps we go through may change from time to time, and we must be able to reprogram it by administrative features.
• (Usability) It must help our user community, which has a history of mis-directing prospects into the wrong step in the opportunity management process. The system must cut misrouting errors by 90% after the users are trained for no more than 4 hours.

If you wrote a spec, it would no doubt address the first in some detail. But the other two? They may get honorable mention, and very likely, they'll get lip-service at that.

But what if they're taken seriously? The theme is no longer solely opportunity management. It's a flexible workflow management system that implements opportunity management, guiding next steps according to business rules. (That doesn't mean it has to be expensive, by the way.) Want to add another step? Sure. Change the roles of those executing various steps? Why not. If built right, these changes may well be something a super-user can do.

The successful applications architect looks at all parts of the problem, articulates all the key themes - not just the obvious ones - and drives the solution towards the right structure. And if one part of the problem is the required use of an existing application, then the architect's work is recrafting the old and blending the new to make something coherent.

Like rebuilding a 1200 square foot Cape into a 2800 square foot colonial.

Allow us to work with you to shape your applications architecture. You business depends on it.