Showing posts from 2007

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 Kostenko
Firebrand Architect®

Software Architecture Conferences and Events

The Software Engineering Institute maintains a comprehensive list of "upcoming conferences, workshops, and calls for participation that explicitly include "software architecture" among their topics of interest." This is a good place to start if you're looking for an opportunity to share thoughts with like minded individuals outside of your immediate circle of software architecture contacts. Research each event with care, as different user communities look at architecture from a different lens.

Constantin K.
Firebrand Architect™

Technical and Business Architecture

If architecting was only about solving a technical problem, then this discipline would be strictly under the computer science domain. What makes software architecture a child of the software engineering domain is the fact that an effective solution needs to solve business problem or achieve a mission. It’s clear that an architect has to work works very closely with all stakeholders in order to understand the root of the problem for which a solution has been envisioned. There are two core qualities that an architect must exhibit. First, an architect must have an implementable vision of the whole concept from start to finish (if you don’t who will?). Second, an architect must intelligently question the business problem that a customer is trying to solve. This is very important, because this will minimize the risk of the solution not fitting into the existing (or future) technical and business infrastructure. In mature organizations both software architects and business analysts speak a …

Selecting COTS software under pressure (Forrester and Gartner)

This happens on many projects: everyone agrees that the core of a solution (e.g. workflow engine) will be purchased instead of built from scratch. This is an absolutely rational decision for most enterprise applications. The next question is which vendor to select. The rational approach is to identify the core functional requirements and key quality attributes that the solution must exhibit. This is an absolute must; because without understanding what you need you will not be able to objectively judge your options. The criteria on which you should evaluate you COTS software candidates must be granular and quantifiable to the degree that makes sense. Each criteria element needs to be weighed against all other chosen consideration elements so that all weights add to a whole. E.g. In case of workflow COTS software the number of concurrent workflow processes that the solution must support has to be at least 400 and this criterion has a 15% importance in relation to other selection element…


As an architect you’re often get placed in uncomfortable situations. One of such scenarios is facing the architect of a working system that you’re tasked with replacing. In this scenario your organization has an existing legacy system that still does a decent job of supporting the current needs of the business. The executives funded your project, because the legacy system cannot support the evolving business needs. You’re up to a real challenge. By definition your project will bring change into organization and any change will cause friction. On top of that you’re working against a benchmark – legacy system provided many years of reliable support. On top of that there may be people who have a high stake in maintaining the legacy system no matter what executives think. Even if you’re an expert in your business domain it’s inevitable (and logical) that you’ll interact with an architect of the legacy system – who happens to have 20 years of experience with organization. Based on what the…


As an architect you’re often get placed in uncomfortable situations. One of such scenarios is facing the architect of a working system that you’re tasked with replacing. In this scenario your organization has an existing legacy system that still does a decent job of supporting the current needs of the business. The executives funded your project, because the legacy system cannot support the evolving business needs. You’re up to a real challenge. By definition your project will bring change into organization and any change will cause friction. On top of that you’re working against a benchmark – legacy system provided many years of reliable support. On top of that there may be people who have a high stake in maintaining the legacy system no matter what executives think. Even if you’re an expert in your business domain it’s inevitable (and logical) that you’ll interact with an architect of the legacy system – who happens to have 20 years of experience with organization. Based on what the…

Advice for apprentice software architects

The software architecture discipline has matured to the point where the core tool bag for architecture analysis and design can be learned by any serious software engineer. But this doesn’t mean that architect’s experience is no longer an important attribute of architect’s character. The best way to learn is by doing. To quote Lakota Indian saying: "Tell me, and I'll listen. Show me, and I'll understand. Involve me, and I'll learn." Apprentice architects must seek out opportunities to work on architecturally significant aspects of various projects. Diversity here means working on projects with different SDLCs, projects of different scope and size, and projects across different functional domains. Diverse experience – preferably across different organizations – will enable an apprentice architect make better decisions in the future as the repertoire of skills and knowledge grows.Everybody wants an architect with 10 years of experience, but nobody wants an architect…

Globalization and Software Architecture

When I interview potential team members I always ask the question: “What is the impact of globalization on our company and on our clients?” This is not an easy question to answer and I’ve seen recent college grads and seasoned leaders alike cringe when they hear this. The topic of the global economy is familiar to the IT folks. Many practicing architects are leveraging or at least familiar with the outsourcing software development models. But thinking beyond software architecture – what impact does globalization have on the business problem you’re trying to solve? Perhaps the problem you’re trying to solve is now nonexistent, or perhaps the complexity of the problem just increased by a factor of ten.“What is the impact of globalization on software architecture?” This question I will try to answer in this blog in the near future. With no clear answers this topic is a zero day problem for pessimists and a vibrant opportunity for optimists. If you’re looking for a primer on the general t…

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 deman…

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™

Evaluating SOA using ATAM

This report, released by the SEI in September of 2007, is a very good example of applying the ATAM to evaluating an architectural style, such as SOA. You can find the report here.

