After hanging around as an ordinary software engineer for some time, which by itself is already very impressive, you will find yourself reaching for more. Be it more responsibility, additional determination options in your company or simply the urge to discover new things to get more out of working with software by itself, the professional title software architect may interest you.
What is software architecture?
Just like every building has a blueprint, every software should have some sort of plan or concept behind it as well before writing any line of code. As you may already have experienced, the later changes in software system need to be made the more expensive it gets to do so. So, if you are going to do it anyway, why not do it the right way right away?
Defining your architecture (probably)
If you are already familiar with UML diagrams you can of course get right into it, set up a neat thing within your component diagram to describe your complex system in an unified way, but what are the essential structures your system consists of?
Different structures explained
Comparable with your body consisting of bones, your software is made up of different structures, which are also known as view types. Being able to identify these enables you to clearly predict their behavior throughout the lifecycle of the software in question.
Roughly speaking, your structures contain elements, which are your separate blocks of software, and relations, which connect the existing elements and help to describe how they are working together.
To stay connected with reality and build a software architecture, which will not just look good on paper, but actually fulfill its purpose in real life as well, the book “Software Architecture in Practice” by Len Bass defines the following three types of elements and relations for successfully creating working structures.
Module
Modules are basically everything living within your filesystem and existing during design time and beyond. Examples for modules are packages and classes as well as database tables.
You are using these module structures as a base for the component and connector structures.
Component and connector (C&C)
Components and connectors can not be seen on your computer like modules. These kinds of structures only exist during runtime, so the only trace you have of them are your logfiles at most.
Examples for those are threads or processes as well as objects.
These structures do the work within your project. They call various functions, return objects, and save data.
Allocation
Coming to allocations, these view types relate a software unit to a non-software unit like a server or personal computer. It shows how modules, components and connectors correspond with each other and illustrates the hardware running the created software.
These structures are also often referred to as mapping structures, as they show how the elements map to one another.
Even more to learn
Being a software architect, defining are complex system with the structures explained earlier, is only a small, but very important part of your responsibilities. Many, especially external, factors, of which an average, mortal software developer may not be aware, need to be considered.
So, one of the biggest challenges you will be facing in this transition is the need for seeing and understanding a software system in a broader scope than before. Being able to calculate and take into account internal and external factors, keeping balance between different aspects of the system itself, and also being able to determine the right trade-offs at the right time.
Sure, it is much more responsibility you need to handle and growing in and getting used to it can take some time, but is there anything we would not do to make our customers happy?
References
- Design It! (From Programmer to Software Architect) by Michael Keeling
- Software Architecture in Practice by Len Bass
Top comments (0)