Software Architecture in Practice

Hi,

this week I started reading this book, since software architecture is the computer science’s area that I like most. It’s too early to give my real opinion about it, but it has a very good reading. After the introduction chapters, I was able to understand the real concept of Software Architecture, its business cycle, known as ABC, and what makes a good architecture. So, let’s do it in parts.

Software architecture has emerged as a crucial part of the design process, representing a summary result of a set of business and technical decisions. It is defined as follows:

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

So, the architecture defines components, their nature, the relationship among them, the significance of each relationship, the significance of the layout and the data and control flow through the system.

After the definition, it’s time to understand the architecture business cycle. Here is how it works:

  1. The architecture affects the structure of the developing organization: teams are formed for each software unit; schedules and budgets allocate resources in chunks corresponding to the units.
  2. The architecture can affect the enterprise goals of the developing organization: a succesfull system can enable a company to establish a foothold in a particular area.
  3. The architecture can affect the customers requirements for the next system by presenting the customer with the opportunity to receive an upgrade system (based on the same architecture) in a more reliable, timely and economical way than building a system from scratch.
  4. The process of building the system will affect the architect’s experience for subsequent systems.
  5. A few systems will influnce and actually change the software engineering culture.

Finally, the answer that everyone wants to know: What makes a good architecture? Unfortunately, there is no such thing as an inherently good or bad architecture, but a software architecture that fits more or less for some stated purpose. Even so, there is some process/structural roles when creating a system architecture, as described below:

  • The architecture should be the product of a single architect or a small group of architects with an identified leader.
  • The architect should have the technical requirements for the system.
  • The architecture should be well documented.
  • The architecture should be circulated to the system’s steakholders, who should be actively involved in its review.
  • The architecture should feature well-defined modules whose functional responsabilities are allocated on the principles of information hiding and separation of concerns.
  • The architect should never depend upon a particular version of a comercial product or tool.
  • The architecure should feature a small number of simple interaction patterns.

Well, I’ve just read three chapters and in a close future we will have a lot of other things to discuss here.

See you.


Fernando

3 thoughts on “Software Architecture in Practice

  1. Oi Fernando,
    Também estou lendo este livro agora. Inclusive a mesma edição. Estou atualmente no cap 8. Na realidade a leitura dele faz parte de um estudo que estou fazendo sobre “arquitetura de software”.

    Achei interessante no livro se indicar,para uma boa arquitetura, que a arquitetura deve ser o papel de 1 arquiteto, ou um arquiteto lider. Isso vai de encontro dos princípios de Ambler(livro:Modelagem Ágil) , embora ele não especifique isso para arquitetura e nem Clements diga que precise ser “apenas” 1 arquiteto.

    Outra coisa interessante é que se propõe que a arquitetura seja o primeiro artefato gerado. Em XP a arquitetura emerge do processo de desenvolvimento não sendo feito nenhum esforço inicial para criar a arquitetura. Pessoalmente acredito que a arquitetura deva gerar os primeiros artefatos de um projeto.

    O que o livro confirma novamente dos princípios de modelagem é a necessidade de uma boa interação com os stakeholders.

    O cap 1 é bom e o livro apenas cresce em cada capitulo.

  2. Oi Fábio,

    estou começando a praticar metodologias ágeis em meus projetos e realmente não criamos o artefato de arquitetura, como você havia mencionado. Na verdade, eu ainda acho um pouco estranho pois sempre me guiei pelo documento de arquitetura e pela modelagem UML criada pela disciplina de Análise e Projeto do RUP.

    Entretanto, entendi que um dos grandes problemas da geração de artefatos é a sua manutenção. Dessa forma, como é bastante comum a mudança da arquitetura de um sistema devido a problemas, ou até soluções mais práticas, encontrados durante a implementação, a criação e manutenção desse artefato passa a ser bastante custoso.

    O que se pode fazer é discutir a arquitetura da solução durante o planejamento da Sprint, minimizando-se assim o risco de projetar um sistema de forma inadequada.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

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

Google+ photo

You are commenting using your Google+ 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 )

Connecting to %s