Domain Driven Design

When a modeler is separated from the implementation process, he or she never acquires, or quickly loses, a feel for the constraints of implementation. The basic constraint of MODEL-DRIVEN DESIGN – that the model supports an effective implementation and abstracts key insights into the domain – is half gone, and the resulting models will be impractical. Meanwhile, if the people who write the code do not feel responsible for the model, or don’t understand how to make the model work for an application, then the model has nothing to do with the software. If developers don’t realize that changing code changes the model, then their refactoring will weaken the model rather than strengthen it. Finally, the knowledge and skills of experienced designers won’t be transferred to other developers if the division of labor prevents the kind of collaboration that conveys the subtleties of coding a MODEL-DRIVEN DESIGN.

Architectural Styles

Pipes and Filters
We defined this style as an example earlier in this chapter. The Pipes and Filters style is characterized by a single, simple element type (the filter) that processes a data stream, with instances of this type connected by simple connectors known as pipes.

Client/Server
This very widely used style defines a system structure comprised of two types of elements: a server that provides one or more services via a well-defined interface and a client that uses the services as part of its operation. The client and server are typically assumed to reside on different machines in a network (although this is not a requirement of the style—the client and server could be in the same operating system process).

Tiered Computing
A development of the Client/Server style, the Tiered Computing style is widely used in enterprise information systems. A tiered system is considered to contain a number of tiers of computation, which combine to offer a service to an ultimate consumer (e.g., a human user). Each tier acts as a server for its caller and as a client to the next tier in the architecture. A key architectural principle is that a tier can communicate in this way only with the tiers immediately on either side of it; a tier is not aware of the existence of other tiers in the system
apart from its neighbors.

Peer-to-Peer
Often referred to as P2P, this architectural style defines a single type of system element (the peer) and a single type of connector that is a network connection (an interpeer connection). The characteristics of the connector are not important to the style, and the style has been used with a number of types of network connections.

Layered Implementation
The Layered Implementation style identifies a single type of system element: the layer. The style organizes a system’s implementation into a stack of layers, with each layer providing a service to the layer above it and requesting services from the one below it. The layers are ordered by the level of abstraction they represent, with the most abstract (e.g., organization-specific operations) at the top of the stack and the least abstract (e.g., operating system–specific libraries) at the bottom. Depending on the implementation of the style, a layer may be able to communicate directly with any of the layers below it (relaxed layering) or only with the layer directly below it (strict layering).

Publisher/Subscriber
The Publisher/Subscriber style grew out of a realization that client/server interactions are not suitable for all types of distributed system problems. The style defines a single system element (the publisher) that creates information of interest to any number of system elements (the subscribers) that may wish to consume it. A single type of connector, a reliable network link, is used to link the publisher and the subscribers.

Asynchronous Data Replication
While Publisher/Subscriber is normally considered to be a style that allows functional elements to exchange information, a variant of it, Asynchronous Data Replication, is a style used where information in two data stores needs to be kept synchronized (e.g., where it is replicated for performance reasons). The style has three element types: the data source, the data replica, and the replicator. The data source is a data store that owns a particular type of information, while the data replica is a separate data store that wishes to maintain a synchronized copy of some subset of the information in the source. The replicator is the element responsible for recognizing changes or additions to information in the source and performing the synchronization of the replica data store.

Distribution Tree
Another architectural style that relates to data distribution is the Distribution Tree style. This style defines three types of system elements: publishers, distributors, and consumers. The elements of the system are arranged into a tree, connected by network link connectors. A single publisher forms the root of the tree, the distributors are connected to form the intermediate nodes, and the consumers form the leaves of the tree. The publishers publish new or changed information, which the distributors then cache and distribute to their immediate child nodes. If a child node is added or restarted, it can refresh its view of the information from its parent node’s cache. When the information reaches the leaf nodes of the tree, the consumer nodes consume it.

Integration Hub
The Integration Hub style is another data-oriented architectural style, extending Asynchronous Data Replication to situations where information needs to be synchronized between a number of different systems (rather than between replica data stores).

Tuple Space
The Tuple Space style is a type of repository that allows a number of pieces of a distributed system to collaborate to share information. The two types of system elements in the style are the clients (computational elements that create and consume information) and the tuple space itself (a storage area where clients can read and write typed information tuples or records). The clients and the tuple space are connected by a client/server network connection. Clients interact with the tuple space by writing new tuples to it or requesting tuples that match simple search criteria. Clients do not interact directly. Typically the tuple space can also call back to the clients when objects they are interested in change.

Software Patterns

Name: A pattern needs a memorable and meaningful name to allow us to clearly identify and discuss the pattern and, more importantly, to use its name as part of our design language when discussing possible solutions to design problems.

Context: This sets the stage for the pattern and describes the situations in which the pattern may apply.

Problem: Each pattern is a solution to a particular problem, so part of the pattern’s definition must be a clear statement of the problem that the pattern solves and any conditions that need to be met in order for the pattern to be effectively applied. A common way to describe the problem that a pattern solves is to describe the design forces it aims to resolve, each
force being a goal, requirement, or constraint that informs or influences the solution (such as a particular sort of flexibility needed or a particular type of interelement decoupling you want to achieve).

