Tag: Architect

97 Things Every Software Architect Should Know – 23/97

The database is where all of the data, both input by your employees and data collected from your customers, resides. User interfaces, business and application logic, and even employees will come and go, but your data lasts forever. Consequently, enough cannot be said about the importance of building a solid data model from Day One.

The exuberance over agile techniques have left many thinking that it‘s fine, or even preferable, to design applications as you go. Gone are the days of writing complex, comprehensive technical designs up front! The new school says deploy early and often. A line of code in production is better than ten in your head. It seems almost too good to be true, and where your data is concerned, it is.

While business rules and user interfaces do evolve rapidly, the structures and relationships within the data you collect often do not. Therefore, it is critical to have your data model defined right from the start, both structurally and analytically. Migrating data from one schema to another in situ is difficult at best, time consuming always, and error prone often. While you can suffer bugs temporarily at the application layer, bugs in the database can be disastrous. Finding and fixing a data layer design problem does not restore your data once it has been corrupted.

A solid data model is one that guarantees security of today‘s data, but also extensible for tomorrow‘s. Guaranteeing security means being impervious to bugs that will – despite your best efforts – be pervasive in an ever-changing application layer. It means enforcing referential integrity. It means building in domain constraints wherever they are known. It means choosing appropriate keys that help you ensure your data‘s referential integrity and constraint satisfaction. Being extensible for tomorrow means properly normalizing your data so that you can easily add architectural layers upon your data model later. It means not taking shortcuts.

The database is the final gatekeeper of your precious data. The application layer which is, by design ephemeral, cannot be its own watchdog. For the database to keep proper guard, the data model must be designed to reject data that does not belong, and to prevent relationships that do not make sense. Keys, foreign key relationships, and domain constraints, when described in a schema, are succinct, easy to understand and verify, and are ultimately self-documenting. Domain rules encoded the data model are also physical and persistent; a change to application logic does not wash them away.

To get the most out of a relational database – to make it a true part of the application as opposed to simply a storehouse for application data – you need to have a solid understanding of what you are building from the start. As your product evolves, so too will the data layer, but at each phase of its evolution, it should always maintain its status as Fortress. If you trust it and bestow upon it the heavy responsibility of trapping bugs from other layers of your application, you will never be disappointed. (RMH Edited 7/13/2008) By Dan Chak (Edited RMH 5/28/2008)

97 Things Every Software Architect Should Know – 22/97

Every software architect should know and understand that you can’t have it all. It is virtually impossible to design an architecture that has high performance, high availability, a high level of security, and a high degree of abstraction all at the same time. There is a true story which software architects should know, understand, and be able to communicate to clients and colleagues. It is the story of a ship called the Vasa.

In the 1620’s Sweden and Poland were at war. Wanting a quick end to this costly war, the King of Sweden commissioned the building of a ship called the Vasa. Now, this was no ordinary ship. The requirements for this ship were unlike any other ship of that time; it was to be over 200 feet long, carry 64 guns on two gun decks, and have the ability to transport 300 troops safely across the waters into Poland. Time was of the essence, and money was tight (sound familiar?). The ship architect had never designed such a ship before. Smaller, single gun deck ships were his area of expertise. Nevertheless, the ship’s architect extrapolated on his prior experience and set out designing and building the Vasa. The ship was eventually built to specifications, and when the eventful day came for the launch, the ship proudly sailed into the harbor, fired its gun salute, and promptly sank to the bottom of the ocean.

The problem with the Vasa was obvious; anyone who has ever seen the deck of a large fighting ship from the 1600’s and 1700’s knows that the decks on those ships were crowded and unsafe, particularly in battle. Building a ship that was both a fighting ship and a transport ship was a costly mistake. The ship’s architect, in an attempt to fulfill all of the kings wishes, created an unbalanced and unstable ship.

Software architects can learn a lot from this story and apply this unfortunate event to the design of software architecture. Trying to fulfill each and every requirement (as with the Vasa) creates an unstable architecture that essentially accomplishes nothing well. A good example of a tradeoff is the requirement to make a Service-Oriented Architecture (SOA) perform as well as a point-to-point solution. Doing so usually requires you to bypass the various levels of abstraction created by an SOA approach, thereby creating an architecture that looks something like what you would typically order at your local Italian restaurant. There are several tools available to architects to determine what the tradeoffs should be when designing an architecture. Two popular methods are the Architecture Tradeoff Analysis Method (ATAM) and the Cost Benefit Analysis Method (CBAM). You can learn more about ATAM and CBAM by visiting the Software Engineering Institute (SEI) websites at http://www.sei.cmu.edu/architecture/ata_method.html and http://www.sei.cmu.edu/architecture/cbam.html respectively.