Software development Architecture

• Architecture definition: With the non-functional requirements captured, the next step is to start thinking about how you're going to solve the problems set out by the stakeholders and define the architecture. It's fair to say that every software system has an architecture, but not every software system has a defined architecture. And that's really the point here. The architecture definition process lets you think about how you're going to take the requirements along with any imposed constraints and solve the problem. Architecture definition is about introducing structure, guidelines, principles and leadership to the technical aspects of a software project. Defining architecture is your job as a software architect but there's a big difference between designing a software system from scratch and extending an existing one.

• Technology selection: Technology selection is typically a fun exercise but it does have its fair set of challenges when you look at cost, licensing, vendor relationships, technology strategy, compatibility, interoperability, support, deployment, upgrade policies, end-user environments and so on. The sum of these factors can often make a simple task of choosing something like a rich client technology into a complete nightmare. And then there's the question of whether the technologies actually work. Technology selection is all about managing risk; reducing risk where there is high complexity or uncertainty and introducing risk where there are benefits to be had. Technology decisions need to be made by taking all factors into account, and all technology decisions need to be reviewed and evaluated. This includes the major building blocks for a software project right down to the libraries and frameworks being introduced during the development. If you're defining an architecture, you also need to be confident that the technology choices being made are the right choices. Again there's a big difference between evaluating technology for a new system versus adding technology into an existing system.

• Architecture evaluation: If you're designing software, you need to ask yourself whether your architecture will work. For me, an architecture works if it satisfies the non-functional requirements, provides the necessary foundation for the rest of the code and provides a sufficient platform for solving the underlying business problem. One of the biggest problems with software is that it's complex and abstract, which makes it hard to visualise the runtime characteristics from UML diagrams or the code itself. We undertake a number of different types of testing throughout the software development lifecycle to give us confidence that the system we are delivering will work when rolled out. So why don't we do the same for our architectures? If you can test your architecture, then you can prove that it works. And if you can do this as early as possible, you can reduce the overall risk of project failure rather than simply hoping for the best.

• Architecture collaboration: It's unusual for any software system to live in isolation and there are a number of people that need to understand it. This ranges from the immediate development team who need to understand and buy in to the architecture, right through to other stakeholders who have an interest from a security, database, operations, maintenance, support, etc point of view. For a software project to be successful, you need to collaborate closely with all of the system stakeholders to ensure that the architecture will successfully integrate with its environment. Unfortunately, architecture collaboration within the development team seldom happens, let alone the external stakeholders.

Delivery of the software architecture

It's the same story with architecture delivery too, where the software architecture role can vary depending on the level of engagement across the elements that contribute to a successful software project.