Hitchhiker's Guide to Software Architecture and Everything Else - by Michael Stal

Thursday, July 23, 2009

May the force be with you

Sometimes it is getting confusing. There are so many influential factors driving software architecture. Here is my small domain language
  • Forces is the set of all influential factors an architect is facing: requirements, risks, constraints, business needs.
  • Requirements are the (documented) set of all expectations for a software system. According to Wikipedia a requirement represents a necessary attribute, capability, characteristic, or quality of a system in order for it to have value and utility to a user.
  • System requirements address the system as a whole. From system requirements we need to derive architecturally relevant requirements that drive architecture and design. That is the architect's job.
  • A Functional requirement defines functionality a system is supposed to provide, sometimes also known as capability. Use cases are functional requirements. They define what the user expects from the system on a black-box level. User stories according to Wikipedia denote software system requirements formulated as one or two sentences in the everyday or business language of the user.
  • A Non-functional requirement (also known as quality requirement, quality attribute or "ility") is constraining a solution. There are two subcategories here: operational requirements as the name suggests constrain the runtime behavior of the system (e.g., security, performance) while developmental requirements constrain the design from a developmental perspective (e.g., maintainability, modifiability). As operational requirements often have a systemic approach to a system they are subject to architecture design and therefore are also called strategic requirements. Tactical requirements such as modifiability mostly have only local scope.
  • Constraints - what a surprise - are constraining the solution. A constraint might be technical (we need to use Windows 7 as our OS), organizational (subsystem A should be developed at location A), standard & law (we must abilde to FDA rules), business-related (target costs should not exceed xxx$).
It is the job of a software architect to base all decisions on the forces of the project. Still she/he has sufficient freedom to make architecture and design a complex task. Architecture is about communication and courage to decide.

Monday, July 20, 2009

No future for architects?

I am a big fan of Star Trek, especially of The Original Series and The Next Generation. From a technology viewpoint, it is amazing how all of these technologies such as warp drives or beaming have influenced science. Did you know that the inventor of the mobile phone had also Star Trek in mind?

However, there is one sad aspect. What about Software Engineering? Whenever software plays a role in any of the episodes, you’ll recognize Spock or Data just coding. Do they ever design? There is also no software engineering team in the Enterprise although software should be an important asset in the system architecture. I am missing a chief engineer for software engineering aspects!

Does the computer program itself? Will UML disappear in the future? Or is it just software engineering being too boring for SciFi fans? Interestingly, there are also seem to be no restrooms in the spaceships. This is what they have in common with software engineers :-)

Thus, we could ask how software engineering especially the discipline of software architects will evolve in the future? Will we still use a successor of UML in hundred years? How could the role of software architects evolve?

The best approach to predict the future is identifying space of improvement. It is very likely that such areas will be addressed. How should the ideal process of software design look like? What is the software architect supposed to know and to do?

In most SciFi movies automatization/Model-Driven Software Development and AI are often the answer. Architects express their intent, smart systems then try clarify open issues, and eventually the result is generated.

Another approach could be an organization like the Borgs who strongly follow an agile approach with code ownership, collective programming and test-first.

Any opinions?

Keep in mind: Resistance is futile!

Sunday, July 19, 2009

RRC Card

Most of you already know the CRC (depicting Class, Responsibilities, Collaborators) which is a low tech technique for discussing software artifacts in brainstorming sessions for software design.

I propose another kind of card for depicting the roles in a particular project: the RRC Card: Role Responsibilities Collaborators.

The idea is simple:

  • The first R stands for role by which I mean a concrete person and her/his role
  • The second R stands for Responsibilities: what responsibilities should this role have to meet its expectations
  • The C stands for Collaborators: from which other roles does this role depend, e.g., with which other roles must it interact

If you start with a project, you could ask the parties involved to jointly fill out these RRC cards, thus making clear how responsibilities are partitioned and how roles are supposed to interact.



R: Michael / Architecture Consultant


Responsibilities                        Collaborators

Mentor and coach                    Lead Architect: Paul

Help design                             Architect: Tom




If you already in a project in deep trouble you could ask persons to fill out how they live their own role and likewise fill out RRC cards for other persons, thus identifying conflicts between expectation and reality.

Document these RRC cards in a document (e.g., paper-based or Wiki-based)

Saturday, July 18, 2009


In addition to requirements and business expectations, risks represent an important driver of architecture design activities. Not addressing risks appropriately is a major reason for project failure. But what exactly is a risk and how can I identify potential risks as an architect.