Solution: The core of the pattern is a description of the solution to the problem that the pattern addresses. This is usually some form of design model, explaining the elements of the design and how they work together to solve the problem.

Consequences: The definition of a software pattern should include a clear statement of the results and tradeoffs that will result from its application, to allow you to decide whether it is a suitable solution to the problem. Consequences may be positive (benefits) or negative (costs).

Viewpoint of Systems Architecture

Functional: Describes the system’s functional elements, their responsibilities, interfaces, and primary interactions. A Functional view is the cornerstone of most ADs and is often the first part of the description that stakeholders try to read. It drives the shape of other system structures such as the information structure, concurrency structure, deployment structure, and so on. It also has a significant impact on the system’s
quality properties such as its ability to change, its ability to be secured, and its runtime performance.

Information: Describes the way that the architecture stores, manipulates, manages, and distributes information. The ultimate purpose of virtually any computer system is to manipulate information in some form, and this viewpoint develops a complete but high-level view of static data structure and information flow. The objective of this analysis is to answer the big questions around content, structure, ownership, latency, references, and data migration.

Concurrency: Describes the concurrency structure of the system and maps functional elements to concurrency units to clearly identify the parts of the system that can execute concurrently and how this is coordinated and controlled. This entails the creation of models that show the process and thread structures that the system will use and the interprocess communication mechanisms used to coordinate their operation.

Development: Describes the architecture that supports the software development process. Development views communicate the aspects of the architecture of interest to those stakeholders involved in building, testing, maintaining, and enhancing the system.

Deployment: Describes the environment into which the system will be deployed, including capturing the dependencies the system has on its runtime environment. This view captures the hardware environment that your system needs (primarily the processing nodes, network interconnections, and disk storage facilities required), the technical environment requirements for each element, and the mapping of the software elements to the runtime environment that will execute them.

Operational: Describes how the system will be operated, administered, and supported when it is running in its production environment. For all but the simplest systems, installing, managing, and operating the system is a significant task that must be considered and planned at design time. The aim of the Operational viewpoint is to identify system-wide strategies for addressing the operational concerns of the system’s stakeholders
and to identify solutions that address these.

Principais Servidores

• Apache - O Apache Webserver mudou a Internet e abriu os olhos de muita gente para o mundo do software livre. Graças a eles é possível ter um servidor web de alto desempenho e qualidade, a um custo mínimo. Sem ele, todos nós estaríamos pagando muito mais caro para hospedar nossos sites na Internet.
• Internet Information Services - Também chamado de IIS, é o servidor Web da Microsoft. Começou como um queijo suíço, mas é verdade que vem melhorando. É a plataforma para quem quer trabalhar com a tecnologia ASP e .NET. Para mais informações, veja também o site americano do IIS.
• Websphere - Servidor Web da IBM,voltado para aplicações Java e J2EE, é um dos principais servidores de alto desempenho e robustez do mercado. 
• BEA WebLogic - Concorre com a IBM pelo mercado de servidores JAVA e J2EE de alto desempenho. 
• Tomcat - Servidor Web gratuito para aplicações J2EE, pode rodar sozinho ou como uma extensão do Apache ou do IIS. Faz parte da Apache Fundation, responsáveis pelo Apache Webserver. 
• Jboss - Muito bem conceituado,um dos lideres de mercado de servidores J2EE gratuitos.
• Thttpd - tiny/turbo/throttling HTTP server - Esse servidor é extremamente simples. Segue o protologo HTTP 1.1 e pronto. Mas se você precisa de um servidor extremamente rápido, para servir grandes quantidades de páginas simples (imagens ou banners, por exemplo) nenhum vai conseguir ser mais rápido que ele nem suportar tanta carga sem perder o desempenho. Para todos os ‘sabores'de Unix (Linux, etc...).
• Jrun - Servidor pago da Macromedia para aplicações J2EE.
• Zeus Web Server - Um servidor pago, caro, e bastante poderoso. Usado por empresas como o E-bay, por exemplo. 

Understanding Architecture

"Software architecture encompasses the significant decisions about the organization of a software system. The selection of the structural elements and their interfaces by which the system is composed together with their behavior as specified in the collaboration among those elements. The composition of the structural and behavioral elements into progressively larger subsystems, the architectural style that guides this organization, these elements, and their interfaces, their collaborations, and their composition. Software architecture is concerned not only with structure and behavior but also with usage, functionality, performance, resilience, reuse, comprehensibility, economic and technology constraints and trade-offs, and aesthetic issues."

Rational Unified Process

"Architecture is a set of structuring principles that enables a system to be comprised of a set of simpler systems each with its own local context that is independent of but not inconsistent with the context of the larger system as a whole."

SunTone Architecture Methodology

Logical layers are merely a way of organizing your code. Typical layers include Presentation, Business and Data – the same as the traditional 3-tier model. But when we’re talking about layers, we’re only talking about logical organization of code. In no way is it implied that these layers might run on different computers or in different processes on a single computer or even in a single process on a single computer. All we are doing is discussing a way of organizing a code into a set of layers defined by specific function.

Physical tiers however, are only about where the code runs. Specifically, tiers are places where layers are deployed and where layers run. In other words, tiers are the physical deployment of layers.

16 Leis Fundamentais da Engenharia de Software

