Tendências de Arquitetura para 2012-2014

Publicado em 1 de novembro de 2011 por Marco Mendes

O Forrester Group lançou agora em Outubro seu relatório de tendências de tecnologias de negócio para arquitetura corporativa os próximos três anos (2012-2014). Faço um brevíssimo resumo do mesmo abaixo, focado em quatro das tendências apresentadas.

BPM
O  Forrester prevê uma expansão do BPM e uma fusão com eventos complexos e gestão de regras de negócio. Um conceito que surge neste contexto de unificação é o de BLMS (Business Logic Management Systems), que une em um mesmo ambiente processos, regras e eventos. Em termos tecnológicos, as soluções de BPMS, CEP e BRMS precisarão ser harmonizadas a partir de tecnologias e fornecedores distintos para gerar este valor de negócio.

BI
O BI se torna pervasivo nas organizações e se expande para analisar quantidades absurdas de informações (Big Data). Em termos arquiteturais, as arquiteturas de EDW e projetos que incorporem mercados de dados departamentais (DM) e ETLs ganham cada vez mais espaço na agenda dos arquitetos de dados.

Governança e Gestão de Dados
O MDM (Gestão de Dados Mestres) ganha espaço e começa a se integrar com iniciativas BPMS (gestão de dados de processo). As iniciativas de governança de dados ganham espaço. Em termos arquiteturais, as arquiteturas de dados mestres e questões de replicação e federação de dados se tornam cada vez mais presentes na agenda dos arquitetos. Talvez seja o momento para que os arquitetos de dados ganhem o espaço que os arquitetos de software na década 2000-10.

Computação nas Nuvens e o XAAS
A computação nas nuvens ganha ainda mais espaço e gera cada vez mais pressão econômica sobre a TI (e os gestores). Em termos arquiteturais, a análise sobre as vantagens e desvantagens da virtualização bem como sobre (qualquer coisa) como um serviço devem ser corretamente analisadas pelos arquitetos de infraestrutura.

Originalmente publicado em marcomendes.com/blog

Publicado em Arquitetura de Software, Processos de Negócio - BPM | Deixar um comentário

Potencialize a maturidade SOA do seu projeto com o SOA Source Book

Publicado em 25 de outubro de 2011 por Marco Mendes

O Open Group é um dos grandes pílares da indústria no desenvolvimento de arquiteturas corporativas. Um trabalho de excelente qualidade deste instituto é o SOA Source Book, uma verdadeira enciclopédia sobre SOA.

Destaco aqui as principais seções deste livro, disponível para consulta no site do Open Group, e que recomendo para todo arquiteto que queira trabalhar seriamente com SOA.

  • O capítulo Service Oriented Architecture traz importantes definições sobre o que é SOA, a sua relação com arquiteturas corporativas e o seu benefício para as áreas de negócio.
  • O capítulo Service Integration Maturity Model apresenta o modelo de maturidade SOA chamado OSIMM, que permite que você avalie a maturidade da sua TI para a integração de serviços, bem como aumentar esta maturidade. O OSIMM apresenta sete níveis e seis dimensões de análise (do negócio à infra-estrutura).

  • O capítulo SOA Reference Architecture apresenta os principais componentes de uma arquitetura SOA em um modelo de camadas técnicas e de governança.
  • O capítulo Service Oriented InfraStructure apresenta os padrões mais adequados para a integração de aplicações, dados e hardwares para a montagem de uma fundação SOA (infraestrutura). Além disso, este capítulo traz um modelo de referência para a infraestrutura SOA.
  • O capítulo SOA e TOGAF apresenta o SOA no contexto do TOGAF , que é o framework de arquitetura corporativa do Open Group.
  • O capítulo de Governança SOA traz um dos elementos mais críticos a qualquer implementação SOA

A edição 3 do livro, lançada em Outubro de 2010, trouxe um excelente apêndice sobre ontologias SOA, para arquitetos que querem compreender os meta-modelos que formam os elementos SOA.

Publicado em Outros | Deixar um comentário

Como construir um Curriculum Mortis (em dez lições)

Publicado em 24 de outubro de 2011 por Marco Mendes

A maioria dos profissionais constroem um belo Curriculum Vitae ao longo das suas carreiras. Outros profissionais criam, ao invés, um pavoroso Curriculum Mortis à medida que passam por algumas empresas.