The Abstract
"The emergence of service-oriented architecture (SOA) as an approach for integrating applications that expose services presents many new challenges to organizations resulting in significant risks to their business. Particularly important among those risks are failures to effectively address quality attribute requirements such as performance, availability, security, and modifiability. Because the risk and impact of SOA is distributed and pervasive across applications, it is critical to perform an architecture evaluation early in the software life cycle. This report contains technical information about SOA design considerations and tradeoffs that can help the architecture evaluator to identify and mitigate risks in a timely and effective manner. The report provides an overview of SOA, outlines …

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.

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.

Responsible Software Architecture 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 conce…

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.

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 mediumPart 1, Part2, Part 3.
Constantin K.

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 recommen…

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.

Architecting With 3rd Party Components: "Trust, but verify"

A proverb: “Trust, but verify” should always resonate in software architect’s mind when a decision is made to use a component that the architect does not directly control. This component may be a COTS software piece or an enterprise library developed by someone else. This becomes especially important if that component is part of the project’s critical path (e.g. a communication infrastructure component).For example, the enterprise may require every solution to use component Foo to obtain a security token. Or the enterprise may require component Bar to be invoked to pass through messages so that certain information can be collected for enterprise auditing purposes. Unless you have previous experience architecting with that 3rd party component take a safe path. Identify the elements of your solution that will rely on the 3rd party component. Then thoroughly analyze the external component for each quality attribute requirement that is associated with the software architecture element tha…

Revisiting the definition of software architecture