On a very coarse grained level, risk might be considered as not knowing the outcome of an event or activity. It is the threat or propability that “an action or event will adversely or beneficially affect an organisation's ability to achieve its objectives” [Wikipedia].

There are as many different types of risks in a  software development project as there are influential factors.

For example:

  • Technical risk: Is EJB the right technology for achieving 100000 transactions per hour in our Web store?
  • Organizational risk: Is the organization appropriate for this kind of development project?
  • Political risk: Does this product manager follow her/his hidden agenda? Is this supplier really trying to support us or is he in fact competing with us?
  • Design Risk: Is this design decision appropriate for dealing with the requirements?
  • Requirements risk: Do we really understand the requirements of our organization or the customers?
  • Process risk: Is this the right development process?

For dealing with risks, there are lot of different ways. Technical risks and architecture risks can be reduced by a requirements-driven, test-driven approach with explicit assessment activities and refactoring activities. Political risks require the architect to communicate and lead efficiently and effectively.

An important point is this context: to be able to deal with risks, we must make them explicit. Implicit risks are often overseen, forgotten or ignored. You should really know your “enemy”.

Making risks explicit means to document AND communicate them.

I recommend to introduce a template for risk assessment comprising:

  • Name of the risk
  • Priority/Relevance of the risk
  • Type of risk: organizational, technical, ….
  • Rationale: explain why this is a risk
  • Context: what else should we know when dealing with this risk
  • Strategies: possible ways to deal with the risk
  • Decision: the recommended strategy to deal with the risk for the concrete context, and the rationale for this decision
  • See also: other risks this risk implies or similar risks that could be treated with the same strategy

Not all of these fields need to be available in the beginning. You could start with name, type, context, thus collecting the risks first. Then, you could prioritize the risks, and eventually extend the templates for this risks identified as high risks with missing information.

Let me give you an example:

  • Name: Uncertainty Using EJB
  • Priority: high (******)
  • Type: technical
  • Rationale: capability to meet the performance requirements of 100000 transactions/hour. We are not sure whether EJB will be appropriate
  • Context: Our developers are not experienced with EJB
  • Strategies:1) Build performance prototype first. 2) Hire external expert. 3) Use Enterprise OSGi instead. 4) Outsourcing.
  • Decision: Hire external consultants. Let them build a performance prototype and then help implementing the system when EJB proves to be a reasonable choice.
  • See also: we are not sure whether MySQL can cope with the throughput requirements.

It is worth mentioning that risk assessment is not exclusively provided by software architects. In fact, all roles in the project must help and closely cooperate for risk assessment. This way, everyone involved is aware of potential risks. And of course, some risks such as those implied by organization, test quality, or quality of requirements must be identified and clarified by other roles such as product and project management, requirements engineering or test and quality management.

Architecture and design decisions should then take risks into account.

Mind the risks: The highest risk is not systematically dealing with risks. 

Friday, July 17, 2009

Who is responsible

Suppose, you are working in a software development project as a software architect. You are still waiting for the requirements to be available in sufficient quality and quantity and priorization. Even after months almost nothing happens. Sure, the problem is caused by requirements engineering. But what is your responsibility as an architect? Your responsibility is to communicate and escalate which requires courage. For example, you could tell the stakeholders what implications the current situation might have - for example, you cannot start with architecture design which means development cannot start with implementation etc. You should never fall into the "this is not my job" trap. After all, software architects need to drive the project. Sometimes, it might be even possible to take responsibility for requirements as an architect but this should be the exception not the rule.
Similar issue for test & quality: if test coverage is only limited, bugs are seldomly found during testing, or tests themselves are faulty, then you could finger point to testers and developers. However, it is your job as an architect to deal with quality. Don't try to escape your responsibility in this area. Test First Design makes it very clear that testing requires the different roles to cooperate.
What about business aspects? I know, you got this product manager who is in charge of all business aspects. But software architects are responsible in helping develop the technology roadmap, identifying patents, estimating the business implication of architecture decisions. Even more, architects must base every architectural decision on requirements and business needs.
Hmmh, what about project management? Of course, an architect should not be forced to also act as a project manager. These two rules are very difficult to live at the same time in the same project. But what if project management needs to estimate costs and resources? Here the software architect needs to provide support. What skills do developers need? How many developers and how much time are necessary to develop subsystem A.
I don't claim that architects shuld be jack of all trades but masters of none. Their main focus should be on software architecture. However, they cannot ignore what is happening on the boundaries between software architecture and the rest of the project. They should feel responsible for project success.