Compartilho aqui dez lições para criar um Curriculum Mortis (baseado em casos reais).

  1. Mudar de empresa a cada 6 meses. Vemos profissionais com 5 anos de profissão e quase 10 empresas no currículo. Promiscuidade similar, somente em micaretas.
  2. Negociar com uma empresa enquanto já estiver empregado em outra para conseguir uma oferta salarial melhor e então usar esta oferta para conseguir um aumento na empresa original. Leilão de salário.
  3. Faltar no trabalho e mentir sobre o motivo. E hajam tias e vós mortas para justificar estas desculpas.
  4. Não investir nenhum tempo pessoal para se atualizar na profissão. Vemos profissionais com 20 anos de experiência (em fazer a mesma coisa errada).
  5. Gastar 40 minutos diários nos cafés e conversas de corredor.
  6. Se intitular pleno após colocar o primeiro projeto em produção. Para que você possa pensar a respeito, a palavra plenitude, no dicionário, significa: “s.f. Estado ou qualidade do que está completo, cheio, inteiro. Totalidade.”
  7. Se intitular sênior após colocar o segundo projeto em produção.
  8. Se intitular Mestre Jedi após colocar o terceiro projeto em produção.
  9. Se certificar sem nunca ter trabalhado com o assunto alvo da certificação (e ostentar esta certificação na assinatura do seu email para todos).
  10. Manipular e usar indevidamente o trabalho dos colegas de profissão para agradar e ganhar o respeito dos chefes.

Pensamendo do dia: “Try not to become a man of success but rather try to become a man of value”, Albert Einstein

Publicado em Pessoas | 2 comentários

Casos de Uso 2.0

Publicado em 23 de outubro de 2011 por Marco Mendes

O conceito de casos de uso foi criado em 1986 por Ivar Jacobson, metodologista e um dos pais do processo unificado. Depois de 25 anos, temos uma evolução na teoria de casos de uso feita pelo próprio autor, influenciado fortemente por métodos ágeis. Descrevo aqui as principais novidades do conceito de Casos de Uso 2.0, publicado pelo autor agora no fim de Setembro em um congresso do IIBA (International Institute of Business Analysts).

Abordagem Iterativa – Fatias de Casos de Uso

Um caso de uso é um conjunto de histórias estruturadas na forma de narrativas. Casos de uso complexos podem ter diversos fluxos alternativos e dezenas de casos de teste. Muitas vezes o tamanho do caso de uso é proibitivo para acomodar entregas curtas em métodos ágeis.

Uma fatia de caso de uso é criado através da seleção de uma história para implementação. É fundamental que uma fatia de caso de uso entregue “valor”, i.e, gere uma experiência de teste para o usuário.

 

Uma fatia de casos de uso é, então, um combinação de fluxos que permite que casos de teste sejam realizados. A figura abaixo exemplifica este conceito para um caso de uso complexo que tenha 15 fluxos alternativos (um verdadeiro épico). Ele é então fatiado em pequenos pedaços, que podem ser adequadamente mastigados pelo time.


O próprio levantamento do requisito pode ser iterativo. Isto é, não precisamos conhecer todo o caso de uso para que o fatiemos para desenho e implementação.

Fatias de Casos de Uso e o Backlog de Tarefas

A figura abaixo mostra três fatias de um caso de uso. É interessante notar que as pequenas fatias podem gerar os itens de trabalho de um backlog no nível necessário para acomodar pequenas entregas, conforme a velocidade do seu time.


O processo da narrativa do caso de uso – Foque na amplitude

É importante mencionar um aspecto também enfatizado por Jacobson, à luz do que Allistair Cockburn já fazia no livro Escrevendo Casos de Uso Eficazes, que é uma narrativa iterativa. Em outras palavras, começamos a narrativa do caso de uso de forma bem leve, sempre trabalhando em amplitude. Com a identificação dos nomes dos fluxos alternativos, por exemplo, já podemos derivar as fatias de casos de uso.

Fatias de casos devem ser unidades testáveis

O leitor mais atento já deve ter percebido isso. Casos de uso devem guiar os testes e o conceito de fatia de caso de uso é o elo para este trabalho. A figura abaixo mostra esta ligação. Uma fatia de caso de uso permite que todo o trabalho do time de desenvolvimento e testes seja acionado até que os testes passem e esta fatia de casos de uso seja marcada como realizada.

Considerações Finais

Ao final de sua apresentação, Ivar Jacobson faz o seguinte resumo:

  • casos de uso ainda são casos de uso;
  • eles provem contexto para nossas conversações (usuários e sistemas);
  • nós devemos apenas modelar o que for importante;
  • nós fatiamos os casos de uso para dirigir o desenvolvimento;
  • nós eliminamos o desperdício usando o nível de detalhamento mais leve possível;
  • nós definimos o caso de teste como parte do caso de uso para definir o PRONTO PARA O USUÁRIO;
  • nós usamos cartões e backlogs para suportar métodos ágeis;
  • nós adicionamos detalhes para lidar com comunicação distribuída (times geograficamente distribuídos)
Publicado em Requisitos | Deixar um comentário

O Manifesto SOA

Publicado em 8 de agosto de 2011 por Marco Mendes

(traduzido para o português)

A orientação por serviços é um paradigma que orienta o que você faz. A arquitetura orientada por serviços (SOA) é um tipo de estilo arquitetural 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 e custos eficazes, alinhado às necessidades de mudanças nos seus negócios.
Através do nosso trabalho nós priorizamos:

Valor para o negócio sobre estratégias técnicas.
Objetivos estratégicos sobre benefícios específicos de projetos.
Interoperabilidade intrínseca sobre integrações personalizadas.
Serviços compartilhados sobre implementações com propósitos específicos.
Flexibilidade sobre otimização.
Refinamentos evolucionários sobre a procura da perfeição inicial.

Isto é, embora nós valorizemos os valores da direita, nós valorizamos mais os itens à esquerda.

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 paradigma
de orientação de serviços para você

SOA pode ser implantado através de uma gama variada de
tecnologias e padrões

Estabelecer um conjunto uniforme de políticas e
padrões corporativos baseado em padrões da indústria,
padrões de facto e padrões da comunidade.

Buscar uniformidade no exterior a medida que
permita diversidade no interior

Identificar serviços através da colaboração de pessoas
de negócio e tecnologia

Maximizar o uso de serviços considerando o escopo
atual e futuro da organização

Verificar se os serviços satisfazem os objetivos e
requisitos de negócio

Evoluir os serviços da organização em resposta ao seu real uso

Separar os diferentes aspectos do sistema para
mudar em velocidades diferentes

Reduzir as dependências implícitas e
publicar as dependências externas para
aumentar a robustez e reduzir o impacto das mudanças

Em qualquer nível de abstração, organizar
cada serviço em torno de unidades
de funcionalidades coesas e gerenciáveis

 

Publicado em SOA | Deixar um comentário

O complexo caminho da simplicidade em Java

Publicado em 8 de agosto de 2011 por Marco Mendes

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.

@Stateless
class Cliente {
   public void metodo() {
     // Meu metodo remoto….
   }
}
Se você desejar criar um objeto distribuído que responda através de SOAP, i.e, um WebService, basta adicionar uma outra linha de código, conforme mostrado abaixo.
@WebService
@Stateless
class Cliente {
   public void metodo() {
     // Meu metodo remoto…
   }
}
Entretanto, se olharmos as especificações anteriores do EJB, veremos que esta simplicidade foi alcançada depois de muito trabalho na remoção de complexidades.

Por exemplo, o mesmo código em EJB 3.0 requer uma classe e duas interfaces Java, conforme mostrado abaixo:

 

@Local
interface ClienteLocal {
   public void metodo();
}
@Remote
interface ClienteRemote {
   public void metodo();
}
@Stateless
public class Cliente implements ClienteLocal, ClienteRemote {
  public void metodo() {
     // Meu metodo remoto….
  }
}
Mais impressionante é notar que na especificação EJB 2.1 este mesmo exemplo seria implementado como uma interface local, uma interface remota, uma interface home, uma classe de implementação de negócio, uma classe de implementação da interface home e alguns arquivos XML. Um exemplo arqueológico pode ser encontrado aqui para os mais curiosos. Para criar um único método distribuído, precisamos de várias dezenas de linhas de código.

Se observamos ainda mais atrás no tempo um objeto CORBA, fonte de inspiração dos primeiros EJB, veremos ainda um código mais complexo.

