By and large, computer programmers are, by both nature and necessity, a detail-oriented bunch. It takes someone who can get down into the weeds, the world of bits and bytes, of ones and zeroes, to craft an effective program to make a computer do something useful.
And for a long time, that’s all that was necessary, because many computer programs were standalone affairs that didn’t need to interact with other systems. But then networks came along, and with them came big ideas about how computers and their programs could work with each other to accomplish so much more.
It turns out that, although making different programs work together requires substantial coding chops, you also need someone who can think about the big picture, about how to put these different pieces together to form an effective overall system.
Thus was born a new role in the world of software development: the technical architect.
Technical Architecture 101
The role goes by different names in different businesses and industries—“solution architect” and “systems analyst,” to name a couple. Here at AndPlus, we use the term “technical architect,” and we have a team of them who help define the scope of every project we take on. But what, exactly, do they do?
A technical architect has to think about how a piece of software fits in to the business environment in which it will be used. As such, the technical architect seeks answers to questions such as:
- Does this software need to be able to operate on its own, or does it depend on other software or systems?
- Will it share data and resources with other software? Where will the data reside?
- How will the software communicate with other software—directly, via system calls, or indirectly, through shared databases or other files?
- Where will the computational heavy lifting happen—on the user’s device, on a local server, in the cloud?
- What are the performance, reliability, and availability requirements? If a component fails, is there a need for an exact, up-to-date copy of that component to automatically and seamlessly take over?
- Does the system need to scale up to tens of users? Hundreds? Thousands?
- What’s the long-term roadmap for the system? What other systems and software will need to be integrated in the future?
…and so on.
The answers to these questions inform the high-level system design. Often, this design is captured in graphical form, with blocks representing the components and lines or arrows showing how the components interact with one another. Sometimes the blocks are organized into layers, with names such as “database,” “compute,” and “presentation.”
Technical Architecture vs. Software Engineering
Another role you hear about from time to time is “software engineer.” It sounds like the terms “technical architect” and a “software engineer” should be more or less synonymous, and although there can be some overlap, the two roles are actually quite different.
The difference generally lies in the level of detail. The software engineer operates at somewhat greater detail than the technical architect, but not as much as the actual developers.
The relationship is similar to that between a building architect and a structural engineer. A building architect defines the overall appearance of a building, and the structural engineer figures out what materials to use and how to build it.
In software, the technical architect defines the overall system design, which in turn drives the software engineer’s decisions about the technology stack and the frameworks that should be used to build each component.
In both cases, the architect and the engineer have to work together, because sometimes the high-level design isn’t feasible given the time or budget constraints of the project. Each role has to be able to compromise a little to arrive at a realistic design that will meet the client’s requirements.
The AndPlus Approach to Technical Architecture
As a full-service custom software provider, we understand that it takes more than just developers to build high-quality, compelling software. It takes a team, with different roles and areas of expertise. It requires an understanding not only of the immediate business problem but the environment in which that problem manifests itself. This understanding helps us design solutions that can grow and evolve with the business without having to be redesigned or replaced every few years.
Technical architecture is the skill that makes this possible. It’s the foundation of all our solutions—a foundation for growth.