Microsoft’s Architecture Journal 15

The latest issue of the Microsoft’s Architecture Journal is bound to rekindle the topic of maturity and purpose of the software / enterprise / technical / infrastructure / data architecture discipline. The issue is fresh off the press. Microsoft is correctly anticipating the onslaught of responses by setting up a special discussion forum. As of writing of this post the forum is not yet active, but once it becomes active the phrase tra-ta-ta-ta-ta will take on a whole new meaning.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Frank Lloyd Wright

Frank Lloyd Wright, one of the most famous American [building] architects of all time, worked on over 500 structures and left a few notes of wisdom for us to consider. While the comparison between software and building architecture breaks down pretty quickly, the quotes below apply to both disciplines.

1. A great architect is not made by way of a brain nearly so much as he is made by way of a cultivated, enriched heart.
2. All fine architectural values are human vales, else not valuable.
3. An architect's most useful tools are an eraser at the drafting board, and a wrecking bar at the site.
4. Every great architect is - necessarily - a great poet. He must be a great original interpreter of his time, his day, his age.
5. Form follows function - that has been misunderstood. Form and function should be one, joined in a spiritual union.
6. Get the habit of analysis - analysis will in time enable synthesis to become your habit of mind.
7. Less is only more where more is no good.
8. The architect must be a prophet... a prophet in the true sense of the term... if he can't see at least ten years ahead don't call him an architect.
9. The architect should strive continually to simplify; the ensemble of the rooms should then be carefully considered that comfort and utility may go hand in hand with beauty.
10. The truth is more important than the facts.
11. "Think simple" as my old master used to say - meaning reduce the whole of its parts into the simplest terms, getting back to first principles.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Engineering elegance

I came across this quote on definition of engineering elegance by a French aviator and author Antoine de Saint- Exupéry: “A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.”

Is this statement applicable to software architecture? Aren’t architects constantly trying to add features that fulfill more and more functional and non-functional requirements? Aren’t multiple layers of security always good? Wouldn’t installing a .NET framework 3.5, for example, is better than .NET 3.0, because it has more features?

Perhaps those who see the power in this quote are the architects who are able to truly understand the essence of a business problem; it is those who can skillfully control the scope. But is this applicable to the software architecture domain as it stands now?

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Criteria For Failure

Every project team asks themselves, implicitly or explicitly, what are our criteria for success? Depending on the range of the stakeholders involved you’ll get answers from the superficial (e.g. “users of all skill level can use software”) to the goal oriented (e.g. “identify the safest and most viable customers who need car insurance”). It’s easy to talk about success – especially non-quantifiable success.

The Firebrand Architect philosophy encourages you take a step further and pose a question: “What are our criteria for failure?” In other words – when we look back a year from now how would we know for sure we have failed to achieve our objective? Depending on your relationship with the group of the stakeholders you may have to be diplomatic as to how you pose the question.

Let’s work through an example. A project aims at providing insight into the inventory stored in many warehouses. The goal is to keep the inventory as low as possible while providing quick response to product demand. This project has a budget of $2,000,000 and will require a purchase of expensive COTS software ($500,000). A team of stakeholders will let the technical team decide which of the vendors to select, but know that a mature COTS software package has solved a similar problem in other organizations.

A year goes by, hardware has been purchased, COTS software installed and linked to a data warehouse, insight for a few categories of inventory can be obtained. Is this project a success or a failure?

One may say that since the software has been installed and connected to a data source in the production environment it’s a success. If that’s the only claim to fame, then this project is a failure. It doesn’t produce the insight that a business needs.

Using the same example as above, if a project produces some level of insight, but not all what was envisioned was it a failure or success? This is a harder question. If the paradigm and the model of operation through which the limited insight has been developed can be naturally expanded to gain insight in all envisioned categories, then the project is a success despite not delivering everything what was planned. If the paradigm doesn’t scale to cover additional level of insight, then the project is a failure.

Knowing the definition of success is important. Knowing the definition of failure is paramount.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Conceptual Integrity

It’s a well known fact that deciding what exactly to build is the hardest part of software development. So how does one deal with complexity and uncertainly? Sanity is retained and complexity managed by maintaining conceptual integrity in your solution. This goes beyond the conceptual integrity of the architecture, but the conceptual integrity of a solution.

As an architect who will start working from a set of initial requirements (and later work with the requirements management team to refine requirements) you need to understand why a business problem is being presented in a given way and why it’s being solved in a given way. The business problem and the conceptual solution need to be rational and need make sense as a whole. It’s not necessary, moreover – counterproductive, to have details at this level, but having a conceptual integrity of a solution before investing heavily into architecture design and analysis is paramount.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com