What is software architecture? What does a software architect do? How could we tell the good software architects from the bad software architects?

LightSpeed

In this post I will deal with an interesting (and thorny) set of questions regarding architecture.

Without much further ado, let’s get into the game.

What is software architecture?

In a broad sense, software architecture is the complete set of design decisions that defines and determines the structure of a given software solution, but let’s bear in mind that when we talk about “software architecture“, we really mean the main design decisions that define the main structural elements of a given software solution, and not each and every design decision, that may include a large amount of rather simple, obvious and very uninteresting design decisions.

What does a software architect do?

In plain and simple terms, the software architect is the person that makes those design decisions, so, that is mainly what the software architect does:
making the design decisions regarding a given software solution.

How could we tell the good software architects from the bad software architects?

To be able to answer this question, we should start with a simpler question:

How could we tell a good design decision from a bad design decision?

Well, design decisions are either good or bad just because of their consequences: a design decision is good if and only if it produces good consequences, just as much as it will be bad if and only if it produces bad consequences.

So, getting back to the answer for the original question, the good software architects are the ones that make design decisions that have good consequences for the project, the team and the product, and the bad software architects are the ones that make design decisions that have bad consequences for the project, the team and the product.

I am aware of the fact that any Product Owner may argue that my answer is not useful for them since, by the time they realize that the software architect is not any good, it is already too late!

Well, allow to say in my defense that it is not so, since you can detect the tell-tale signs of either good or bad consequences from design decisions being made by the architect early on the duration of any software development project.

As a parting idea to this post, I will give you another tip on good software architects. All of them are really good at these two things:

1) Good software architects, when they have to make a design decision, they never forget to ask the following question:

How could I make sure that the design decision that I’m about to make will neither compromise nor limit our ability to keep making the design decision that we need, for the forseeable future?

(Since you have allowed me a few things, allow me to say that this is a quote of my own batch)

2) Good software architects, when they ask themselves this question, they always figure out a successful answer to it for the solution at hand.

Most people may argue that the question in 1) is an impossible question since we cannot predict the future, so, there is no way that today we could guess what might be the design decisions that we will need to make in the future.

Again, allow me to say in my defense that most people are not software architects (let alone good software architects), so, most people will not pay attention to the key to this question: “neither compromise nor limit our ability to keep making the design decision that we need

Good software architects do not need to predict the future to be able to figure out the answer to the key to the question.

Kind regards, GEN

Advertisements

2 responses to “What is software architecture? What does a software architect do? How could we tell the good software architects from the bad software architects?

  1. @Gaston, Good Insight !!!
    However have couple of questions
    1) What are different kind if Architects ? ( Infra architect, Information architect, technology architect )
    2) What is Enterprise Architecting and Solution Architecting ?
    3) Isnt Architect need to be a hands-on person in whatever discipline ( infra, security, development etc ) he is architecting ?

    • Yogesh, Hi!

      To be able to answer your questions, it would be very helpful to bring forward some contextual information.

      To start with, I will focus first on the etimology of the word architect: the word architect derives from the greek word arxitexton, which is a composite word:

      Arxi-Texton (the letter xi in greek should be pronounced like the letter H in Hello)

      Texton literally means artisan, and the root tex means literally “made by the hand of a person”, in the sense that artisan means anyone skilled in making handicraft.

      Tex is the root for words like “technique” or “technical”.

      It is also the root for the name of the tool known as TeX.

      Arxi could mean many things, but in this context, it has a very specific meaning, literally it means “the guy that is one level above”, so arxi-texton literally means the “head texton”,

      the “head artisan”, or the artisan in charge, or the artisan responsible for making design decisions.

      When you have a simple structure to deal with, you could have a single guy making all the design decisions.

      But when you have a complex structure to deal with, just like the kind of complexity that most companies face nowadays, you cannot have just one single guy calling ALL the shots, you need to
      resort to a strategy of the type “divide and conquer”, which means that you will have to define different levels of decision making, with a different guy at each level make design decisions
      proper to that given level.

      At the leaf level, you will have to put in charge a guy with a narrow and focused skillset, what we would call a specialist, and at the top level you will have to put in charge a guy with a wide
      skillset, with a lot of experience in all areas and levels of decision making.

      It is because of the leaf level positions that we hear the names like Infrastructure Architect, IT Architect, Information Architect, Data Architect, etc.

      It is because of the higher levels positions that we hear names like Enterprise Architect.

      At each level, you have to put in charge a guy with the proper skillset for that given level of decision making, and the proper skillset always means many disciplines, not just one or two.

      The higher the level of decision making, the wider and more diverse the set of disciplines required for the guy in charge to be profficient with.

      Even though I will write very soon a least one post on some of the main topics pertaining to Enterprise Architecture, allow me to say some of the most important stuff regarding the kinds
      of problems that an Enterprise Architect has to solve:

      Enterprise Solutions like ERPs or CRMs target all industries, all regions and countries. all types of organizations, all sizes of organizations, all kinds of customers, all kinds of products, all kinds of services.

      As a solution architect, when you have a solution that has to deal with this wild set of requirements, let’s be very clear that your are facing a rather crazy ride!

      To say it in very simple terms, what is a useful requirement for an industry or a type of organization, it might as well be a very inconvenient constraint for another industry, or another type of organization, or what have you!

      Let’s get back to the Enterprise Architects and what they have to accomplish as the “gardeners in charge of such gardens” that are full of plants like ERPs and CRMs!

      Any Enterprise Architect (EAx), to be successful, has to be able to set free the functionality that is “taken hostage” within Enterprise Solutions like ERPs or CRMs.

      In a broader sense, the EAx has to decouple the functionality from the technology so as to be able to set free that said functionality.

      Many Enterprise Solutions have in their architecture a “Silo-Oriented” approach which makes them complex to be integrated into streams of execution of business processes.

      Some other Enterprise Solutions, even though they include in their architecture ways (including standards-based ways) to be integrated into streams of execution of business processes, they are expensive to integrate.

      A good Enterprise Architect is able to figure out alternative and innovative ways to integrate these solutions in an efficient and not expensive manner.

      Kind regards, GEN

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s