Showing posts from 2009

Anyone can takeoff, can anyone land?

Oh prototypes. We love them, clients love them, users love them. They help with requirements and sometimes help us answer architecturally significant questions.
But early success creates a false sense of security. A successful prototype that a senior manager or a customer loves cannot always be operationalized in a matter of days or weeks. If fundamental quality attributes of software have not been thought through (e.g. security, scalability, performance, etc.) it's impossible to add that on later.
Solution? Manage the expectations of your audience. Explain the limitations before they see a demo - and discuss next steps right after prototype presentation.
Developing software intensive solutions without thinking through architecture is like taking an airplane into the air. Anyone can take off, but only pilots can land.
Constantin Kostenko
Firebrand Architect®

12 dimensions of the space of architecture

On what dimensions may the discipline of software architecture change over time?
Here is what the thought leaders in the field put together during the IFIP Working Group 2.10.
12 dimensions of the space of architecture:codification and socialization—processes by which an architect communicates architectural ideas to stakeholders. Codification refers to specification of the architecture, while socialization refers to the less formal processes by which the architecture is internalized. Socialization can happen through conversation, training, and so forth. Codification and socialization are complementary processes; they should enforce each other.0—Codification and socialization do not occur.10— Codification and socialization are in balance with each other; socialization becomes a process for codification; socialization and codification enforce each other and work in a global environment.handling quality attributes0—There is no consensus on quality attributes.10—Quality attributes are linke…

Wiki for Architecture Documentation & Managing Your Project

The idea of using a Wiki to manage coordination and artifact development as part of your software development is not new. The concept and tools have matured to a point where even the most monolithic organizations involved in development of large software intensive solutions are using this.
The goal of using a Wiki is simple: keep artifacts current through collaborative ownership.

The multitude of successful open source projects using a Wiki based approach is the best justification why a community based approach works. Additionally, a perspective from academia centric sources, with associated analysis, will help you build a business case.
If you're considering pursuing a Wiki based approach consider the following resources: Experience Using the Web-Based Tool Wiki for Architecture Documentation (thorough and free report based on actual project experiences - SEI). Blurb.On-line collaborative software development via wiki (from Proceedings of the 2007 international symposium on Wikis -…

Where portability matters

What's a good example of a software solution where portability is a paramount design quality attribute? Tethering software for mobile phones. PDANet, an application developed by June Fabrics, is a good example where designing for portability is a top design concern.
Portability is defined as the ability of a system to run under different computing environments. The environment types can be either hardware or software, but is usually a combination of the two. (Definition source)
PDANet enables PDA owners to convert their device into an Internet connection. It's hard to say if the talented folks at the June Fabrics initially planned to expand their PDANet software to other mobile OS vendors, but this application is a prime example where portability matters.
Currently PDANet supports Android, Palm OS, Windows Mobile, BlackBerry, and iPhone. While the operating systems are fundamentally different and provide different level of services to developers, the architectural drivers (i.e. …

Impact of organizational politics on software design

What is the impact of organizational politics on software design? This is a question I raised three years ago in this post and the time has finally come to attempt to answer that question.
We, as software solution stakeholders, make conscious and subconscious decisions that have a profound long-term effect on the usability, maintainability, cost, security, implementability, any-ility of a software solution. But how often are these decisions based on our personal and career motivations? Are we aware of this? Is it a good or a bad thing? If my career is centered around a certain vendor (e.g. Oracle and Java) should I or even can I viably consider technology from other vendors (e.g. SQL Server and .NET)? Would I have enough technical knowledge?
If you have an immediate thought on the impact of organizational politics on software design please leave a comment. And look for a formal invitation to fill out a survey in the very near future.
Constantin K.
Firebrand Architect®

Essays by Paul Graham

Paul Graham is an essayist, programmer, and programming language designer. If you haven't read his essays on programming and software engineering you should consider.
His latest essay on Apple's iPhone store is a good read on how business models that work for product n may not work for a product y. In this case Apple is treating iPhone apps as if they were iTunes songs, and Apple being the broker between the consumer and software producer. The nature of the development process of the iPhone apps requires frequent, if not daily, iteration of software releases, while Apple favors a lengthy review cycle before an app is published in its stores. What will it take for the developers to switch platforms? When will Apple become the evil empire? You can find the latest essay here and the rest of the essays here.
Subscribe to this blog via RSS.
Constantin K.
Firebrand Architect®

Pricing Software

We're in the business of software. That's why we all care, directly or indirectly about its pricing. Pricing affects everything - our salaries, benefits, profit. We also care about pricing because we're all are buyers of software (COTS, GOTS, development tools, etc.). And of course with respect to computer systems the cost of software exponentially outweighs the cost of hardware.
The new book, Don't Just Roll The Dice - A usefully short guide to software pricing, is a quick read, mere 84 pages, raises the right questions to get you thinking.
"How do you price your software? Is it art, science or magic? How much attention should you pay to your competitors? This short handbook will provide you with the theory, practical advice and case studies you need to stop yourself from reaching for the dice." Download a free copy here or get an a physical copy from Amazon.
Constantin K.
Firebrand Architect®

Software engineers are also your solution architecture stakeholders

It's easy to forget that the software engineers on your development team are also your stakeholders. They need a particular view of solution architecture in order to understand how they fit into the development ecosystem.
Expect to be challenged. As you walk through your vision or proposal for how a solution should be analyzed and architected be prepared to field questions from developers. More importantly, be prepared to answer those questions from developer’s point of view using terminology and analogies they understand. Since software architecture concepts deal with systemic issues of a software solution that extend beyond the routine scope of a software developer, be prepared to also educate developers on why it’s important to evaluate and address crosscutting solutions needs. You’ll have to demonstrate why a software architecture centric view is necessary and why a given approach (e.g. concentrating on architectural drivers early on) best suits a given situation. And of cours…

Need experience planning for and executing a long term project? Run a marathon.

This thought came to me on mile 21 of the Marine Corps Marathon that I ran and finished on October 29th, 2009. Planning, training for, and running a marathon is similar to executing a long term successful project. Both activities require superior commitment, strategic planning, progressive results, and a clear goal.

A marathon is different by definition - it's a solo event. However there are some points of interest.

- Goal. For a marathoner a goal is clear - finish the race in a given time period. A successful project must have a clearly defined goal that can be achieved and measured.
- Planning. Superficially it may seem that planning for training is easy. However poor planning will prevent you from training properly. And you won't be able to catch-up later (an equivalent of Fred Brook's motto of adding more people to a project that's already late will only delay a project). Long runs must be planned - including a day before and runs during the week. Planning for a long…

adding complexity to reduce complexity

In a recent Software Engineering radio episode Markus Voelter in his interview with a guest described complexity as energy. More specifically he talked about the law of conservation of energy (energy cannot be created nor destroyed, it can only be transformed). The topic of complexity can be viewed similarly.

By addressing some nuance of complexity in a project (e.g. growth of a team) we're applying tactics (e.g. hire a manager) that may solve the issue of coordination, but introduce the issue of bureaucracy.

We have come to accept these unattended consequences (or collateral damage) as a fact of life, but it's good to remind ourselves to question why we choose one tactic over another. Some of our "trivial" decisions are binding with no undo button.

Constantin K.
Firebrand Architect®

See the ecosystem, not the forrest

As a software architect one must see a forest and not just trees. As a Firebrand Architect® one must see an ecosystem and not just the forest.

Constantin K.
Firebrand Architect®

Architecting Windows 7

"To Rebuild Windows, Microsoft Razed Walls " is the title of an article in the October 20th 2009 edition of the Wall Street Journal.

There is something interesting about Microsoft's software development approach taken for Windows 7.

The article attributes the perceived initial success of Windows 7 to a different, more humble, approach taken by Microsoft and the Windows 7 team. While the quality of the operating system is yet to be determined by the real world tests it appears that the design and execution of the product was different.

"A key problem was that the Windows team had evolved into a rigid set of silos—each responsible for specific technical features—that didn't share their plans widely. The programming code each created might work fine on its own, but cause technical problems when integrated with code created by others."

This article exert contains a key observation. Operating system development can be viewed as a set of semi-independent silos unit…

What kind of leader are you?

An architect role is a leadership role - that's a fact. Your leadership style and your capability to lead will enable or cripple your team.

There are many leadership gurus with thousands of books on the subject. For the purpose of this post and to keep things simple I'm using John C. Maxwell's five levels of leadership strucutre. I've been to his lecture and I like the simplicity of his approach. John's repertoire of books is significant (, but at its core the following structure stands.

Level 1. People follow you because they have to.
Level 2. People follow you because they want to.
Level 3. People follow you because of what you have done for the organization.
Level 4. People follow you because of what they have done for them.
Level 5. People follow you because of who you are and what you represent.

The first level is self explanatory.
At the second level your leadership depends on the relationships you build with the people. At this level you're conne…

PDC 2009

If you're on the Microsoft bandwagon, then PDC 2009 is for you.

Constantin K.
Firebrand Architect®

You, as an architect, must take the initiative

Simply by having an "architect" word in your title or role description automatically puts a heavy burden on you. Automatically people will assume, and rightfully so, that you have the responsibility of gathering and synthesizing information and making early design decisions. Your colleagues and stakeholders will expect guidance from you - well before and after the official software design phase commences.

As an architect you should be very well aware that you're under a spot light at all times. Nobody will ever tell you that the right time has come to start architecting. If someone has to tell you that now is the right time to start architecting it means that you're not paying attention. There are, of course, times when it appears that no action is required. For example, requirements are too fluid and insufficient to start designing, or a business case for a solution has not yet been well defined, or perhaps the funding has not yet been approved. The times of uncertai…

Interviewing future leaders at Carnegie Mellon - Heinz College graduate students

It's truly inspiring to speak with young graduate students who passionately feel about positively changing the world. This week I was asked to join a small team interviewing graduate students (Carnegie Mellon - Heinz College) who are seeking employment in late winter or late spring to put their degree to a good use.

The most exciting part of the interview was seeing how most students in my group were able to discuss concrete problems from an end-to-end perspective. Here is a general observation about the future leaders:
- they can effectively organize and leverage team members' time and skills; they are have a disciplined and patient approach for deciding who would lead and how the tasks should be distributed
- they continue to learn and care a whole lot about learning opportunities their employer offers
- they are open to new ideas and observations; change is not a distant concept, it's a way of life
- they are data driven at all the right places; they understand the value of …

You can't rely on your knowledge of patterns alone to architect

Design patterns are used for solving a specific known (routine) problems using a prescribed approach. For architects the patterns are the building blocks of the systems we create. An architects needs to have a working knowledge of a diverse library of patterns spawning various levels of granularity and applicability relevant to his or her domain.

It's important to note that all patterns fit somewhere on the spectrum of design decisions. All patterns can either be refined by lower granularity design patterns or rolled-up into larger patterns. However there are exceptions to these rules impacted by strategic vision and availability of resources (constraints). This is what makes architecting fun.

Constantin K.
Firebrand Architect®

Example of a solution not fit for purpose

Five years ago I architected and (with a small team) implemented a COTS centric solution (Microsoft and ProSight technologies). The design process was supported by clients and all phases of SDLC were executed well. Architecturally significant decisions were made based on factual findings. For example, after an evaluation of enterprise environment we concluded that the necessary bandwidth required by COTS software wasn't available and a decision was made to allow select user groups to access software directly on a server via a remote desktop connection. Other user groups would use web interface for simpler tasks. We estimated the number of users, application load cycles, data call spikes, etc.

In the end we crafted a seven sever solution with load balanced web front ends, separate logic server for data crunching, and a set of very powerful database servers (in 2005 fully loaded HP ProLiant 570 were the best of breed).

At UAT the solution surpassed technical and usability expectations…

What exactly is "fit for purpose"

Firebrand Architect® adopted the "software fit for purpose"™ mantra for a very good reason. It's the architect's job to make and bear responsibility for decisions that can make or break a software solution. Of course an architect is not the only factor in the success of a solution, but clearly early design (and approach) decisions come with high cost.

Deciding on what's fit and what's not fit, and how to reach the right balance, is a subjective and difficult question to answer. This is why software architecture (and various other flavors of IT architecture) will always be part science and part art. This is why there will be more and more architecture specialists (e.g. security architect, performance architect) over time as complexity of software solutions (or rather system of systems) grows. And this is why architects of all flavors need to have a well rounded understanding of the operating environment - including human aspects.

In order to convince oneself tha…

Software Engineering education for your clients and customers

This is not a "how to" post, but a reminder to build in time for client and customer education on software engineering. There is only one person in this world that thinks exactly like you, and that's you. Everyone else around you, even your long term colleagues, have a different perception of problem, solution, and approach even if you work well them.

This observation calls for two actions:
1. Build time (directly or indirectly) into your project to educate your clients and customers on the discipline of software engineering and software architecture. You'll have to spend time convincing them that a disciplined approach to creating software is not a choice, but the way of life.
2. Create a mini curriculum, or at least talking points, ahead of your engagements with clients and customers. You need to be proactive in your education sessions and they always should be done in the context of a specific business problem or a solution you're working on.

If a client or a cust…

Writing down solution concept - a practical quick start guide

As an architect you’ve been tasked to come up with a business and technology solution. Where do you start? You probably have a lot of ideas and concepts in your mind. The best way to get started is to offload your ideas and concepts into a list – or better yet on paper or whiteboard (or Visio). As you dump ideas down you’ll be tempted to expand and link the concepts right away, but first concentrate on writing everything down.

The next step is to create a “back of a napkin” business perspective of your solution. What are the key components and functions? Perhaps a shopping cart, an inventory management thingie, a brain to pull it all together, and a payment processing element. Use whatever media you’re most comfortable to quickly sketch a business architectural cartoon. Show how things are linked.
Allocate all elements from your list at this stage.

The disciplined part of you may be tempted to think about decomposition using proper architectural perspectives (static, dynamic, and physica…

Using consultants for big picture insight

Few software engineers and software architects have the privilege of being meaningfully involved in so many initiatives that they see the big picture of where the organization is going. This does not apply to all architects and all organizations, so this tip is for large organizations.

If your organization is using consultants to help on various projects you should consider tapping into their experiences for a big picture perspective. Yes, they will ask you to fund the time they spend gathering the data and creating a presentation, but the insight may be worth the time and money. It’s always very beneficial to have a third party provide feedback on the elements you don’t have time or ability to see.

Caveats: only work off the existing trust level. If there is no trust between you and a consulting group you won’t benefit from provided insight. Pay attention to the recommendations and the consultants’ line of work – they may be consciously or subconsciously selling you more work (and you …

What breaks my heart

In a fruitful conversation with this organization's software evangelist we discussed the right (economical, efficient, simple, verifiable, results centric) approach for designing a solution to address a pressing knowledge management problem. The explosion of electronic data over the past ten years has really caught up now. The solution would use organization's existing infrastructure assets (both software and hardware) and can be implemented to serve 4,000 users in the production environment under 6 months with 4-7 FTEs.

Evangelist's caution statement? Political barriers within the core IT organization won't allow for creation of the system, because it doesn't include the other 20,000 employees in other divisions who may need something similar. This is the heart breaking part. The core IT organization cannot dedicate its resources to reduce the burden for 4,000 employees, and lack of trust between a business division and the core IT organization prevents business un…

Turbulent times

At this organization the tenure of the senior leader post is closely resembling that of a Bank of America CEO. The post length is now measured in months and not years.

Superficially it appears that the changes at such high level do not influence the design of software systems. But upon taking a closer look it quickly becomes clear that changes at the top have a direct impact on your software design decisions. To recap the flow: the world events influence customers' decisions, corporations adjust to serve customers, CEOs and senior leaders set objectives and goals to maximize profit on sales to customers, measures associated with objectives and goals influence the business processes, software exists to support business processes, and company employees use software to deliver value to a customer.

Only in the most mature (or highly bureaucratic organizations) the change at the top has marginal effect on organizations, but in this economic environment with ever changing business models …

Paul Nielsen, SEI Director, brings awareness to software engineering issues in front of the U.S. House of Representatives

A big part of what we, as software architects, do is educating our stakeholders on why it's critical to take a disciplined and rational approach to developing software. Very few managers, directors, and executives know or care about the internal complexity of a software solution. Their attitude, and rightfully so, "just make it work." It's good to know that people like Paul Nielsen, SEI Director, find time to testify before the U.S. House of Representatives to raise awareness of the growing complexity and importance of large scale software intensive systems and their importance to our day-to-day lives.

Constantin K.
Firebrand Architect®

Conway's law

Conway's law: "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."

Constantin K.
Firebrand Architect®

Take control

Being a firebrand architect at times requires assuming control of a situation even if you are not the primary owner of a project or an initiative. It often means taking on more responsibility than you expect just so that you can do your job later.

Imagine a coordination teleconference between twenty people from over a dozen different IT and business functions. The objective is simple: move a server from one domain onto another without breaking the existing solution on that server. Everyone on the call plays a role and an agenda unifies the participants for the duration of an hour. However no progress takes place - the current executive owner of the server gave a green light for migration as long as his technical team is comfortable. Yet the technical team (two developers) lack the enterprise wide knowledge to fully explain what services, data, and support they need and how their solution has been setup. In this case a COTS based application reaches out to various data sources and allow…


Whether we want it or not, we, as software (solution) architects have to specialize in a bounded business domain and a bounded array of technologies. The required depth of knowledge depends on the type of architecture work you do.

While finding the "golden balance" is an obvious observation, a helpful reminder for you is to review your "golden balance" once every quarter and don't be afraid to re-define what you mean by your balance. It's natural for people to change - some become more specialized and technical, others pull up and specialize in a macro view. If you move a lot between low level and high level architecture you'll experience "turbulence" - and that may be OK if that's how you define your balance.

Constantin K.
Firebrand Architect®

Microsoft Technology Center in Silicon Valley

Having worked for two startups I was not surprised to see glass enclosed server room positioned prominently to the side of the main work area. After all this a customer centric facility where select Microsoft customers are invited to spend time with the best and the brightest Microsoft hands-on technologists.

But it was not the stacks of the latest hardware with its neatly tucked cables in dust free racks that impressed me. Not even the myriad gizmos such as a touch screen HP's desktop and a Microsoft Surface. What impressed me are the people who worked at the Microsoft Technology Center in Silicon Valley on my recent trip in July 2009.

For the duration of the weeklong stay the hosts ensured that all our activities stayed within the scope of the business problem we defined on day one. And that's the key. The hosts took time to understand the business and concrete problems in the context of an end-to-end scenario. They adapted quickly to our team's terminology and collecti…

Seeing The Big Picture

In any organization - large or small - we make assumptions about new people who join a project or an initiative. First impressions matter, and while first bad impressions can be reversed over time, it's better to start on the right foot. While this is not news to you, it's important to remember this. This is especially important for a person who aims to act like a Firebrand Architect® since such behavior and action may be perceived as negative and derailing.

This set of reminders may help you:
- Listen to understand
- Understand the other person's point of view
- Learn what others are doing and why - conduct preliminary independent research
- Understand different roles colleagues play. Then understand your role
- Ask intelligent questions - advance conversation with your questions
- Speak slowly - this will allow you to formulate your ideas more clearly
- When replying pause to allow others to respond before switching topics. If you hear (or feel) that others are trying to speak w…

soft skills

Great blog post on recognizing the importance of the ever changing soft skills with respect to delivering technical solutions. Link.

festina lente

"I don't think much of a man who is not wiser today than he was yesterday. " ~Abraham Lincoln

Learning is essential in every discipline and architects often carry a double duty of learning both the technical angle and the business angle. But there is another angle that you, as an architect, must learn, and that's the human angle.

In a recent three day working session with a rapidly developing project I was following the well defined path of working with the clients through the core business processes, defining technical pieces of a potential solution, etc. Early on I was fortunate to realize that despite coarse grained requirements provided by the team there wasn't much substance (conceptual integrity) in what was said by the stakeholders.

That was a clue to take extra time to understand just how much and how well the stakeholders understand the business problem at hand. By listening and learning quickly from them I re-scoped the day's discussion and concentrate…

patterns & practices - Application Architecture Guide 2.0

"This guide provides design-level guidance for the architecture and design of applications built on the .NET Framework. It focuses on the most common types of applications, partitioning application functionality into layers, components, and services, and walks through their key design characteristics.This guide is a collaborative effort between patterns & practices, product teams, and industry experts."

It's a useful guide, but use with caution. At times the authors confuse the perspective. For example a "tier" is used interchangeably with a "layer." This is not correct since a tier is usually defined to exist in a run time perspective and a layer in a static perspective. All in all a very useful composition.

Constantin K.
Firebrand Architect®

Complexity in Software Architecture and a new architect role

Things are just getting worse for software architects. Relative stability of business models and computing paradigms of the 2000's has vanished. Making the right early design decisions has become very difficult. Keeping up with technical and operating environment complexity has become nearly impossible.

Humans deal with complexity through abstraction. With rapid growth of complexity in the software architecture domain (both business and technical perspectives) we're now seeing divergence of software architect roles. It's not possible to be a great security architect, a great performance architect, and a great general software architect at the same time. Recently architects have been specializing, often not by choice, to fit the business domains and their operating environments.

The important point is that a new breed of architect role needs to be officially recognized. It may be called a composer, orchestrator, manager, or a solution architect. In this role an architect w…

Fifth SEI Architecture Technology User Network Conference (SATURN 2009)

I "subscribe" to the general principles of the Software Engineering Institute's (SEI) software architecture paradigm. I apply various aspects of the approach in my day to day activities. If you're a fan of the SEI's work on software architecture you should consider going to their annual conference (May 4 - 7, 2009) to mingle with likeminded colleauges. Early bird registration is through March 31st. A 10% off coupon may be available if you're interested.

Link to the conference site.

Constantin K.
Firebrand Architect®

Analysis paralysis

Analysis paralysis is a common problem in the software requirements domain. Engineers or requirements analysts become overwhelmed with amount of information and get bogged down in details.

Software architects face a similar problem. If an architects seeks perfection or the best solution for a given problem he or she may get bogged down in the details of various design alternatives. A more effective approach is to invest time in understanding the key architectural drivers - the requirements that have a profound effect on architecture (i.e. critical functional requirements, quality attributes, and constraints). By quantifying your requirements (e.g. by using quality attribute scenarios) an architect will be able guide your decision making process through various design alternatives.

As Fred Brooks said - getting the conceptual integrity right is the most difficult, but the most important part of your job. To help you with this process you should use an iterative approach to developing arc…

The role of organizational politics in Software Engineering and Software Architecture design

This is a very important topic I've been examining for a number of years. While my Ph.D. work on "the cost of organizational politics on software engineering" is many years away it's important to raise the awareness of this subject matter.

The topic of organizational politics is not new. The concept surfaced in 1958 and in early 1980's the topic was actively studied and analyzed. There is no definitive guidance since it's a challenging topic to study; after all this is about the behavior of people. There are many factors that shape the game of politics: individual values and ethics, organization's structure and the way of life (e.g. "cooking books"), environmental conditions (e.g. market stress), and performance reward criteria (e.g. measuring and rewarding the wrong results). What's clear from research is that there is a distinction between an actual political behavior and a perception of a political behavior. For a software architect it…

Insights from vendor panel on Cloud Computing (FOSE 2009)

The leading providers of Cloud Computing services (IBM, Microsoft, Google, and Amazon ) gathered for a panel discussion at FOSE 2009 organized by Booz Allen Hamilton.

- Standards have matured significantly over the past few years for both Software as a Service and Infrastructure as a Service.
- Significant gains have been made with respect to interoperability, but until vendors develop a usable way to collaborate adoption will be difficult.
- Trust will make or break clouds. Security is still a big issue - IPv6 will help.
- Private clouds are likely to come first before commercial clouds become widely used.
- A cloud provides substantial benefits when economy of scale is reached.
- Any organization considering cloud computing needs to develop and understand its total cost of ownership (TCO). Cost standards are not mature.
- Cloud Computing is not SOA.
- Cloud Computing maturity level models are being developed (Booz Allen).
- Demand for Cloud Computing has been established - ther…

Cloud Computing Wargames at FOSE 2009

Booz Allen Hamilton held Cloud Computing Wargaming sessions at FOSE 2009 (March 10 - 12th 2009). This wargame simulates the thinking process and the choices IT decision makers have to make in real world as they develop organization's capabilities to meet business or mission challenges. The goal of the exercise is to get the players thinking about the tradeoffs between different computing resources, associated costs, risks, and resulting benefits.

Cloud Computing is not a new concept, but with rapid progress of standards and maturity of technologies "on demand" computing has become a viable option for many organizations.

During the 90 minute session a table competes against six other tables. The goal of the game is to collect Mission Value Points (MVPs). A team obtains MVPs upon successful completion of tasks. To complete a task a team must build a set of capabilities required to support a task. A capability can be built in "Traditional IT", "Hybrid Cloud&quo…

How Business Goals Drive Architectural Design

How do quality attributes affect the architectural design of a software solution? If we only cared about the functional requirements of a software solution, then any architecture and any implementation would suffice. Further, how business goals drive architectural design?

The topic of translating business goals into architectural drivers merits a separate post, however this article from the August 2007 edition of the Computer magazine (IEEE Computer Society) eloquently demonstrates how the architecture of a software solution changes as business goals are refined into quality attribute scenarios. Application of architectural patterns and refining tactics significantly alter the architecture of a software solution.

Constantin K.
Firebrand Architect®

Architecting Software Intensive Systems: A Practitioners Guide

In summary of chapter 5, The Work of an Architect, the author notes that "… this is not intended to be a definitive statement on how to architect. Architecture design is guided by the intuition and judgment of the architect. The purpose here is to provide principles and guidance for how tot think about decomposing a system, what to consider when decomposing the system, and how to capture key design choice and rationale." This chapter alone is worth the price of the book, Architecting Software Intensive Systems: A Practitioners Guide, as it proves invaluable guidance in a clear and concise manner.

Make space on your bookshelf that's located closest to your desk. Buy this book. Use this book.

Few practitioners have the level of depth and breadth necessary to eloquently capture and explain the practical aspects of the software architecture discipline. The author, Anthony J. Lattanze, explains the critical need for separating perspectives (static, dynamic, physical), explains…

The process of learning the principles of software architecture

This is my second year serving as the distance education instructor for Carnegie Mellon's Principles of Software Architecture course. The distance education course is aimed at working professionals and has the SEI Software Architecture paradigm as a backbone. The course is based on the same material taught in the Masters of Software Engineering program at the Carnegie Mellon by David Garlan and Anthony J. Lattanze.

I spend time interacting with students through conference calls, class bulletin board, emails, and assignment grading. It's very interesting to see how professional software engineers and architects with many years of experience learn new ways of thinking and reasoning about software architecture. This experience offers me a unique perspective to see how people learn about a disciplined way of thinking about the art and science of software architecture.

Experienced software engineering professionals who design and build non-trivial software systems as part of their …

Simple Architectures for Complex Enterprises

Measuring complexity of business processes and software solutions that support them is a difficult task. Roger Sessions in his Simple Architectures for Complex Enterprises book provides an excellent math (logic) based approach for examining Enterprise Architecture complexity without getting into formal methods. The philosophy behind the approach is superb and refreshing. The chapter on technology approaches will be obsolete soon, but chapters 1 - 5 will be applicable for years to come.

Constantin K.
Firebrand Architect®

A new era of responsibility

As president Barack Obama was delivering his inaugural address on January 20th 2009 I was taking notes on how his theme of a "new era of responsibility" will affect my clients and my colleagues. Software architects have a tremendous power to make or break a system. With such power should come a great level of responsibility. But how often do you hear architects taking full responsibility for the design of a software solution? How often do you hear architects clearly justify why a certain design was chosen among an array of alternatives and how specific tactics will address domain specific business needs? Just check any software licensing agreement: [company] makes no warranties, express or implied ...

Has the time come for responsible software architecture and responsible software engineering? As a software architect how will you handle a new era of responsibility?

Constantin K.
Firebrand Architect®

Dealing with the bus problem

When a "bus problem" becomes a reality it's critical to address the human needs first. This post does not provide guidance on how to deal with loss, but if you're in a leadership position you need to know how to appropriately respond or where to go for help.

Ultimately if you hold a key position in your organization (e.g. reputable architect or a trusted advisor) you may be called upon to help right away. Your first order of business should be to get the software solution up and running by all means necessary. Be prepared to look at the source code, log files, incomplete documentation, conduct interviews with frustrated users. You will be looked upon as a savior whether you're ready or not, so you must be prepared to act like a Swiss army knife. In this situation the pressure is high and failure is not an option.

Here are the guidelines to help you think when under pressure:
- Create a plan of action. Write down everything you think you need to do. Use this list as …