O documento discute a separação entre o conhecimento do negócio e a tecnologia em sistemas corporativos. Ele argumenta que as necessidades do negócio e da tecnologia requerem abordagens distintas e que a solução conceitual deve ser definida completamente antes da implementação técnica.
3. Definindo dois universos diferentes
Conhecimento do negócio
● entendimento do domínio do problema (jurídico, obras, ...)
● necessidades dos clientes (o que é ou não importante)
● como atendê-las (solução conceitual)
Tecnologia
● interface com usuário (HTML, Swing, WinForms)
● middleware (SOAP, REST, CORBA, JMS, sockets)
● gerenciamento de dados (SQL, No-SQL, prevalence)
● linguagens de programação (Java, Delphi, RoR, PL-SQL)
● ambiente operacional (hardware, SO, rede etc)
● paralelismo, transações, distribuição, logging,
auditing, síncrono vs. assíncrono, local vs. remoto, ativo
vs. passivo...
4. Comparando dois universos diferentes
Conhecimento do negócio
● a essência do valor da solução (o "fim")
● diferencial competitivo
● independente de tecnologia
● estabilidade: variável, mesmo que domínio
Tecnologia
● custo de se construir solução concreta (o "meio")
● não é diferencial competitivo significativo (commodity)
● independente de domínio
● trivial, bem compreendida, padronizada, repetitiva
● estabilidade: volátil (um a dois anos)
5. Cenário típico
● requisitos espalhados, em forma não estruturada, imprecisa,
incompleta (documento Word, wiki, sistema de tickets, emails)
● solução conceitual em modelos UML
imprecisos/incompletos/desatualizados ou perdida no código
● solução conceitual só pode ser validada após construção
● mudanças de natureza conceitual requerem muito esforço para se
identificar a "intenção" do código existente
● mudanças de natureza técnica têm grande impacto na aplicação
(afetam vários artefatos), normalmente feitas parcialmente
● inconsistência impera
Checkpoint
6. Problema
Negócio e Tecnologia
têm natureza completamente diferentes.
As necessidades do negócio e da tecnologia
requerem tratamento distinto e separado.
7. Solução
● solução conceitual é completamente definida antes da
implementação
● linguagem própria para solução conceitual (nível de
abstração mais adequado, independência de tecnologia)
● testes de unidade e aceitação definidos no nível
conceitual (codificação precisa dos requisitos)
● avaliação de solução conceitual via protótipo (comunicação
entre stakeholders técnicos e do negócio)
● estratégias de implementação definidas como
mapeamentos automáticos (reuso de decisões técnicas,
agilidade na evolução da arquitetura)