Felizmente temos observado este movimento de simplificação de APIs em vários outros lugares da API Java. O JBOSS Seam inspirou a simplificação do JSF na nova especificação do JSF (JSF 2.0), conforme podemos observar neste artigo em anexo.

O modelo de servlets também foi simplificado. Agora podemos ter Servlets que são configuradas puramente com anotações ao invés de arquivos XML, conforme podemos ver no exemplo abaixo:

@Servlet(urlMappings={“/MinhaAplicacao”})
public class MinhaServlet {
    @GET
    public void tratadorGet(HttpServletRequest request,
                          HttpServletResponse response) {
                ….
    }
}
 

Um ambiente que já suporta estas novidades de simplicidade é o NetBeans 6.8. Notavelmente, o NetBeans tem conseguido “roubar” muita audiência dos desenvolvedores Java justamente por ser mais simples do que o poderoso (mas complexo) Eclipse. Para os programadores Java que nos leem, um tutorial é fornecido aqui.

Pensamento do dia: “Tudo deveria ser mantido o mais simples possível, mas não mais simples que isso”, Albert Einstein.

Pensamento do dia seguinte: “Se em tudo o mais forem idênticas as várias explicações de um fenómeno, a mais simples é a melhor””, William de Ockham

Publicado em Java | Deixar um comentário

Guias MPS-BR

Publicado em 8 de agosto de 2011 por Marco Mendes

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: 2009 (Outubro de 2009)
Este guia contém orientações para a implementação do Modelo de Referência MR-MPS em organizações do tipo Fábrica de Software.

- Guia de Implementação – Parte 10: 2009 (Outubro de 2009)
Este guia contém orientações para a implementação do Modelo de Referência MR-MPS em organizações do tipo Fábrica de Teste.

Estes novos guias mostram a necessidade de personalização de processos para segmentos específicos da indústria e também indicam um caminho de aumento de maturidade para organizações de TI sérias mas que infelizmente não possuíam um modelo de referência para trabalhar.

Pensamento do dia revisitado: “Um longo tempo é necessário para trazer a excelência à maturidade”, Publius Syrus, Séc. I A.C.

Publicado em Engenharia de Software | Deixar um comentário

Motores de Regras de Negócio – BRMS

Publicado em 8 de agosto de 2011 por Marco Mendes

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 BRMS (Business Rules Management Systems).

Um BRMS não nos é útil se não entendermos o conceitos primário de uma regra de negócio, descrito abaixo.

Regras de Negócio – Átomos de Negócio do Domínio

Uma regra de negócio expressa uma restrição sobre um domínio de negócio. Um exemplo simples é mostrado abaixo:
Se o cliente possuir cadastro de crédito positivo no SERASA, então o desconto sobre o financiamento será de 1%

A premissa de um motor de regras é que as regras podem ser expressas e mantidas em uma linguagem natural (ou uma aproximação) e portanto permitem uma velocidade e responsividade muito maior da TI a alterações regulatórias e de inovação nas áreas de negócio. Em tese, a mudança da regra de desconto de um financiamento de crédito pode ser totalmente implementada por um analista de negócio em um sistema BRMS, sem conhecimentos profundos dos complexos padrões WS-* e de linguagens pouco produtivas como Java, COBOL ou C++.

Regras não são um agrupamento desordenado de textos. Um modelo de regras deve ser identificado e organizado a partir de um conjunto de critérios formais tais como:

  • um vocabulário de negócio que exprime a semântica dos conceitos sendo trabalhados em um domínio – Fatos;
  • um conjunto de proposições que permitem a geração de conhecimento a partir destes fatos.

No exemplo acima, podemos identificar como fatos primários o CLIENTE e o FINANCIAMENTO. A proposição do exemplo usa o crédito do CLIENTE para estabelecer uma política de desconto sobre o FINANCIAMENTO.

Um modelo formal para compreender como estruturar regras de negócios é o OMG SVBR, cuja versão 1.0 está disponível aqui. Recomendo fortemente que os iniciados em BRMS estudem este documento antes de abrir e trabalhar com uma suíte BRMS. O documento pode parecer tedioso, mas assim como para dirigirmos um carro precisamos de aulas de legislação, precisamos entender que suítes BRMS estão baseados em conceitos não tão populares que precisam ser entendidos. Para os mais apressados, uma boa introdução ao tema está disponível aqui.

