Um PSS integra diversos elementos de naturezas distintas: produto, serviços, processos, organização e infraestrutura (ICT e recursos). Da mesma forma, a arquitetura de um PSS deve integrar a arquitetura desses elementos.
A arquitetura do PSS relaciona e mostra interfaces entre os principais elementos do modelo de negócio em um nível mais detalhado para direcionar o design detalhado da solução completa.
Objetivos
- Consolidar o conceito do PSS;
- Estruturar os principais elementos que compõem o PSS;
- Estabelecer os relacionamentos e interfaces dos elementos do PSS para guiar o detalhamento da solução.
Para atingir a arquitetura final de um PSS, precisamos definir cada uma das arquiteturas que o compõem:
- Arquitetura de Produto
- Arquitetura de infraestrutura (ICR e recursos)
- Arquitetura de processos de negócios e serviços
É mais fácil criar a arquitetura final do PSS após ter criado cada uma dessas arquiteturas, pois basta interconectar os itens das arquiteturas que se relacionam ou possuem alguma interface.
Relação com outras atividades
A arquitetura de PSS deve estar alinhada com a estratégia da organização para que possa representar a solução em desenvolvimento de forma concreta.
A arquitetura representa os elementos do modelo de negócios em um maior nível de detalhes. Ela estrutura os elementos e fornece uma referência para o design detalhado e para o lançamento do PSS.
Lembre-se que estamos entre o nível conceitual representado pelo modelo de negócio e o nível de especificação para implementação do design detalhado. No design detalhado existem iniciativas de representação integrada por meio dos formalismos da engenharia de sistemas baseada em modelos (model-based systems engineering – MBSE).
A MBSE parte do pressuposto que existem modelos que podem representar todos os elementos de um sistema a ser desenvolvido. Modelo é uma representação da realidade (tanto atual como futura, quando estamos desenvolvendo). Apesar de iniciativas internacionais, não existe um formalismo aceito para representar todos os possíveis elementos de um sistema (não estamos falando de software aqui, mas de sistemas mais abrangentes de um negócio). Além disso, durante o desenvolvimento, temos diversos níveis de abstração desses elementos. Algumas iniciativas de se especificar meta-modelos de PSS vão na direção de se criar uma referência única integrada, mas ainda estão com um nível baixo de maturidade. As soluções que existem definem os significados dos elementos de um PSS e não pode ser usada para apoiar à servitização. Uma empresa em processo de servitização já deve ter seus próprios métodos de definição das arquiteturas de produtos e ICTs. Dessa forma, nessa versão do guia da metodologia de servitização daremos maior enfoque à arquitetura de processos e serviços Esse conjunto de atividades ainda está em desenvolvimento.
Descrição resumida da arquitetura do PSS
No desenvolvimento de produtos, a arquitetura é vista como o esquemático da solução que relaciona funções e componentes físicos. Porém, um PSS é um sistema, como o próprio nome diz, e deve ser visto como tal. Ele possui mais artefatos do que simplesmente serviços e produtos. A arquitetura de um PSS é composta pela combinação das arquiteturas de seus artefatos (tangíveis e intangíveis) e envolve todo o relacionamento e interfaceamento dos produtos, serviços e a infraestrutura necessária para oferecer a solução. Assim, consideramos neste guia que a arquitetura de um PSS é um esquemático para mapear as funções e elementos do PSS, assim como a relação entre eles. Esses elementos podem ser partes dos produtos, recursos, partes da infraestrutura, atividades ou subprocessos de processos e serviços. As funções também não são necessariamente atreladas ao produto, podendo ser funções relacionadas aos serviços, processos, e recursos da infraestrutura.
Perceba que é muito importante ter essa perspectiva completa da arquitetura do PSS, pois ela estabelecerá como cada artefato se relaciona. No entanto, essa perspectiva deve demonstrar de forma clara os limites de cada artefato também. Lembre-se que, posteriormente à arquitetura, será o momento do detalhamento dos artefatos. Assim, um grupo de engenharia desenvolverá o carro com base na arquitetura do carro. Seus engenheiros não precisam saber os detalhes do processo de cobrança. Eles apenas precisam saber que aquele produto possui relacionamentos com outros artefatos e quais são os requisitos desses relacionamentos. Da mesma forma, os desenvolvedores que implementarão o aplicativo precisam apenas saber a arquitetura do aplicativo e as interfaces do aplicativo com outros artefatos, assim como seus requisitos. Por isso, temos um paradoxo: a arquitetura deve ser única e divisível.
Vamos tentar explicar melhor essa ideia com um exemplo. Considere um caso de carros compartilhados. O carro é disponibilizado pela empresa para seus clientes. Se o cliente desejar utilizar o carro, ele libera o uso do carro por meio de um aplicativo. Assim, se o cliente usa o carro por uma hora, a empresa cobra em seu cartão de crédito um valor equivalente a uma hora de uso. A empresa também é responsável por realizar manutenção em seus veículos a cada 10.000 km rodados e emprega sensores que enviam dados diretamente para um banco de dados online sobre a quantidade de quilômetros rodados para cada carro.
Podemos visualizar que o produto carro tem uma arquitetura. O aplicativo também tem sua arquitetura. Os processos da empresa também têm uma arquitetura que preveem a cobrança do uso do carro, a manutenção dos carros, assim como todos os outros processos necessários para oferecer a solução. Porém, nós sabemos que o que disparará o processo de manutenção é o fato de o carro ter rodado mais 10.000 km, o que é lido por meio de um sensor que se encontra no carro. Ou seja, um elemento da arquitetura do produto carro possui interface com o processo manutenção. São duas arquiteturas se relacionando. A tecnologia de informação e comunicação (ICT) aplicativo também se relaciona com o processo cobrança, informando o número de horas que um determinado usuário utilizou o carro.
A divisibilidade da arquitetura é o divisor de águas no desenvolvimento de um PSS. Seu time deve tratar o projeto de forma unicamente integrada até este ponto. A partir desse momento, cada artefato será desenvolvido de forma separada. No entanto, reforçamos que é essencial que um engenheiro de sistemas participe ativamente da criação da arquitetura e do estabelecimento dos requisitos técnicos da arquitetura. Esse engenheiro deverá acompanhar o restante da servitização, i.e., o detalhamento dos artefatos, verificando o atendimento dos requisitos para garantir a integração da solução.
A arquitetura de um PSS pode ser subdividida nos seguintes tipos de arquitetura:
A arquitetura de produto é definida como a representação das funções do produto organizadas em seus elementos físicos e nas interações entre eles.
A arquitetura da infraestrutura é composta da arquitetura de ICT e dos recursos.
A arquitetura de tecnologia de informação e comunicação (ICT) representa as soluções computacionais que apoiam os serviços da arquitetura de processos e podem requerer conexões com os elementos da arquitetura dos produtos.
Arquitetura dos recursos representa a estrutura dos recursos de infraestrutura (que não sejam de ICT) e suas relações, que apoiam o modelo de negócio. Ou seja, que desenvolvem funções que entregam valor para os stakeholders.
A arquitetura de processos e serviços pode ser traduzida pela arquitetura de processos de negócio, devido principalmente à natureza intangível dos serviços que permite que eles sejam representados por uma sequência de passos. Com isso, temos a arquitetura de processos de negócio e serviços como a representação de um modelo hierárquico que mostra como uma empresa entrega seus serviços, da perspectiva de processos, processos em um nível tático.
As naturezas dos elementos de um PSS são diversas, assim como as formas de representá-los. São várias perspectivas possíveis. Essa é a dificuldade maior em se criar uma representação única que consiga mapear todos os elementos. Assim, no estágio atual de desenvolvimento da metodologia vamos apresentar algumas escolhas de formalismos para representação de cada uma das arquiteturas e elementos que apresentam sua integração. Existirão, portanto, redundâncias. A arquitetura integrada de um PSS é ainda objeto de pesquisa, mas atualmente é possível trabalhar com as arquiteturas separadas e pontos de intersecção, no qual elementos de uma arquitetura são mapeados em outras arquiteturas relacionado com os elementos dessa outra arquitetura.
Quem deve realizar essas atividades?
É importante que membros que participaram das etapas anteriores se mantenham no time neste momento ou, pelo menos, transmitam as informações para os novos membros.
Como a arquitetura é a base para o detalhamento e representa a interface entre todos os artefatos da solução, é essencial a presença de um engenheiro de sistemas ou alguém que tenha experiência em gestão de requisitos e integração de sistemas. A criação de uma boa arquitetura dependerá do conhecimento desse indivíduo.
Também é muito importante que o gerente de projetos esteja alinhado com os resultados da arquitetura, dado que a divisão dos artefatos na arquitetura influenciará o planejamento do detalhamento da solução.
Se a organização já possui uma gestão por processos, o responsável pela gestão deverá participar do time em conjunto com o gerente de projetos. O gerente de projetos tem a visão da situação futura, enquanto o gestor de processos conhece os processos atuais.
O time deve ser composto por membros das áreas funcionais, em especial as mais afetadas, como desenvolvimento, vendas e entrega de serviços. Além disso, a equipe de engenharia tem papel fundamental na construção da arquitetura de produtos e ICTs e deve estar em completa integração com as equipes responsáveis pela provisão dos serviços. Por isso, o papel do engenheiro de sistemas é tão importante: ele deve garantir que as áreas conversem entre si de forma que a solução final seja realmente uma solução completa e integrada.
Conhecimento básicos para realizar essas atividades
Existe um capítulo introdutório sobre arquitetura de produto na referência (2).
Fontes adicionais de consulta
OLIVEIRA, Cristiano Bevitori Maffia de. Estruturação, identificação e classificação de produtos em ambientes integrados de manufatura. 1999. Dissertação de Mestrado. Universidade de São Paulo.
Visão geral das entregas das arquiteturas integradas
Atividades e Entregas
Primeiro, as atividades necessárias à construção dos três tipos de arquitetura que compõem a arquitetura do PSS serão apresentadas.
Elas são referentes às iterações características da metodologia. Lembre-se que a arquitetura do PSS precisa estar alinhada com as estratégias de servitização e com as decisões já tomadas.