The architect generally has the most experience on the team, and is capable of creating the most difficult pieces more efficiently than anyone else.
For many people, architecture is just about how code is organized. However, software architecture is more than that. Good software architecture is concerned with maintainability, reliability, portability, and scalability. In addition to how these crucial aspects of software design, architecture is also about how the software architect works in the team.
An Architect Who Codes
In some organizations, becoming a software architect is seen as a step up the ladder where you don’t have to code anymore, and instead are concerned with coding standards, approving common libraries, and creating diagrams for other teams. This approach generally keeps the architect somewhat removed from the team, less accountable to project goals, and also means they start to lose the feel for how good code is written “in the trenches”.
At SpiderLogic, the architect is an integral member of the team and is directly accountable to the project. More than that, the architect doesn’t simply create the blueprint for the project, and assign all of the code writing tasks to team mates. The architect writes the most difficult and integral portions of the code in the project. After all, the architect generally has the most experience on the team, and is capable of creating that more efficiently than anyone else.
By having the architect lay the code foundation of the project, it is easier for team members to follow that pattern and example to write better code, as opposed to only discovering high level coding mistakes during code review. This makes the code more maintainable from the very outset of the project.
Using such universal concepts as inversion of control and separation of concerns, code can be tested more easily at lower levels. By encouraging ubiquitous unit tests in the project, developers are less fearful of rewriting portions of code that have become too unwieldy. This reduces technical debt before it becomes a problem.
Architecting code for reliability is first about creating a system that can be tested at all levels. Code first must be easily unit tested. These tests are performed by the developer, before code ever makes it to source code control, ensuring reliability in the build for other developers, and for testers.
These techniques continue showing benefits in other areas of testing as well, as good architecture ensures that code can be easily regression tested. By allowing the testing team to create suites of regression tests, it frees the testers to test the software for more obscure problems, and improve the reliability of the final product even more.
Years ago, the first question an architect usually asked was, “Is this going to run on the desktop, or on the web?” Now the question has morphed into “How many platforms do you want to support?” In addition to desktop and browser based applications, many projects need to run on multiple phones, tablets, and other devices. Good architecture is concerned with reducing the amount of code that needs to be rewritten to support the ecosystem of devices your software needs to run on. This can involve writing Service oriented applications where common services are hosted in the cloud for multiple devices to connect to, or using frameworks that allow common code to be run on different platforms.
Applications that have small audiences today will hopefully have large ones tomorrow. Software needs to be designed to handle growth without needing to be rewritten every time this kind of success is achieved. Designing software that runs on multiple platforms also allows software to be divided among multiple computers to scale with increased load. Good architecture is more than those design concepts. Architecture is also about being able to work with systems operations who are maintaining your environment to find bottlenecks before they become a problem, and work with your infrastructure teams to plan ahead so that you are scaling ahead of demand, instead of scrambling to respond to slow systems.
Architecture is about how the code in an application is organized. It is about how the pieces that make up the whole relate to each other. It is about different components and where they live. This might sound like something only a programmer would care about, but in the end, architecture is the foundation for things that you care about too.