Outras especificações relacionadas são o OMG BMM (que motra o papel das regras de negócio dentro da modelagem de negócio) e o OMG PRR (que mostra como um programa computacional pode ativar inferências a partir de um conjunto de regras de negócio e uma memória de trabalho). O PRR é, em termos leigos, o mecanismo de inteligência artificial usado pelos motores de regras. O BMM, por sua vez, permite entender como o BRMS está ligado com o BPM e as estratégias corporativas.

Suítes BRMS

Um BRMS parece ser apenas uma ferramenta, mas como o próprio nome diz ele se refere a um conjunto de ferramentas, onde cada ferramenta tem um propósito. Listo abaixo algumas categorias de ferramentas BRMS:

  • Sistemas de produção de regras. Sistemas baseados em algoritmos de produção de regras como o RETE. Normalmente permitem que analistas e desenvolvedores expressem regras em uma linguagem natural baseada em critérios IF/THEN. Um exemplo de ferramenta nesta linha é o Drools Expert.
  • Sistemas de processamento de eventos (CEP). Eventos são regras temporais que podem ser expressas da forma WHEN/DO e permitem a construção de sistemas que reajam a eventos e realizem algum tipo de raciocínio temporal/espacial. Um exemplo de evento seria: Quando houver três transações de débitos no cartão em menos de trinta minutos em três estabelecimentos comerciais diferentes, realizar o bloqueio do cartão e solicitar que um atendente ligue para o proprietário do cartão para confirmar o desbloqueio. Uma ferramenta nesta linha é o Drools Fusion.
  • Sistemas de governança de regras. É fácil criamos centenas ou milhares de regras em uma implementação BRMS. É mais fácil ainda perdemos a governança sobre estas regras. Regras possuem versões, dependências e impactos sobre outras regras. Portanto, possuir um sistema de governança de regras é fundamental em implementações BRMS. O Drools Guvnor é um exemplo deste tipo de ferramenta.
  • Um ambiente de desenvolvimento para criarmos regras. Um exemplo nesta linha é o plugin Eclipse JBOSS Tools, que permite a criação e manutenção de regras de negócio no Drools.
Publicado em Arquitetura de Software, Plataformas | Deixar um comentário

Pontos de entrada SOA

Publicado em 8 de agosto de 2011 por Marco Mendes

Um conceito muito importante no mundo SOA é a escolha do ponto de entrada. Um ponto de entrada descreve para uma empresa, área de negócio ou mesmo uma unidade de negócio qual a melhor abordagem arquitetural para uma automação SOA.

Os principais pontos de entrada SOA são:

  • Integração de pessoas;
  • Integração de processos;
  • Integração de aplicações (conectividade);
  • Integração de informações;
  • Reuso.

Um ponto de entrada de pessoas por exemplo irá demanda uma abordagem arquitetural baseada em serviços visuais. Tecnologias como portais, mash-ups, portlets, sindicalização, colaboração, fluxos de trabalho/workflows devem fazer parte da sua agenda técnica.

Um ponto de entrada de processos, por outro lado, irá demanda uma abordagem arquitetural baseada em serviços de processo e serviços de negócio. Tecnologias como BPMN, BPEL, orquestração e coreografia e processos e motores de execução de processos farão para da sua agenda técnica.

Um ponto de entrada de integração de informações, para citar um outro exemplo, nos leva a uma plataforma de serviços de dados. Tecnologias e conceitos como replicação de dados, federação de dados, bancos federados, caches, GEDs, entre outros, irão fazer parte da sua agenda.

A natureza operacional da sua unidade de negócio determina os pontos de entrada SOA

Pode parecer que *nós*, analistas e arquitetos, temos livre arbítrio para escolher qual o ponto de entrada que desejamos usar. Entretanto, isso não pode estar mais longe da verdade.

A natureza e o modelo operacional de uma empresa, uma área ou mesmo unidade de negócio demanda maior ou menor necessidade de integração de dados e integração de processos. Nem sempre uma grande integração de dados e uma grande integração de processos é necessária. Uma holding, por exemplo, necessita de grande integração de dados mas baixa integração de processos. Cada empresa que compõe a holding, entretanto, pode ter diferentes necessidades e assim recursivamente nas suas unidades de negócio.

