Sob a perspectiva da arquitetura corporativa, o conceito de “serviço” tem um significado amplo, explicado em três camadas. Primeiro, há o entendimento de “serviço” sob a perspectiva de negócio – ou seja, um “comportamento” exposto por um ator (pessoa, departamento, divisão negócios) para seu contexto de atuação. Segundo, há o entendimento de “serviço” sob a perspectiva de aplicações – ou seja, software que dá suporte a execução das atividades previstas para o “serviço de negócio”. Finalmente, há o entendimento de “serviço” sob a perspectiva de tecnologia – ou seja, o aparato tecnológico necessário para suportar os “serviços de aplicação” que, por sua vez, suportam os “serviços de negócio”.
Explicitando o que é necessário para um “serviço do negócio”
Uma boa forma de “explicar a individualidade” de uma organização é explicitar os serviços que ela presta. Por exemplo, uma loja de eletrônicos que, além de vender, realizar reparos e “tirar dúvidas de uso”, seguramente será diferente de outra que “apenas vende”.
 | Do Tech ao Biz Diferenciando Estratégia, Tática e Operação São nos resultados da operação, ao longo do tempo, que ficam demonstrados os impactos das melhorias implantadas nas iniciativas estratégicas – com a ajuda das práticas de arquitetura corporativa.Nesse capítulo são explicados os conceitos de estratégia, tática e operação. |
Os serviços de uma organização não se realizam sozinhos – eles são a expressão das capabilities desenvolvidas na empresa – tangibilizadas em papéis (com responsabilidades específicas), processos e artefatos.
O diagrama indicado abaixo aponta algumas “questões a responder” quando se está “modelando” um serviço de negócios.
Que serviço está sendo modelado? Como será demandado ou acompanhado? Que atividades serão necessárias para a prestação do serviço? Quem fará o trabalho? Que artefatos serão gerados?
Na visão do modelo, indicada no diagrama acima, por exemplo, temos a modelagem de um serviço hipotético de “suporte técnico a clientes” que responde as questões propostas. Está “respondido” que o meio de contato com o suporte é e-mail, que as atividades tem relação com “Suporte de Nível 1” e são executadas por um atendente de suporte. Além disso, que registros de atendimento são gerados.
Relacionando “serviços do negócio” com software
Na abstração, indicada no diagrama acima, sugere-se que as perguntas que “começam” o pensamento para arquitetura de um software têm relação íntima com a modelagem de um serviço de negócio.
Como features de software poderiam colaborar com o trabalho? Como elas deveriam ser acessadas? Em qual software da organização essas features deveriam ser implementadas? Quais são as principais demandas funcionais dessas features? Quais serão os “dados persistentes” serão produzidos?
A visão do modelo, indicada no diagrama acima “conecta” o serviço de aplicação “Customer Supporting” as atividades necessárias para o cumprimento do serviço de negócio “Customer Technical Support“.
No diagrama, sugere-se que as atividades de “suporte nível 1” devam ser suportadas por um software CRM, acessível através de um “cliente web”, que oferece tracking de interações e um KB. Também fica indicado que os “registros de atendimento” são “materializados” com cadastros de clientes e registros de interações.
Arquitetura de soluções
Uma vez que a arquitetura corporativa expressa a relação de alto nível de componentes necessários para atender o negócio, cabe a arquitetura de soluções identificar a melhor forma de “implementar” tais componentes. Eventualmente, isso implica na contratação de recursos prontos (no exemplo, a aquisição de uma solução de CRM), ou ainda, na especificação de demandas para o desenvolvimento de software novo, demandando atividades de arquitetura de software.
 | Definindo arquitetura de software e o papel do arquiteto Manual do arquiteto de software As atividades relacionadas a arquitetura de software nem sempre são entendidas, assim como o papel do arquiteto de software. Entretanto, são essenciais para garantir a competitividade em organizações digitais. O arquiteto de software parte das definições explicitadas na arquitetura corporativa para “orquestrar” o desenvolvimento de software.Nesse capítulo, explico o que é arquitetura de software, bem como o papel do arquiteto. |
Relacionando “serviços do negócio” e software com a infraestrutura tecnológica
Para atender as demandas do negócio, software demanda infraestrutura tecnológica.
A abstração proposta acima sugere questionamentos importantes para determinar a infraestrutura tecnológica adequada, para suportar aplicações que, por fim, viabilizam a execução de serviços de negócio.
Qual é a contribuição esperada da infraestrutura tecnológica para o negócio? Que recursos devem ser disponibilizados e como eles irão ser acessados? Que capacidades tecnológicas precisam ser provisionadas?
Na visão do modelo, indicada no diagrama acima, entendemos que a infraestrutura tecnológica suporta a ferramenta de CRM, fornecendo mecanismos para armazenamento dinâmico e estático. Uma base de dados Oracle precisará ser mantida, bem como suporte a execução de aplicações .NET e um sistema de arquivos – tudo em servidores on-premises.
Para pensar…
As visões de modelo, expressas nos diagramas desse capítulo, mostram a abrangência da arquitetura corporativa na modelagem de serviços. Há, pelo menos quatro especialidades envolvidas: negócios, soluções, software e infraestrutura tecnológica. Cada uma delas com complexidades inerentes e especificidades. Ou seja, o “projeto de serviços” é naturalmente complexo. Enquanto isso, a competitividade, em empresas modernas, depende da excelência dos serviços na operação de negócios – que é corroída pela complexidade.
É fácil reconhecer que uma das maiores contribuições da arquitetura corporativa está na orquestração das atividades de especialistas, mitigando complexidades predatórias. Sem a devida orquestração, é fácil que sejam desenvolvidos “serviços de aplicação” sobre ou subdimensionados para suportar os “serviços de negócio”. Da mesma forma, é fácil que a infraestrutra tecnológica fique desajustada, cara demais ou insuficiente, frente aos benefícios proporcionados.
Os relacionamentos explicitados nas visões de modelo fornecem, além de clarificação, capacidade de rastreamento das justificativas decisões – colaborando para o ganho de assertividade.
// TODO
Antes de avançar para o próximo capítulo, recomendo as seguintes reflexões:
- Como são “orquestradas” as atividades de design de negócio, arquitetura de soluções, arquitetura de software e infraestrutura tecnológica em sua organização hoje?
- Como as decisões técnicas, tanto em software quanto em infraestrutura tecnológica, são “justificadas” na sua organização?