Lei nº 1 – Lei fundamental da Engenharia de Requisitos
Os requisitos terminam onde começa a liberdade do implementador.

Lei nº 2 – Lei dos 3 éfes da Gestão de Prioridades
1º) Funcionalidade
2º) Fiabilidade
3º) Eficiência

Lei nº 3 – Princípio fundamental da Arquitetura de Software
Qualquer problema de estruturação de software resolve-se introduzindo níveis de indirecção.
Corolário: Qualquer problema de desempenho resolve-se removendo níveis de indirecção.

Lei nº 4 – Lei de Arquimedes da Arquitetura de Software
Um sistema de software fundado numa má arquitectura afundar-se-á sob o peso do seu próprio sucesso.

Lei nº 5 – Princípio fundamental da Desconfiança Homem-Máquina
Inteligência artificial é melhor do que estupidez natural.

Lei nº 6 - Paradoxo da Redundância
A redundância é fonte de erros, mas também permite revelar erros.

Lei nº 7 – Princípio fundamental da Verificação & Validação
Um programa que cumpre perfeitamente uma péssima especificação é um péssimo programa, não um programa perfeito.

Lei nº 8 – Limitação fundamental da  Engenharia de Software
É praticamente impossível provar que um programa está correcto. 
Corolário: Desenvolver software é conjecturar soluções para problemas.

Lei nº 9 – Princípio fundamental da Qualidade de Software
Todo o programa tem erros. Além disso, o número de erros de um programa é dado precisamente pela fórmula n > a, em que a é um inteiro qualquer.

Lei nº 10 – Lema fundamental do Teste de Software
Os bugs escondem-se nos cantos e reúnem-se nas fronteiras.

Lei nº 11 – Princípio da incerteza no Planeamento de Projetos
Não é possível fixar simultaneamente o resultado, custo e duração de um projeto de software.

Lei nº 12 – Dinâmica do Deslizamento de Prazos
Falta cada vez mais tempo para acabar o projecto.

Lei nº 13 – Paradoxo de Zenon do Software
Não basta fazer o que falta fazer para satisfazer o cliente.

Lei nº 14 – Princípio da Conservação da Não-Aceitação
Os X% que falta implementar têm (100-X)% de importância para o cliente.

Lei nº 15 – Lei fundamental da Gestão de Alterações
Fazem-se sempre mais alterações, até não haver mais tempo para fazer alterações.
Corolário: A última alteração é a que deu cabo de tudo.

Lei nº 16 – Responsabilidade social do Engenheiro de Software
O mundo pode acabar devido a uma catástrofe. E é aí que entram os Engenheiros de Software.

Algumas definições de arquitetura

“A arquitetura de um software é a estrutura ou estruturas do
sistema, o que compreende componentes de software, propriedades
desses componentes que são visíveis externamente e o relacionamento
entre eles”, Paul Clements, SEI.

“A arquitetura de um sistema de software compreende um conjunto
de componentes, conexões e restrições de sistema e de software; um
conjunto de necessidades de stakeholders; uma lógica que demonstra
que se os componentes, conexões e restrições definem um sistema
que se implementando irá atender as necessidades dos stakeholders”,
Barry Boehm.

“A Arquitetura de Software é a organização fundamental de um
sistema, incluindo seus componentes, o relacionamento entre esses
componentes e com o ambiente e os princípios que definem o desenho
e a evolução dos componentes.”,
IEEE 1471/2000 Recommended Practice for Architectural Description of
Software-Intensive Systems

“A Arquitetura de Software inclui o conjunto de decisões significantes
sobre a organização de um software tais como a seleção dos
elementos estruturais e suas interfaces; o comportamento entre esses
elementos; a composição destes elementos estruturais e de
comportamento em subsistemas maiores e o estilo arquitetural que
guia esta organização.”, Booch, Kruchten, Reitman, Bittner, and Shaw

Como (e por quê) criar uma arquitetura executável em sistemas de informação

Uma das maiores falhas de gerentes e líderes técnicos em projetos de software é ignorar os riscos técnicos inerentes em tecnologias como J2EE, .NET, Delphi, VB, SAP/R3, entre tantas outras. Exemplos destes riscos manifestados incluem:

• Sistemas Web ou de banco de dados que não escalam por ausência de testes de desempenho
• Erros em operações financeiras por falhas de precisão em representação numérica
• Alta taxa de erros em sistemas de atendimento (call center) e perda de clientes devido a falta de testes de usabilidade.

Muito dinheiro é perdido anualmente no Brasil devido a estas falhas. Pense por um instante quantas horas de projeto provavelmente voce já precisou gastar devido a falhas desta natureza…
Um forma de dar com este problema é realizar, no começo do projeto, a identificação dos requisitos arquiteturais de um produto. Um requisito arquitetural determina um critério de qualidade a ser observado, como por exemplo o tempo médio de resposta das telas de um sistema, a taxa de crescimento anual em registros de um banco de dados, a precisão numérica de operações financeiras ou os browsers suportados em uma aplicação Web.
Normalmente estes requisitos podem ser avaliados e medidos durante o ciclo de vida de um projeto, o que garante acordos minímos de qualidade do produto em construção. Uma boa equipe deve, portanto, criar um mecanismo de aferição destes requisitos arquiteturais ainda nas fases preliminares do projeto. Chamamos aqui este mecanismo de aferição de uma arquitetura executável, que consiste de código executável que viabilize a construção do sistema como um todo (requisitos funcionais) e sua operação em produção sem contratempos. Metaforicamente, a arquitetura executável é similar a fundação de um prédio de engenharia civil, que consiste de uma estrutura que garanta que todos os andares de prédio sejam montados posteriormente.
Criamos um roteiro abaixo que mostra como criar uma arquitetura executável, em três passos:
1. Identificação dos Requisitos Arquiteturais
2. Criação de uma prova de conceito para cada requisito arquitetural que seja risco técnico alto.
3. Validação da arquitetura executável, que consiste do conjunto de provas de conceito realizadas no item 2.
O passo 1 deve ser realizado a partir de questionários e modelos disponíveis na literatura como a norma ISO 9126 ou o modelo FURPS+ (Usado para coletar requisitos não-funcionais no RUP).
O modelo FURPS+, por exemplo, trabalha os seguintes aspectos de qualidade:

• Funcionabilidade: Estética e consistência na interface com o usuário.
• Confiabilidade: Disponibilidade (a quantidade do sistema “funcionando apropriadamente”), exatidão dos cálculos do sistema e a capacidade de recuperação do sistema após falhas.
• Desempenho: Rendimento do processamento, tempo de resposta, tempo de recuperação, tempo de inicialização e tempo de encerramento.
• Suportabilidade: Possibilidade de teste, adaptabilidade, sustentabilidade, compatibilidade, configurabilidade, instalabilidade, escalabilidade e possibilidade de localização.

O problema primário destes modelos é que eles são áridos para iniciantes e pessoas sem background arquitetural. Para ajudar neste problema, colocamos abaixo uma versão mais leve, em formato de questionário, baseado na norma ISO 9126.

1. Precisão
   • O sistema realiza operações financeiras? Se sim, especifique o número de casas de precisão destes cálculos.
   • O sistema é de extração de dados/estatístico/ engenharia e realiza cálculos matemáticos complexos ? Se sim, especifique o número de casas de precisão das regras de transformação/cálculo.
   • O sistema manipula medicamentos, compostos quimícos ou elementos cuja dosagem possam causar danos a seres humanos?
2. Interoperabilidade
   • O sistema se comunica com outros sistemas, hardwares ou bases de dados? Se sim, especifique os sistemas de comunicação, hardwares ou bases de dados.
   • O sistema é de comércio eletrônico (B2C ou B2B)? Se sim, especifique os sistemas de comunicação do B2C ou B2C.
3. Segurança
   • O sistema deve realizar controle de acesso (autenticação e autorização)?
   • O sistema deve garantir o sigilo das informações trafegadas na rede interna ou internet (condidencialidade e integridade)?
   • O sistema deve realizar auditoria (log) das operações?
4. Maturidade
   • O sistema deve funcionar vinte e quatro horas por dia, sete dias por semana (missão crítica)? Se não, especificar o tempo máximo que o sistema pode ficar fora do ar (ou alternativamente porcentagem mínima de operação).
5. Tolerância a Falhas/Recuperação de Falhas
   • Em caso de falha do sistema, existirá algum plano de contingência ou de retomada de operação?
     Se não, especificar o tempo máximo que o sistema pode ficar fora do ar.
6. Facilidade de Entendimento
   • O sistema deve ter help-online ou manual?
   • Deve haver treinamento ou workshops para os usuários do sistema?
7. Operabilidade
   • O sistema usa hardwares específicos (canetas óticas, PDAs, URAs, telefones celulares, plotters ou outros)?
   • O sistema é de pronto atendimento (ex: call-centers)?
   • stema deve operar em browsers outros além do Internet Explorer?
8. Comportamento de Tempo
   • O sistema deve ter funcionalidades que rodem abaixo de seis segundos? (*) Seis segundos é um valor, medido em testes de usabilidade, onde usuários de sistemas computacionais começam a perceber a latência do sistema em uso. Como todo valor, ele deve ser contextualizado à sua realidade.
9. Comportamento de Recursos
   • O sistema irá rodar na Internet ou Intranets de grande porte? Se sim, especificar o número máximo de usuários esperado em horários de pico.
   • O sistema irá manipular bases de dados com muitos registros? Se sim, especificar o número máximo de registros e a taxa de crescimento anual.
10. Conformidade e Facilidade de Troca
    • O sistema deverá rodar em quais sistemas operacionais?
    • O sistema deverá rodar em outros hardwares além dos PCs? Se sim, especificar quais hardwares.
11. Padronização
    • O sistema deve obedecer a alguma lei, norma, regulamentação ou portaria governamental? Se sim, especifique.
    • O sistema deve obedecer a algum padrão definido na organização alvo onde o sistema irá funcionar. Se sim, especifique o padrão.
12. Facilidade de Instalação
    • O sistema deve possuir instalador para usuários finais?

O questionário acima não é completo. Remova, altere e adicione itens ao mesmo, mas não deixe de ter o seu roteiro para entrevistar os seus usuários e coletar estes requisitos suplementares. Temporalmente, você deve terminar esta coleta na fase de iniciação do projeto pois estes requisitos são críticos e normalmente de alto risco. Por exemplo, se o seu projeto tem vinte semanas de duração, você deve ter extraído os requisitos arquiteturais e riscos associados nas duas primeiras semanas do projeto.
Ao terminar este processo, iremos partir para o item 2, que consiste em montar provas de conceito que mitiguem os potenciais riscos destes requisitos. Para isso, iremos trabalhar um exemplo simples. Suponha que coletemos um requisito de desempenho que nos peça para suportar 4.000.000 transações por dia e um máximo de 200 usuários concorrentes no sistema. Um requisito desta natureza impõe um alto risco no produto pois existe uma alta chance de não ser suportado em uma típica configuração PC Intel + windows + Servidor Web. Se existe o risco, devemos mitigá-lo. A mitigação deve ser feita com código executável e não com modelos UML apenas. Criamos então uma primeira versão do produto, que chamamos de Alfa 1, que consiste de um requisito funcional implementado sujeito as condições do requisito arquitetural em análise. Por exemplo, podemos implementar um versão simplificada de um relatório ou página sendo consumida simultaneamente por 200 usuários. A versão Alfa não possui compromissos reais de funcionalidade como por exemplo possuir todos os campos ou realizar todas as consistências de negócio, mas deve ser suficientemente real para mitigar o risco. No nosso exemplo poderíamos ter descoberto que precisaremos de duas máquinas em um cluster para operar com tal carga. O risco foi mitigado e a topologia física agora se baseia em uma decisão técnica e não em uma especulação ou estimativa.
O procedimento exemplificado acima é repetido para cada risco identificado e novas versões (Alfa 2, 3, N) são geradas ao longo de alguns dias ou algumas semanas para projetos de maior porte. Temporalmente, o primeiro terço da vida do projeto deve conseguir gerar uma arquitetura executável que mitigue todos os riscos destes requisitos suplementares. Em um projeto de vinte semanas, este processo deve ser encerrado até a sexta ou sétima semana. O passo 2 (Criação das provas de conceito) se encerra aqui.
Finalmente, temos um conjunto de códigos evolutivos que compreendem alguns requisitos funcionais (normalmente entre 5 e 20% do escopo do sistema), que atendem a todos os requisitos arquiteturais que impõe riscos técnicos alto no sistema. Chamamos isso de uma arquitetura executável, que deve ser então testada e validada por um audiência maior. Eventualmente, ajustes devem ser feitos e novos alfas serão produzidos até que a arquitetura se estabilize. Este produto é chamado de arquitetura executável e serve como linha de base arquitetural do sistema. O passo 3 se encerra aqui.
Quais as vantagens desta abordagem, pode perguntar o leitor mais cético?

• A grande maioria dos riscos técnicos do sistema foram mitigados. As surpresas técnicas em produção nao existem mais, pois foram detectadas, analisadas, implementadas, testadas e homologadas previamente.
• O tempo investido em arquitetura permite agora a paralelização dos recursos o que fornece economia de escala em médio prazo.
• O retrabalho de projeto é reduzido drasticamente. Por exemplo, cito o caso de uma empresa de Belo Horizonte que detectou tardiamente em um projeto que o browser Mozilla precisava ser suportado em sua aplicação Web (Veja novamente o item Operabilidade no item 1 do nosso processo). Após mais de 50 requisitos incorretos, isso gerou um retrabalho de mais de 1000 horas e um custo extra de mais de 50.000 reais! A pergunta que pode ficar é: Quem cria uma arquitetura executável? O arquiteto de sistemas é o papel responsável pela criação de uma arquitetura executável. O arquiteto, entretanto, nào é um super-homem. Ele é muitas vezes composto de um comitê de pessoas que em um trabalho conjunto irão identificar e mitigar riscos técnicos e então criar a arquitetura executável de um sistema.
  Se você está começando um novo projeto agora, pare por cinco minutos e pense. Você quer gastar horas e horas intermináveis em sessões de depuração de código à noite. viver a pressão de atrasos, falta de qualidade no código e ter noites mal dormidas? Se não, invista agora em criar a sua arquitetura executável do seu sistema. O trabalho é desafiante, mas o benefício é garantido!
  

A Morte dos Sistemas de Informação de TI

Um velho paradigma de TI é traduzir o conceito da construção de sistemas de informação (da administração) para a construção de grandes sistemas de informação automatizados de TI. É fácil reconhecer este paradigma, que se manifesta pelos seguintes sintomas:

