What does a Software architect do exactly!? Developers write code, testers test the system, analyzers elicit the requirements. But, what the hell are architects doing!?
Imagine someday, one of those hot summer days, your boss comes to you and entitles you as software architect. What will you be doing after that hot day!?
Here, I want to share my experience about after that hot day!!
Software Architects vs. Architects
Are we like architects? After all, we're borrowing our name from them. So, there might be something.
Thinking about building something
There is something interesting about our work. We both don't build, we just think about building something.
-We don't build, we imagine a building!
So you can find lots of architects wasting their time with talking to each other! However, talking helps to imagine better. When you talk about your ideas, you are creating a more clear vision about it in your mind (and maybe in other's too)
Using some models to imagine something that doesn't exist yet
We both use models to demonstrate our idea. In fact modeling is the first step of validating our imagination. Architects imagine buildings and their usages, facilities, spaces and their experience. We also, imagine software and its usages, facilities, its experience and spaces.
Spaces!? Do we think about spaces!? What does it mean to think about spaces in software? Believe me or not, this is the main topic of this blog. I've just made the whole story to get you here at this point and raise a word: "Space".
Software Architects vs. Spaces
Let's get deeper and use some more technical terminology. In Object Oriented world, as some developers we are writing code. We are writing:
- Lines of codes in code blocks
- Code blocks in methods
- Methods, in classes
- Classes in namespaces
- Namespaces in assemblies
- Assemblies in projects
- Projects in solutions
In fact, the Object Oriented architecture predicts and provides some spaces for us. For example, if I need to write a method, it should be in a class. A class is a space that OO has created for us. Thanks to OO language architects.
But again, what about us? The architects!?
In the recent years, I've worked as an architect in lots of projects. As an architect the only thing I'm thinking about all the time, is to design spaces.
-As an architect the only thing I'm thinking about all the time, is to design spaces.
In fact when I want to test if my architecture is in a good shape, I ask myself this question:
-Consider X as the code which developer wants to write. If a developer want to write a business about X, would he find just one Space for X?
The 'just one space' is the key. Let's talk about 'just' and 'one' words separately.
Describing the 'Just Part'
What happens if I, as a developer, find 2 or more spaces for the X? I'll pick one of them randomly. The most probable choice is the one that I find first. Most of the time I won't look for another possible space as I think that I found the correct space. On the other hand, another developer might have already written the code X in the other space. What do we call this situation in Software Engineering? Redundancy!
DESCRIBING THE 'One part'
What happens if I, as a developer, don't find at least one space for the X? Obviously, I'll write it somewhere I like. I don't even ask for a space from the architect, I won't waste the time and I'll invent a space. Each developer will invent a space. In this case, not just a simple redundancy is happening, but a growing redundancy happened. Not only the space is not unique per X, but also the number of spaces is growing rapidly.
Growing Redundancy: Due to lack of a space for X, each developer tends to create a space for X. Not only the space is not unique per X, but also the number of spaces is growing rapidly.
So, one of the main concerns of an architect should be managing spaces so that the developers don't tend to write redundant code. And this hard job is just one of many responsibilities of a software architect.
I posted another blog as part 2 of this blog here:
Check it out, people find it interesting.
Good post, Thanks!
i am so happy from your writing about software so continue that ,
i have many ideas about team management but but i do not have patience
for writing .
so continue and continue .....
your friend mojtaba
Thank you Mojtaba, I know you always have great ideas about software. It'll be great to hear more of your ideas.
nothing interesting !!!
It is good and useful idea. Identifying system boundaries (The Walls) and project scope is the most important keys of software development project success but not necessarily useful software, compilation previous step with good architecture (good space design) lead to usefull software.
But how design it?
Hi Mr Mehran Thank you for good and useful idea. I'm so happy to meet you