Conforme estas necessidades de integração, podemos derivar quais capacidades de TI serão mais úteis e mais corretas para que possamos então escolher um melhor modelo SOA para a nossa área, unidade de negócio ou empresa. Escolher o SOA correto para a sua unidade de negócio tem a ver com eficácia e com o alinhamento das ações de TI com a arquitetura de negócio da sua empresa.

Para os mais céticos, basta olhar os portifólios de produtos que trabalham com SOA. A JBOSS, por exemplo, tem diferentes suítes de produtos para diferentes abordagens arquiteturais. O JBOSS MetaMatrix (TEIID), por exemplo, é para o SOA baseado em serviços de dados e faz parte do JBOSS Data services Platform. O JBOSS jBPM, por outro lado, é para o SOA baseado em serviços de processo e serviços de negócio. O JBOSS Portal, como um terceiro exemplo, é para o SOA baseado em integração de pessoas e faz parte do Portal Platform.

Nas empresas líderes SOA de mercado (IBM, Oracle/BEA/SUN, TIBCO), a segmentação do portfólio é ainda mais aparente e os pontos de entrada SOA são uma boa forma de digerir e entender como a oferta de valor destas empresas pode ser melhor para a sua empresa.

Antes de começar a sua implementação SOA, então, faça a seguinte pergunta: “Qual o melhor SOA para a minha empresa?”.

Publicado em SOA | Deixar um comentário

Arquitetura de Negócio

Publicado em 8 de agosto de 2011 por Marco Mendes

Arquitetos de software de verdade investem grande parte do seu aprendizado em técnicas arquiteturais. Exemplos destas técnicas incluem o modelo de visualização 4+1 de Kruchten, processos de software, os modelos SEI QAW, ATAM, CBAM, V&B e ADD, os modelos de requisitos FURPS+, ISO 9126, ISO SQUARE, as recomendações arquiteturais da norma IEEE 1471, técnicas de liderança de times e mesmo modelos de arquiteturas corporativas como o TOGAF ou o Zachman Framework.

A notícia boa é que este corpo de conhecimento técnico permite que o arquiteto projete, elicite requisitos, modele, experimente, prove conceitos com código, acompanhe a sua equipe e edifique toda a arquitetura técnica de um produto.

A notícia ruim é que mesmo este corpo gigantesco não garante o bem mais esperado de uma arquitetura de software, que é o alinhamento às estratégias de uma organização.

A notícia pragmática, então, é uma arquitetura de software somente deve existir para servir à uma arquitetura de nível superior, chamada de arquitetura de negócio. A arquitetura de negócio não é um super-conjunto da arquitetura de software. Ela é apenas uma arquitetura que existe em outro plano.

Uma arquitetura de negócio é uma macro-organização que descreve o modelo operacional de uma organização, suas áreas de negócio, seus processos de negócio nucleares e os seus atores de negócio.

Para tornar o concreto o nosso raciocínio, uso como exemplo o eTOM dentro so segmento de TELECOM. o eTOM é um guia com a descrição dos processos de negócio para um provedor de serviços de telecomunicações.

Um outro exemplo concreto é o SCOR, modelo de referência para empresas que possuam complexas cadeias de fornecimento (supply-chains).

Um terceiro exemplo, dentro do governo Brasileiro, é a empresa de referência da ANEEL. Esta empresa de referência serve como modelo operacional para qualquer concessionária de distribuição de energia elétrica, descrita no documento supracitado através de um conjunto de motivadores de negócio, processos de negócio, regras de negócio e modelo organizacional.

Um quarto exemplo é o ITIL, que é uma arquitetura de negócio para operações e serviços de TI.

Ao saber mais do contexto onde atuamos como arquitetos, podemos escolher entre soluções técnicas mais adequadas e coerentes. Podemos usar melhor os recursos escassos da TI e gerar mais valor de negócio para estas empresas.

Para se tornar um melhor arquiteto e saber mais sobre arquiteturas de software, estude mais as arquiteturas de negócio das verticais de atuação da sua empresa.

Pensamento do dia: A primeira lei da automação, por Bill Gates – “A automação de um processo de negócio eficiente irá aumentar a sua eficiência operacional”

Publicado em Arquitetura de Software | Deixar um comentário