Tuesday, July 18, 2006

On Architecture

When does the definition of a thing become more than the thing itself? Twenty years ago no one cared about software architecture. Now, when you review how the community defines architecture, its sometimes insightful and sometimes laughable. It is seldom consistent and often vague. It's a great title though.

The problem is that architecture is similar to art. When there is talent and thought involved, people notice. When you throw it against a wall and it sticks, it is not necessarily art (or architecture). Who defines it is as important as the definition.

So here goes...

When defined by its results, application architecture is successful when it:
  1. Defines the patterns of all entities within a 'system'. This accomplishes improved project estimation and allows for specialization of development staff.
  2. Defines specifically HOW each entity can interact with other entities and which entities cannot interact. This accomplishes loose coupling.
  3. Defines WHEN each entity can communicate and what information is transferred during a transactional communication. This provides state management and requirements coverage in all application scenarios.
An entity is the realization of an atomic unit of the business problem that can be logically and clearly separated by its composition, function or derivation.

When all three of these objectives are met, the application’s architecture can be completely documented and translated into tangible components and base objects that enforce requirements within context.

... chew on that and let me know what you think. JJ

No comments: