Since the term "Software architecture" has been coined more than 20 years ago, it became a fashion item to have in the project. In recent years, everybody who could barely operate a flip chart was deemed to be a fabled software architect, diminishing the true and crucial role of architectural decisions about a software system.

Grave consequences

The quality of software architecture is essential only for organizations who value the success of their software product across non-functional criteria: Reliability, performance, security and maintainability.

It's easy to see that nowadays, it is vital for almost any software system.

Getting it right or wrong – or having no clearly defined architecture at all, sets the stage for everything to come: The system's development, integration, testing, and modification. This stage may turn out hosting a romantic comedy, a gripping drama or a 3rd-rate, free-for-all acting school.

Checking and fixing an architecture early in the development cycle is relatively inexpensive. Fixing it later can be prohibitively expensive or even impossible. Lots of high-profile software projects suffer and ultimately fail because of this, no matter whether they were driven by classic waterfall or agile processes.

Developers and architects unite

When establishing or optimizing architecture for a single product or a complete product line, Codebox software architects work directly with development staff. This process can cover any number of architecture-related activities.

Codebox architects can participate in the development of a product architecture as well as train client staff in architecture-centric development and matching processes.

This flexibility helps Codebox' clients becoming proficient in all aspects of architecture-centric design for products or product lines.

Activity: Establishing the driving requirements

In the beginning, there are various options for a system architecture, testament of a typical mass of technical and business requirements – some seemingly of implicit nature, some brought forward and advocated by product stakeholders.

A careful analysis of these requirements can find the key drivers within them, enabling the architects to come up with approaches ensuring success for the resulting software product.

Skipping this analysis can lead to architectures which look strikingly elegant but eschew critical system properties. Or which try to be all-things-to-all-people, thus resulting in an overly complex hairball.

Activity: Defining the architecture

Once the driving architectural requirements have been established, fitting architectures can be developed accordingly. A coordination strategy can be set up to help develop suitable alternative architectures for the product or a product line.

Codebox architects can also help client staff in retrofitting product line architectures when individual products seem to develop an unexpected life of their own.

Activity: Evaluating the architecture

A decision between different alternatives for architectures can be a hard one as they are not immediately open to quantified analysis.

Therefore, Codebox architects work with the client staff to determine when and what methods of architecture evaluation are appropriate – and apply their results to come up with improvements and credible decisions.

Activity: Scoping the architecture

An architecture can be defined in varying breadth and depth. That's where the application developers should have their say.

The goal should be to establish just the right amount of system-design decisions within the architecture: Too few and the developers will overspend valuable time pondering high-level options. Too many and the developers will be too constrained when trying to overcome practical challenges.

Activity: Documenting the architecture

As long as the software product hasn't been completely built, the architecture is one major tool to allow all stakeholders to discuss the system's properties.

To enable those discussion, the architecture has to be documented in appropriate detail and in a form which allows developers and other stakeholders to access it easily. Determining which architectural views, which amount of detail and what form of presentation supports this goal best, is a joint effort of client staff and Codebox architects.

Software architecture: What is this for anyway?

Software architecture is a set of fundamental decisions about a product/solution, crafted to meet the project's requirements. As these decisions are the earliest made, they're the hardest to change later-on and the most critical to get right.

The architecture covers a software's main components, its vital attributes, interactions and behavior – all set up to meet the desired quality levels.

Usually, an architecture is expressed in several abstraction levels, depending on a project's size. If the architecture is intentional (rather than accidental) it should be communicated from multiple viewpoints to address the needs and interests of various stakeholders within the project.

The beauty of a well-planned architecture is that it not only serves as a blueprint for the product but also for the whole development project. Many organization and processual clues can be taken from the architecture to set up…

• The team structure
• The documentation organization
• The work breakdown structure
• Scheduling, planning and budgeting
• Unit testing and integration

What are software architects doing?

The actual planning is only one part of a software architect's vital activities which also include:

• Taking responsibility for the technical direction of a project
• Ensuring overall coordination, completeness and consistency of the architecture and systems engineering activities
• Making high-level design choices for software structure and usage of frameworks, protocols and algorithms
• Determining coding practices, development tools and validation requirements
• Performing pathfinding and surveying interesting/emerging technologies
• Communicating with inhouse and industry technologists, developers and project managers to evaluate the feasibility of requirements and determine development priorities

Your software: The process of making it click

Over the course of many projects big and small, Codebox gained lots of positive experiences when its clients felt as being a valuable part of the actual developer team, enabled by agile development processes.

Codebox has established an agile paradigm for all of their projects, using its own blend of Scrum and eXtreme Programming. This enables quick project set-ups, early results and beneficial, regular cross-checks of development direction with clients. And it's a lot easier to discuss feature-sets and interactions on a live version of the software rather than just descriptions and drawings.

Agile development, however, has its own set of challenges:

• When starting a project within an existing IT environment, integration issues require thorough analysis in order to avoid adding to existing technical debt.
• Documentation has to be updated more frequently to reflect ongoing decision-making after every release.
• Development has to be supported by a robust, broadly accessible set of tools where all team members can can track down decisions and changes from the requirements documentation down to the actual code, including its evolvement in a version control system.
• Architectural planning and right-sizing is more difficult, i.e. initial plans could be diluted early if not taken care of properly.

Having successfully mastered these challenges in many projects, Codebox does also offer special consulting services on architecture and development with agile methods and structures.

To get a robust footing, Codebox conducts an initial consultancy phase for a new project to identify to the guiding parameters:

• Learn about the driving principles in the client's set-up
• Understand the business requirements from a broad point of view
• Discuss the minimum footprint required to reach the desired business goals
• Determine the major quality parameters which are paramount to lead developers later-on in making minor decisions

Now that Codebox knows quite a bit about the size, target, environment and load of the project, they decide about which foundation to use as it's not always the most efficient to start with a blank sheet. The Codebox team is proficient in integrating all major open source platforms and products with its own libraries and newly created code.

From this point onward, Codebox enters the "normal" Scrum mode, with its time-boxing and "release early, release often" paradigm. The client is included whenever possible into sprint reviews, usually taking place in audio and video conferences.

This is not only a great way to build confidence but also helps boosting the team's efficiency through continously growing understanding of the client's concerns. The higher investment from the client's side in these regular meetings usually pays off very well.