|
|||||
|
A arquitetura de software pode ser entendida como um domínio da arquitetura corporativa. Inclusive, é dentro de tal contexto que o mais eficaz valor da arquitetura de software é realizado: o alinhamento com o negócio. Antes de prosseguirmos, convém definir “arquitetura corporativa”. “A arquitetura corporativa define a coleção de capacidades de negócio, processos, serviços de negócio, serviços tecnológicos e infraestrutura de TI para realizar tais capacidades.” – TOGAF TOGAF (The Open Group Architecture Framework) é um dos corpos de conhecimento em arquitetura corporativa. A saber, alguns outros:
A arquitetura corporativa se preocupa com as capacidades da organização, enquanto que a arquitetura de software é apenas um dos aspectos para desenvolver tais capacidades. Abaixo relacionamos o senso comum sobre os domínios da arquitetura corporativa.
Arquitetura de negócio é composta por:
Arquitetura de dados é composta por:
Arquitetura de aplicação descreve o grupo lógico das capacidades para gerenciar objetos de dados necessários para processar os dados e o negócio. E, finalmente, a arquitetura tecnológica:
A arquitetura de software, ao mesmo tempo que se preocupa fortemente com a arquitetura de sistemas de informação (aplicações e dados), se relaciona diretamente com a arquitetura de negócios e arquitetura tecnológica. O relacionamento com a arquitetura de negócio provê um alinhamento natural com o contexto organizacional, as estratégias corporativas e os processos de negócio. Além disto, a estreita ligação com a arquitetura tecnológica garante que a fundação de TI estará apta a suportar aplicações com necessidades de negócio perfeitamente endereçadas. A arquitetura de software, dentro de uma abordagem corporativa, certamente terá maiores chances de transformar o software em valor real para a companhia. A prática de BPM é normalmente definida como a “modelagem, simulação, automação, monitoração e gerenciamento dos processos de negócios essenciais de uma organização”. Esta definição guarda um conceito importante, que é a necessidade de conhecermos o que são os processos essenciais. Uma técnica importante para descobrir quais são os processos essenciais é o uso de capacidades de negócio. Uma capacidade de negócio representa uma abstração de negócio que represente a natureza de uma organização e quer normalmente requer alavancagem. Alguns exemplos para tornar concreto o nosso raciocínio poderiam incluir:
Capacidades de Negócio – A bússola BPM  Oriente seus processos de negócio pelas capacidades de negócio que melhor definem a natureza da sua organização ou unidade de negócio As capacidades de negócio definem atributos sobre um sistema empresarial e permitem expressar a natureza do negócio desta organização. Capacidades complementam a visão clássica de BPM. Enquanto o BPM responde “COMO”, as capacidades de negócio dizem “O QUE” e nos auxiliam nos motivadores de negócio – “POR QUE”. Uma vez que tenhamos descoberto as capacidades de negócio, podemos focar no mapa de processos. Todo e qualquer processo que não esteja aderente a uma capacidade de negócio será descartado. Apenas os processos de negócio aderentes às capacidades de negócio serão alvo do nosso esforço BPM. Esta iniciativa pragmática permite focar e saber que o nosso esforço será eficaz. Para os praticantes de SOA, as capacidades de negócio criam um caminho confiável e assertivo para as integrações sistêmicas e automações de processos de negócio. Para os interessados, um artigo introdutório a respeito está disponível aqui no Microsoft Architecture Journal. Para os realmente interessados, um artigo sobre o modelo de engajamento de TI às capacidades de negócio de uma organização baseado no excelente trabalho de Jeanne Ross está disponível aqui.
A abordagem tradicional para SOA está baseada nas premissas da modelagem, simulação, automação, monitoração e gerência de processos de negócio, i.e, o ciclo de vida de BPM (Gerenciamento de Processos de Negócio). Existem diversos cenários, entretanto, onde esta premissa não se torna válida.
Caso a nossa empresa ou o problema em questão apresente a lista de [...]
Os Princípios do Manifesto SOA
Nós seguimos estes princípios:
Respeitar a estrutura social e de poder de uma organização.
Reconhecer que SOA requer mudança em vários níveis
O escopo da adoção de SOA pode variar. Devemos manter os seus esforços gerenciáveis e dentro de limites significativos
Produtos e ferramentas sozinhos não lhe fornecerão SOA ou aplicarão [...]
O Manifesto SOA
A orientação por serviços é um paradigma que orienta o que você faz. A arquitetura orientada por serviços (SOA) é um tipo de arquitetura que resulta da aplicação da orientação por serviços. Nós aplicamos a orientação por serviços para ajudar organizações a entregar valor de negócio de forma sustentável, com agilidade aumentada [...]
Para um novato Java que queira criar um EJB na especificação 3.1, o processo é muito simples. Você cria uma classe Java e com apenas uma anotação você tem um objeto distribuído que responde via protocolo RMI/IIOP.
Se você desejar criar um objeto distribuído que responda através de SOAP, i.e, um WebService, basta adicionar uma outra [...]
O MPS-BR, modelo Brasileiro de maturidade de software, está evoluindo a pleno vapor. Três novos guias estão disponíveis no portal do MPS-BR.
- Guia de Implementação – Parte 8: 2009 (Outubro de 2009)
Este guia contém orientações para a implementação do Modelo de Referência MR-MPS em organizações que adquirem software.
-Guia de Implementação – Parte 9: [...]
Depois de um longo e pesado Setembro, estamos de volta ao nosso bom hábito de escrever. Desta vez gostaria de falar sobre uma habilidade cada vez mais valorizada pela empresas de TI, que são os “soft skills˜, ou habilidade suaves, em uma tradução literal. Estas habilidades são muito enfatizadas pelos agilistas e escolas ágeis e [...]
Com a popularização de projetos SOA, também houve um renascimento do conceito de motores de regras (Rule Engine). Mas o que são motores de regras?
Um motor de regra é um sistema computacional que tem a capacidade de executar um conjunto de regras de negócios em um ambiente de produção. Eles são chamados em inglês de [...]
Um dos gaps existentes nos times de desenvolvimento de software é a distância entre a concepção e desenho da arquitetura e sua efetiva realização. Motivos para este problema incluem:
Mudanças de escopo e mudanças nas prioridades dos condutores e requisitos arquiteturais,
Ausência de desenvolvedores na definição da arquitetura. Quando uma pessoa não participa da definição [...]
|
|||||
|
Copyright © 2013 Arkhi - All Rights Reserved |
|||||