• grandes especificações de requisitos, que consomem meses (ou anos) para a produção de livros (obsoletos no dia D+1);
• projetos com cronogramas gigantes e orçamentos com 6 dígitos;
• grandes equipes;
• sistemas monolíticos baseados na tecnologia da década (Cobol, Pascal, C, Java, C# ou linguagens dinâmicas);
• sistemas incapazes de gerar valor de negócio e obsoletos antes mesmo de entrar em produção;
• prejuízos proporcionais ao tamanho do desafio e um sentimento de incapacidade.

Pense em capacidades de negócio e serviços
Citando um velho ditado latino chamado “Divide et impera”, a chave para sermos efetivos é quebrar o conceito de “sistemas de TI” e pensar em termos do conceito de capacidades de negócio e também em termos de serviços de negócio. Serviços de negócio são pequenos módulos de negócio que geram algum valor de negócio para a organização. A vantagem desta abordagem é que serviços de negócio podem ser colocados rapidamente em produção, gerar valor real de negócio muito mais rapidamente e permitir uma adaptação do negócio a mudanças do mercado.

Dê menos ênfase em arquiteturas de sistemas de software. Dê mais ênfase em arquiteturas de referência de serviços
Se os serviços de negócio forem criados sem uma fundação, a tendência é que eles gerem um tipo de construção arquitetural chamada “puxadinho de software”. Antes que serviços sejam criados, mantidos e evoluídos, uma fundação para estes serviços deve ser estruturada e criada. Esta fundação é chamada de arquitetura de referência de serviços e opera como um elemento que permite acomodar estes serviços ao longo do tempo em termos dos seus elementos técnicos e de seus elementos de governança.

Pense na ótica de negócio
A TI não existe para o seu próprio fim. O fim da TI é potencializar negócios. Permitir aos decisores, através da agilidade e sustentabildiade dos serviços de negócio, uma rápida tomada de decisão pode fazer toda a diferença nas organizações. O pensamento na ótica de negócio requer uma mudança de filosofia na parte de TI. Sistemas monolíticos com ciclo de vida de meses ou anos podem ser “divertidos empreendimentos técnicos” ou “máquinas de faturamento de fábricas de software”, mas tem comprovadamente e repetidamente gerado fracassos retumbantes.

Arquitetura Corporativa para Leigos

O conceito de Arquitetura Corporativa existe já há quase 30 anos na indústria de TI e administração, mas apenas nos últimos anos tem obtido alguma visibilidade no mercado Brasileiro. Mas o que é mesmo uma Arquitetura Corporativa?

Adaptei um meta-modelo de um corpo de conhecimento chave para arquitetura corporativa, o TOGAF, que mostra a visão holística da arquitetura dentro de uma empresa.

Uma arquitetura corporativa tem alguns pontos chave, que destaco aqui:

• ênfase no pensamento estratégico de forma que o time de arquitetura gere uma visão arquitetural para todo projeto, de forma que que todo o esforço do time de arquitetura seja convergente às expectativas de negócio dos gestores;
• a clara necessidade de organizar os requisitos arquiteturais do projeto antes que a solução seja endereçada;
• a decomposição da arquitetura em quatro disciplinas: arquitetura de negócio, arquitetura de aplicações/software, arquitetura de dados e arquitetura tecnológica;
• a governança de todo o esforço arquitetural nos projetos, iniciativas e oportunidades, i.e, um controle dos artefatos arquiteturais gerados, a mensuração do valor gerado por estas iniciativas e o controle dos ciclos de melhoria contínua.

De forma pragmática, a arquitetura corporativa nos ensina que escolher uma tecnologia no primeiro dia do projeto normalmente tende a ser uma má idéia. Isso traz uma profunda implicação para os “arquitetos Java EE” ou os “arquitetos .NET” que usualmente levam a sua tecnologia a tira-colo antes de entender o problema, a estratégia de uma organização e capturar corretamente os requisitos arquiteturais que eles devem endereçar. Em verdade, o próprio termo “arquiteto Java EE” ou “arquiteto .NET” traz uma contradição per se.

O tema arquitetura corporativa é ainda muito vasto e desafiador, mas a internalização dos alguns dos seus princípios fundamentais pode nos ajudar a resolver problemas de TI de forma a gerar maior valor de negócio para as empresas e com soluções mais robustas e assertivas.

Um Pequeno Glossário Para Arquitetos de Software

Compilo aqui um pequeno glossário de termos usados dentro do processo de arquitetar software. Estes termos foram compilados a partir de fontes diversas da literatura de arquitetura, da experiência de colegas de trabalho e também da nossa experiência em projetos. Acredito sinceramente que estes termos podem ajudar arquitetos a comunicar conceitos e remover mal-entendidos comuns em projetos de TI, especialmente com leigos na disciplina de arquitetura de software.

Condutor Arquitetural
Uma importante diretriz, de natureza de negócio ou técnica, que conduz e influencia as decisões arquiteturais primordiais de um projeto. Os condutores arquiteturais expressam os principais elementos da estratégia arquitetural a serem observados pelo time de arquitetura.
Como exemplo, um projeto de um novo portal governamental pode ter como condutores a universalização do acesso (padrão EGov), a confidencialidade dos dados dos contribuintes e não repudiação no acesso das informações.
Condutores são negociáveis e devem ser priorizados conforme a sua importância estratégica ou tática dentro do cronograma de um projeto.
Projetos de complexidade média possuem entre seis e doze condutores. Projetos muito complexos podem ter algumas dezenas de condutores.

Princípio Arquitetural
Um princípio arquitetural é um tipo especial de condutor, que se torna tão importante que passa a ser não negociável. Um princípio arquitetural é também chamado de meta-condutor.
Como exemplo, um projeto de um home-banking pode ter como um dos seus princípios arquiteturais o elemento a segurança dos dados de um correntista, enquanto que um projeto de uma promoção de um feriado comemorativo em uma empresa de TELECOM pode ter como princípio arquitetural o tempo de mercado.
Projetos devem ter poucos princípios arquiteturais (Normalmente um número entre três e seis princípios)

Requisito Arquitetural
Um requisito arquitetural é um requisito de alto valor de negócio, alta complexidade e abrangência técnica e que permite detalhar um condutor arquitetural. Requisitos arquiteturais devem ser específicos, mensuráveis, atingíveis, realizáveis e rastreáveis. Por exemplo, no exemplo anterior da segurança para o sistema de home banking, poderíamos identificar um requisito arquitetural de autenticação que requer que usuários sejam corretamente identificados no primeiro acesso a um portal.

Requisitos arquiteturais não são necessariamente requisitos não-funcionais. Requisitos arquiteturais podem advir de requisitos funcionais, desde que estes gerem impacto para a arquitetura. Por um exemplo, um requisito de cadastro de bilhetes em um sistema de bilhetagem de TELECOM pode gerar impacto para a arquitetura de persistência, dado que as bases de dados podem precisar manter e recuperar quase 1 bilhão de registros em alguns exemplos reais no Mercado Brasileiro.

Visão Arquitetural
A visão arquitetural expressa os objetivos primários do esforço arquitetural dentro de um projeto de TI. A visão arquitetural promove o alinhamento das estratégias técnicas à visão de um produto a à estratégia de uma organização.
A visão arquitetural pode ser complementada com um primeiro rascunho ou desenho chamado de visualização de negócio (esboço arquitetural).

Visualização de Negócio
Também chamada de esboço arquitetural ou marketecture, é um diagrama de forma livre e com formas humanizadas que permite comunicar o propósito da arquitetura a todos os envolvidos de um projeto, inclusive gerentes e leigos.
Muitas vezes esta visualização de negócio é denominada, incorretamente, de arquitetura, por leigos na terminologia técnica de arquiteturas de software.

Estratégia Arquitetural
A estratégia arquitetural define a forma de atuação básica do esforço arquitetural. Advinda da escola do pensamento estratégico (OMG BMM e BSC), a estratégia é composta da visão arquitetural, da visualização de negócio e é baseada também nos princípios e condutores arquiteturais.

Tática Arquitetural
Uma estratégia é composta por um conjunto de táticas. Uma tática arquitetural, também chamada de mecanismo arquitetural por alguns autores, define uma preocupação importante no espaço da solução. Exemplos de táticas podem incluir a persistência de objetos, a interoperabilidade entre aplicações ou a auditoria.
Um tática pode ser expressa em nível de análise, nível de desenho ou nível de implementação, à medida que for refinada dentro de um projeto. Por exemplo, o requisito arquitetural que expressa que usuários sejam corretamente identificados pode ser expresso nas seguintes táticas:
• Tática de análise: Autenticação
• Táticas de desenho: Autenticação com LDAP ou Autenticação com Kerberos
• Tática de implementação: Autenticação com os produtos OpenLDAP ou Microsoft AD com Kerberos.

Plano Arquitetural
Reflete o planejamento do projeto referente às ações do time de arquitetura. Este plano é desenhado a quatro mãos pelo arquiteto de software e o gerente do projeto.

Risco Arquitetural
É um risco que pode afetar a arquitetura do projeto e eventualmente gerar um colapso técnico dentro do produto. Por exemplo, dentro de um projeto que envolva a comunicação em tempo real entre dois sistemas, a latência de disco pode ser um risco arquitetural que deve ser identificado e mitigado.

Arquitetura Candidata
É um primeiro desenho da arquitetura, com as principais decisões e estratégia do projeto. É normalmente usada para gerar um processo de viabilidade técnica do produto nas fases preliminares de um projeto. Em projetos ágeis, deveria ser o produto de um primeiro Sprint. Em projetos baseados no UP, deveria ser produzida no primeiro décimo de um projeto.
Em diversos processos e métodos, é formalizada em um documento chamado de Documento de Arquiteutra de Software (DAS).

Arquitetura Executável
Representa uma arquitetura que contenha fragmentos de códigos executáveis, normalmente produzidos para mitigar riscos arquiteturais de táticas e requisitos arquiteturais complexos. Uma arquitetura executável é refinada ao longo de um projeto, embora deva ser trabalhada com mais ênfase nas fases iniciais de um projeto.
Quando uma arquitetura executável consegue mitigar todos os principais riscos de uma arquitetura, esta é chamada de arquitetura executável estável. Em processos baseados no UP, a arquitetura executável estável é o marco de fim de fase de Elaboração.

Lean Architectures (Arquiteturas Enxutas)

O pensamento Lean, que foca na redução do desperdício na produção de produtos, foi popularizado a partir dos seus resultados práticos na Toyota, no Japão. O desperdício é muitas vezes sutil e ocorre em escala quase imperceptível ao nosso redor. Por exemplo, Uma torneira pingando uma gota a cada 5 segundos representa mais de 20 litros de água desperdiçados em apenas um dia ou 600 litros por mês.

Arquiteturas Enxutas

Este pensamento da redução do desperdício tem sido estudado e adaptado para o desenvolvimento de software há alguns anos já. O livro emblemático nesta área é o “Lean Software Development” by Mary and Tom Poppendieck. Neste livro, os autores divulgam sete princípios básicos para a produção de software que reduza o desperdício.

Naturalmente, o desenvolvimento de arquiteturas de software pode se beneficiar destes princípios. Adapto as idéias compiladas por estes autores para o dia a dia do arquiteto e do pensamento arquitetural em projetos.

• Elimine gastos desnecessários
Uma das fontes de desperdício de gastos arquiteturais é o pensamento especulativo em projeto de softwares. Exemplos clássicos são o projeto de software portáveis, com usabilidade nível WCAG A3 ou com altíssima escalabilidade na ausência completa destes requisitos pelo negócio. Infelizmente muitos arquitetos acreditam que os requisitos de qualidade vem livre de custo. Em verdade, adicionar um atributo de qualidade ao projeto pode impor um alto custo financeiro e temporal ao mesmo, o que pode ofender metas organizacionais de tempo de mercado e competitividade. Por exemplo, uma arquitetura com forneça disponibilidade de 99,9% é 10x mais cara que uma arquitetura que forneça disponibilidade 99%. Um outro exemplo de desperdício é o conceito de complexidade arquitetural acidental, que é a complexidade não inerente a um problema. Por exemplo, quando um arquiteto decide introduzir um mecanismo de comunicação distribuída entre telas e objetos de negócio (e.g. IIOP ou SOAP) em uma aplicação Web que irá operar para 10 usuários ele introduz uma enorme complexidade acidental no projeto, o que em última instância levará a desperdícios. A mensagem é clara. Atenha-se ao estritamente necessário e projete arquiteturas que gerem real valor de negócio. Requisitos arquiteturais especulativos são uma enorme fonte de gasto nos seus projetos e devem ser removidos a todo custo.
• Pratique qualidade contínua
Defeitos significam desperdícios. Projetar uma arquitetura com complexidade acidental aumentará a curva de aprendizado e introduzirá inexoravelmente mais defeitos no seu projeto. Arquiteturas com qualidade contínua promovem a redução dos defeitos com a geração da solução mais simples possível que atenda ao negócio, projeto e expectativas do cliente.
• Crie conhecimento
Planos são ótimos, mas o conhecimento é obtido através de aprendizado. Em termos arquiteturais, devemos abolir os arquitetos da torre de marfim, que criam planos desconectados da realidade. Arquitetos devem acompanhar o trabalho do time de desenvolvimento no dia a dia, aprender com os resultados e documentá-los no seu “caderno arquitetural”. O documento de arquitetura de software deve ser, portanto, vivo e melhorado continuamente a partir dos resultados práticos das provas de conceitos e casos de uso.
• Adie compromissos imutáveis
Arquitetos não devem projetar arquiteturas inflexíveis e que somente são produzidas após meses de labor. Em verdade, arquiteturas devem ser evolutivas e acomodar de forma iterativas cenários de negócio fim a fim. Um cenário de negócio não é um caso de uso, mas em verdade um corte transversal mínimo em vários casos de uso que gere um pequeno valor de negócio. Se um arquiteto projeta uma arquitetura resiliente e flexível que possa acomodar cenários ao longo do tempo, as equipes de negócio podem gerar valor de negócio (código implantado) para os participantes de um projeto em tempo reduzido.
• Entregue rapidamente
Steve McConnell e outros autores mostram que desenvolvedores sob pressão introduzem até 40% mais defeitos que desenvolvedores do mesmo nível em ambientes controlados. Defeitos são desperdícios, como dissemos anteriormente. Paradoxalmente, portanto, a chave para isso é respeitar a velocidade do time de arquitetos e desenvolvedores na montagem da arquitetura executável. Meça a velocidade de produção do seu time nas primeiras iterações e a use para planejar o projeto apropriadamente.
• Respeite pessoas
Nenhum de nós é melhor que todos nós. Em termos arquiteturais, arquitetos devem buscar a colaboração dos times para projetar as arquiteturas dos seus projetos. O envolvimento e o respeito às pessoas do time é fundamental para produzir arquiteturas mais assertivas, reduzir o retrabalho e portanto reduzir desperdícios.
• Otimize o todo
Java, .C#, ERP, MYSQL, SQL Server, Linux ou Windows não são valores de negócio. É por isso que quando vemos arquitetos brigando por posições tecnológicas baseado em preferências pessoais, é sinal que algo vai muito mal no seu projeto. Infelizmente, já vi “arquitetos” recomendarem tecnologias para órgãos do governo e empresas da área privada baseado em posições “religiosas”, com resultados desastrosos em médio prazo. Arquitetos do século XX entregam arquiteturas que são apenas escaláveis, performáticas, amigáveis ou tolerantes a falhas. Bons arquitetos do século XXI, por outro lado, devem pensar no real valor de negócio que eles estão entregando em seus projetos e portanto irão usar tecnologias como meio para atingir os benefícios do projeto. Bons arquitetos projetam arquiteturas que permitem que clientes vendam mais, atendam melhor seus consumidores, reduzam o tempo de entrega de seus produtos ou melhorem os seus fluxos de caixas. Bons arquitetos declaram os objetivos de negócio como metas finais da sua arquitetura e garantem que os seus softwares atendam a estes objetivos, acompanhamento a implantação do software fim a fim. Métodos centrados na monitoração de negócio (BAM e CEP) são importantes aliados para os arquitetos demonstrarem valor de negócio e não apenas demonstrarem pilhas tecnológicas.

Pensamento do dia: “Um homem que ousa gastar uma hora de tempo ainda não descobriu o valor da vida.”, Charles Darwin