When was the last time you thought about the definition of a software architecture? It has been quite some time since I read the definitions posted on the SEI’s Community Software Architecture Definitions page. Some interesting definitions:Eoin Woods (Software Architect, Investment Bank, London, UK): Software architecture is the set of design decisions which, if made incorrectly, may cause your project to be cancelled.
Adu Matthaeus (Systems Architect, Eikon, Centurion South Africa): A configurable skeleton of any kind of software beast on which you hang implementation specific muscle to make it live.Jeff Winter (Software Engineer): … Architecture is necessarily a series of abstractions, depicting details relevant to one perspective while suppressing details relevant to other perspectives, and therefore expressed as a series of complimentary views. To say what those views are, you must embrace some ones method or make up your own.Steve Wright (Consultant - Sr. Data Architect, Knowledg…

Software Architecture Discipline Splits

We dreamed about the software architecture discipline becoming a mature discipline similar to the way civil engineering has evolved over time. To a certain degree this has become true: a unique set of skills is not required to develop a basic accounting back-office suite or a large scale eCommerce site. Banal solutions are reproducible by anyone with basic software design knowledge. This is good, because seasoned architects are now reaching out to solve more challenging problems. Up until now software architects were doing two jobs under the same title: mature software engineer and mature software designer. [Note that the word 'mature' is used over 'senior' since age does not equate to seniority or ability to design complex solutions.] The software architecture discipline will eventually split into those who concentrate on the art of the discipline and those who specialize in the science of the discipline. This is inevitable due to the ever-growing complexity of respon…

Question assumptions or live with consequences

Don’t assume that the knowledge you have or recently acquired is possessed by your stakeholders, customers, and clients. Even non-architectural knowledge, such as existence of alternate SDLCs, may not be known by those around you. This is a big deal, because a project may be moving forward, on a wrong orbit, while all key stakeholders assume that it’s the only way. As an architect it’s your responsibility to challenge the assumptions and expect a reasonable explanation. The same way you, as an architect, expect to be questioned about the tradeoff decisions and alternative designs. Firebrand on duty: Constantin K.

On Time and on Budget

Fresh from the June 2007 PMI magazine ... according to 2006 Chaos Research a study of 10,000 global software projects (value at $100K to millions), completed between October 2005 and November 2006, reveals that only 35% deliver on time, on budget, and within the requirements. That's an improvement from the 29% figure reported in 2004 by The Standish Group.

Firebrand Architect on duty: CK

Security for Software Architects

Security is about managing risk. No usable system is 100% secure – that’s a fact. Of course it is possible achieve 100% security by placing a system in a physically guarded bank vault and disabling all communication mechanisms. Based on how the society uses software systems it's clear that such approach is not suitable for most usable software systems. It’s not possible to defend against all vulnerabilities, not only because organizations don’t have the resources, but because new threats arise daily. It’s the architect’s job to work with the system stakeholders to seek the balance between risks and resources.

Read a new article on this topic on It's written is for both seasoned and apprentice software architects in mind. Security has always been an important topic, but with rapid software evolution software architects are forced to pay more attention to this quality attribute. In not so distant past, before standardization of various protocols (e.g. T…

Control Your Engine!

Imagine you’re building a car. You get car parts, including an engine, from various vendors [think COTS software] and different people help you put it together along the way [think contractors & subject matter experts across divisions]. You’re making progress – you have attached the wheels and can push the car through the product line [dev / test]. Now you’re reached the end of the product line. It’s time to start the engine and drive [pilot stage]. The engine turns but doesn’t start. After troubleshooting and double checking your work you find out that the engine [think messaging infrastructure] doesn’t work. The fuel tank is full [messages are sent from originator], the fuel line to the engine is full [message path is traceable], but the engine won’t process the fuel. When you ask for help from the engine integrators they blame the fuel line. The engine is the mechanism that makes a car move in a similar way that a messaging platform makes software components work together. The …

Design constraints

Nothing nullifies the effectiveness of a software architect more than project manager’s directive to design in three month increments for a system that will stay in service for 15 to 20 years.Not thinking about the future of a system is a sure way to guarantee unpredictability when it comes to the system quality attributes such as modifiability and extensibility.

Business Improvement Through Better Software Architecture

In the 10th edition of The Architecture Journal, published by Microsoft, a son & father pair have done an outstanding job describing architect roles in business software development. It’s not very often that you come across such a well written, eloquent, yet terse piece of writing that energetically captures the responsibilities of architect roles and the relationships between those roles.The authors, Sten & Per Sundblad, state in the opening paragraph that “business software exists for one reason only: to support the business and its activities … there is no other reason for business software.” This is the premise of their philosophy and a fact that software architects often forget. Countless articles have been written over the past five years on lack of alignment between IT and business. Few of those articles presented the issues and solutions with proper level of abstraction that made reading this article equivalent to reading a really book that you don’t want to end.The ar…

Asking for help - a mature decision

A software architect is in charge of the overall technical solution – there is no question about that. But a good software architect also knows his limits and requests assistance from subject matter experts on the issues outside of his or her knowledge base. Technical skills are only 49% of software architect’s skill set. For example, a software architect with experience in web portal development is assigned to lead a project for a web based case management system. If similar technology and the same web based paradigm are used on the new project this is a reasonable request on behalf of the business management. After studying case system requirements and after examining the quality attributes an architect sees that the system will require a highly sophisticated authorization system in order to ensure that the right users get access to the right parts of a case at the right time. If complex resource authorization is not architect’s technical strength, then a subject matter expert must …

EA pillars - a view

Enterprise Architecture is probably one of the most overloaded technical terms. There are many groups wrestling for control of the definition and its associated taxonomy. This of course causes architectural mismatch between systems, concepts, departments, and organizations. The following post by Paul T. Preiss, President of IASA, calls for examination of the essence of certain architecture specialties (software, infrastructure, and business) to derive an objective list of knowledge foundation blocks. This post is a great start to future collaborative work on building bridges between different frameworks and methodologies.

Duties of a Software & Solution Architect

What does it mean to be a software architect? How about a solution architect? There are as many opinions as definitions of software architecture. It is clear that a software architect is not simply a senior software engineer. Responsibilities of a software architect cover a wide array of skills outside of technical field of knowledge. The listing below is a series of opinion pieces by various bloggers and web sites on the definition of a software and solution architects.An Overly Long Guide to Being A Software Architect David IngWhat does the Solutions Architect career path look like?Mark BaciakAnatomy of a Software Development Role: Solution Architect Robert Bogue ( of a Software Architect SoftwareArchitectures.comWhat are the Duties, Skills, etc. of a Chief Software Architect? (previous page) SEIWWISA view WWISAConstantin K.
Firebrand Architect®

Effective Presentations by Software Architects

In an earlier post the topic of clear, concise, and terse writing was presented. This post raises the importance of effective architecture presentations. It’s critical for every architect to be able to create and deliver effective presentations in an amount of time allocated. The following tips, derived from experience, should be kept in mind. It is assumed you’ll be using a Power Point or similar software.Mind your audience. It’s imperative to set the tone and presentation content based on the audience and audience’s expectations. If someone requests a presentation on the architecture of a system find out what they want to get out from the presentation. This will make the process of creating the presentation easier and your results will be measurable.Mind your time. If you’re allowed 30 minutes for presentation you will only get 30 minutes. This is especially true with angel investors, venture capitalists, executives, and anybody who simply val…

Architects need to improve their written communication skills

Effective written communication skills are essential for every software architect. Expressing your ideas clearly, tersely, and effectively is paramount. If your audience does not fully understands your vision or design, then you’ll have to build (and probably fund) the system yourself. It is your responsibility, as the architect, to ensure that your readers understand your ideas.

Written communication is important, because that’s the only effective way to communicate with a large number of people who may be geographically distributed across the world in different time zones. A single software architecture design package is often the source of reference for hundreds of people on a large scale system or a system of systems.

The international software engineering community recognizes English language is the standard language for cross cultural communication. Therefore it is paramount for any software architect to improve their skill set of the written English. Improving written English is…

Beyond technolgoy in technical books - joy for architects

The winds are changing – the software engineering mainstream practitioners are finally starting to value the importance of the human aspects of software engineering. And that’s only good news for software and solution architects.If you’ve been reading some of the newer technical literature, such as the Pro [Microsoft] BizTalk 2006 book, you would have noticed one paramount shift in the book’s introduction part.First the authors provide the core overview of the BizTalk architecture, as expected, but then spend the next chapter going over various human and organizational aspects of running a project.This is important. This shows a conscious effort on behalf of the authors to convince the reader that establishing a technical and management structure is essential to the success of the project. The book provides brief guidance for setting up communication chain of command, provides an example of a rudimentary build and deployment process, and emphasizes on the importance of organization an…