Wednesday 27 January 2016

What is a software architect ?

Let's talk about a (real story) fairy tail:

A software is delivered, it's running in production. After some weeks, it's start to get some real data, then, it start to crash, it start to loose data, no one knows how to deal with it and in the end, what it's really losing is the company's money. So, we take a close look at this software, ask the involved on that project about the architecture, where is it ? They answer is: what architecture ? (poker face)

Mostly softwares that are running nowadays don't have a properly architecture or even don't have an architecture. The problem it could cause is like to one I write above, the software could simply doesn't survive after some days and that shouldn't be accepted.

So, to have a good architecture, we need a software architect... but, what is a software architect ?

Here are some definitions founded about architect:

Some definitions about architecture from different sources:
"Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. [IEEE 1471]

The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. [Bass]

[Architecture is] the organizational structure and associated behavior of a system. An architecture can be recursively decomposed into parts that interact through interfaces, relationships that connect parts, and constraints for assembling parts. Parts that interact through interfaces include classes, components and subsystems. [UML 1.5]"


Being an architecture require to think much more about than just technologies, API, Frameworks, Design, Code quality. It required you to think also about business, have multi views, dimensions, discipline, think about trade offs, combination and co-relation and system-of-system.

Let's talk about some of these thinking I believe an architect must have:

- Multiple Views

Usually a software developer have just one view, that is: API, they think about how to know and implement it. There are much more views that we need to care about, like reliability, internal / external system integrations, technical risks, instability, performance, security. An architecture need to open his mind and extend his views to more than APIs.

- Multiple dimensions

Developing a software is not just about creating lines and lines of code. We need to ask yourself some questions, like, where will this software be deployed ? Who is going to maintain it ? What is the needed infrastructure for running the software ? Will we have someone to support this software in production ? All these questions matter and an architect need to think about it because software is not valuable when it's code is finished, it's valuable when it's running in production with stability and adding value to the final user and this company.

- Multiple Disciplines

First, say to yourself: "I won't believe every tool I found is working properly.. I won't believe every tool I found is working properly", repeating it 10 times should be fine for today.. :)

Architects shouldn't believe every tool they use is working properly, they need to be suspicious, they need to hack if it's needed. Hack is even more important, it's not just for this case, do you know if the library for connection to your database is really good for your solution that need a high performance ? If after a performance test you discovered that you have a gap, yes, hack it and discover what this library is doing. The library is written in some software language, so, hack it, find a solution and share with the community. An Arch doesn't sit and wait for the solution, he goes and create it.

- Trade Offs

Can I choose the 'coolest' existent technologies and use in my architecture ? Well, that would be very nice, but we need to be REALISTIC. Using the multi dimensions skills, an arch need to know when and what he could use some specific technologies. First, what is the problem I want to solve ? Create an application for streaming some information and save it in some place for future use, should I use nodejs and some nosql database ? Does I have people to work with nodejs ? If I don't have, should I capacitate people at the company to get people experts on this technologies ? 

- Combination / Co-relation

There are some patterns in architecture, an architect need to know what are they and use it correctly, there are some combinations like coca-cola and french fries that we know that are very good, because we saw it in many places, tried and it works. There are some patterns in software architecture to solve some specific problems like streaming some data and put it in some nosql database (because the data to be streamed probably don't have an structure and a nosql is ideal for it), other likes, streaming some data and use an ETL tool to extract some information from this data, process it and load to some database.

- System-of-Systems

There are a lot of existent tools at the market and we need to use it if it's for good, we don't need to re-invent everything, if there is a solution that helps our solution, we need to use it, of course, understanding the trade offs about this solution to see if it's really good for our solution. This item could be mistaken with the about item, but this item is more high level and combination / co-relation is more low level.


So, as you can see, an architect really need to think out of the box and it's much more just than technologies. There are much more that is need, but let's talk about it the future posts. See you soon!! ;)

No comments: