Monday, September 24, 2007

Neglected Aspects of Software Architecture

Todd Kaiser, a Chief Architect of Government Systems at Raytheon Intelligence & Information Systems, delivered an outstanding presentation at the 2007 SATURN workshop. The absolute beauty of the presentation is simplicity with which he delivered a very important message: some software architects ignore non-technical aspects of software architecture that results in “collateral damage.” In addition to concentrating on technical pillars of a solution: data, structure, and behavior, an architect must also actively weigh managerial, financial, and contractual aspects of software architecture. Your personal architecture world may be different, but Todd Kaiser’s presentation succinctly delivers the message that applies to most architects: architecture is more than just technology.

SATURN 2007 presentation on Neglected Aspects of Software Architecture.

Firebrand on duty: Constantin K.
www.SoftwareArchitectures.com

Thursday, September 20, 2007

Architecture is in expressly delightful

"Architecture is expressly delightful, and of the greatest convenience to mankind in all respects, both public and private; and in dignity not inferior to the most excellent. …. Him I shall call an architect who, by a sure and wonderful art and method, is able, both with thought and invention, to devise and, with execution, to complete all those works which, by means of the movement of greatest weights and the conjunction and amassment of bodies, can, with the greatest beauty, be adapted to the uses of mankind: and to be able to do this, he must have a thorough insight into the noblest and most curious sciences." Leon Battista Alberti (1450)


Firebrand on duty: Constantin K.
www.SoftwareArchitectures.com

Sunday, September 16, 2007

Responsible Software Architecture

SoftwareArchitectures.com is propelling the concept of responsible software architecture. This concept is based on philosophy that every decision made by a software architect must be conscious and must be supported by a judicious decision making process that clearly demonstrates why the chosen design alternative was selected out of a range of other possibilities.
Every decision made by a software architect is made in some context at some snapshot of time. The context is defined through architect’s understanding of personal capabilities, requirements, constraints, financial resources, time, capability of the team, etc. The context changes over time, so it’s imperative to document the background against which a decision was made. When someone questions a design decision or suggests a better solution an architect must provide a scientific justification of his or her decision – without it architect’s credibility and the credibility of the solution may be compromised.
The concept of responsible software architecture is very powerful, but few architects live by it. Think about two or three most recent software architecture design documents that you reviewed. How many documents clearly explain the way key architectural decisions meet business drivers and why selected architectural approach is better than listed alternatives? Not every decision needs to be documented with an elaborative set of alternatives, but all key decisions need to be explained. Key decisions are architecturally significant choices that if changed have a profound impact on multiple quality attributes of a system.
A responsible software architect must sincerely believe that a business problem, and not technology, drives the solution. Technology may be the core vehicle for delivering the solution, but it’s not the driver – this is a paramount concept. Because technology is not the driver a responsible architect must be able to initially reason about a solution without technology specific terminology. The point here is that selection of a technology (platform, development tools, COTS software, etc.) is an architecturally significant decision that constraints the solution. An architect must be able to provide a judicious explanation as to why selected technology was chosen. Once that decision was made it’s only natural to think within the context of selected technology.
Some software architects have too much vested interest in a given technology so they only design solutions with that framework in mind. This clearly limits the range of solution alternatives, but it’s not as limiting as reusing the same architectural approach from project to project without justifying the reason for doing so. For example an architect who designed web based applications using MVC architectural style for the past four years may be inclined to use it on the next project even if a Front Controller style or an AJAX based pattern may be more appropriate. Similarly if an architect is used to a working with a process intense SDLC he or she may push for it without realizing that a new project requires agile JAD/RAD approach due to its research and development nature. The latter examples demonstrate the proverb: “When all you have is a hammer, then everything looks like a nail.” For an architect to be responsible he or she must question their decisions and make sure that appropriate audience is able to understand the reasoning behind the decisions.
SoftwareArchitectures.com is currently establishing a Center for Responsible Software Architecture. Join the discussion on responsible software architecture in a specially created forum. Each post will earn you a chance to win Evaluating Software Architectures: Methods and Case Studies book (through October 15 2007). Registration required to view and post.

Firebrand on duty: Constantin K.
www.SoftwareArchitectures.com

Friday, September 14, 2007

AJAX Application Architecture

A friendly reminder: a decision to implement the UI of a solution with AJAX has architecturally significant implications. There are different flavors of AJAX implementations and each has a set of tradeoffs associated with bandwidth consumption and security. Read this MSDN article for details.


Firebrand on duty: Constantin K.
www.SoftwareArchitectures.com

Thursday, September 13, 2007

Beyond Software Architecture - quick read

A dated (2004) yet applicable interview with Luke Hohmann, author of Beyond Software Architecture: Creating and Sustaining Winning Solutions (Addison-Wesley, 2003).

Make this a quick read - Luke Hohmann provides interesting views on the human points of software architecture with respect to building enterprise software with agile methodologies in mind.

Some notable points:
- In the beginning architecture should be complete, but it’s OK for it to be immature. This is exactly what Fred Brook’s identified in his 1975 masterpiece “The Mythical Man-Month” (p. 94) when he identified the concept of conceptual integrity as the most important consideration in system design.
- Software architecture is a communication medium

Part 1, Part2, Part 3.


Constantin K.
www.SoftwareArchitectures.com

Friday, September 07, 2007

Microsoft's Reference Architecture

A software architect must have a comprehensive understanding of the technical environment in which a software solution will reside. Mature and usually large organizations usually have volumes of Enterprise Architecture (EA) that contain guidance and identification of the as-is state of the enterprise and the future evolution. The volumes of EA usually represent different levels of abstraction, but have a common theme centered on a business domain. Parts of the EA are meant to be used as reference architecture to guide a software architect in design of a solution so that it fits snuggly into the existing enterprise and so that a solution can evolve graciously.

Microsoft has developed a comprehensive reference architecture that for its Windows Server platform. It’s a “detailed reference architecture, tested and proven in labs, that yields valuable implementation guidance for meeting the requirements of an enterprise.” Even non-Windows enterprise architects will benefit from the recommendations in the Microsoft’s reference architecture documentation.

For each type of service reference architecture contains an introduction, a blueprint, a planning guide, a build guide, and an operations guide. Out of many services covered some notable are network devices, storage devices, firewall, certificate, backup, network, directory, file, data, web application, middleware, and messaging.

Microsoft’s reference architecture is well organized, easy to use, and very comprehensive for both Microsoft and non-Microsoft centric architects.

Home page | Comprehensive download MS Word documents in installer

Firebrand on duty: Constantin K.
www.SoftwareArchitectures.com

Thursday, September 06, 2007

Startbucks The Way I See It #240

Sometimes there is more wisdom on the outside [of your Starbucks cup of coffee] than on the inside. From "The Way I See It" series #240 applies fluidly to software architecture:

If you can’t visualize it, don’t build it.
-- Constance Adams
Space architect and National Geographic Emerging Explorer.


Firebrand on duty: Constantin K.
www.SoftwareArchitectures.com

Blockchain learning path for Enterprise Software colleagues

I wrote this post to document my learning path of blockchain concepts and Ethereum technologies while keeping my “new to blockchain” collea...