Que considerações devem ser feitas a favor e contra os sites "super"?

Minha empresa está considerando consolidar todos os aplicativos e sites de nível 1 (ou seja, produção de ponta) em um único conjunto de códigos.

A teoria é que suas permissões, design e funcionalidade geral podem ser homogeneizadas e gerenciadas centralmente.

Não tenho preocupações com essa abordagem, pois as estruturas de dados subjacentes a cada aplicativo são muito diferentes, as regras de negócios são complexas e exclusivas para cada aplicativo e as bases gerais de código para os aplicativos existentes são extremamente díspares e muito negligenciadas.

EDIT :

O ambiente atual consiste em três sites ASP.Net 1.1 que mal viram amor desde a primeira criação (devido principalmente à ausência de desenvolvedores experientes na empresa) e um aplicativo MVC2 que também era um site ASP.Net 1.1 antes de ser gravado. atualizado no ano passado. Nós escrevemos exclusivamente em C #.

A empresa é bastante pequena, com cerca de 50 funcionários; três dos quais são desenvolvedores reais. O gerenciamento (mesmo o gerenciamento de TI) não possui experiência ou experiência em TI além do gerenciamento de projetos de projetos de TI (e, portanto, algum conhecimento prévio sobre terminologia e impactos nos negócios).

As aplicações são principalmente serviços online para dar suporte aos produtos vendidos pela empresa. A empresa não vende nenhum software diretamente.

Então, para expressar toda essa situação em uma pergunta razoavelmente específica e respondível: Quais são algumas das razões convincentes a favor e contra a tentativa de reunir todos os seus sistemas em uma solução abrangente, dadas as condições atuais (ou seja, base de códigos antiga, sistemas e regras de negócios complexos )?

Péssima ideia

Essa reação é baseada nas seguintes suposições:

1. Existem muitas aplicações bastante díspares sendo homogeneizadas
2. Existem muitas equipes trabalhando nas diferentes aplicações
3. Não há arquiteto de software respeitado e autoritário que gerencia ativamente os aplicativos

O que acontecerá se você continuar

Provavelmente, haverá um esforço inicial consolidado para reunir tudo sob uma única abordagem de design. Isso mostrará o enorme esforço necessário para que tudo funcione da mesma forma e pode ser considerado impraticável.

Se for pressionado, será necessário algum tipo de repositório centralizado contendo dados de configuração (por exemplo, acesso de segurança, níveis de log etc.), quando alguém indicará o óbvio e dirá

"Ei, por que não adaptamos essa abordagem de configuração externalizada aos aplicativos antigos, será muito mais rápido?"

e, um momento depois, alguém mais vai aparecer

"E, como estamos refatorando de qualquer maneira, por que não aplicamos um padrão de design para cada um dos domínios de aplicativos - o processamento da Web se parece com isso, o processamento da regra de negócios assim e o acesso ao banco de dados como isso?"

Até que finalmente

"Ah, e há muito código comum aqui por que não reunir algumas bibliotecas facilmente compartilhadas. Provavelmente precisaremos de algum tipo de integração que seja executada em intervalos regulares, digamos, todas as noites."

Nesse ponto, todo mundo respira aliviado por não ter sido construído um enorme monólito.

Temos trabalhado nisso na minha empresa. Eu acho que é possível e há benefícios óbvios (você os mencionou), no entanto, esse provavelmente será um projeto de 5 a 7 anos no mínimo absoluto e requer basicamente que tudo seja reescrito. Se você conseguir assinar algo assim, então eu diria que vá em frente. Caso contrário, prepare-se para uma marcha da morte de pesadelo.

O Google faz isso, então certamente é possível .

Esse link BTW é uma apresentação interessante de um Googler sobre como ele gerencia sua base de código, integração contínua, teste etc.

Sem um compromisso igualmente forte com as ferramentas, no entanto, como o Google fez, é provável que você tenha um mundo de mágoa.

A questão-chave aqui é por quê ? Por que a gerência sênior quer fazer isso? Que economia, alavancagem ou outra vantagem eles esperam obter?

Se você conseguir resolver um número suficiente desses problemas, a fim de alcançar seus objetivos, evite a base de código única que lhe interessa, enquanto ainda lhes proporciona o mesmo resultado efetivo.

Estamos passando por um processo semelhante. Tínhamos um produto que já existe há algum tempo. No ano passado, lançamos outro produto 95% igual ao primeiro, com 5% de diferenças às vezes sutis, mas significativas, com essas diferenças a serem desenvolvidas e mantidas por uma equipe separada.

Quando começamos a trabalhar no novo produto, a equipe antiga continuava fazendo alterações que nos impactavam negativamente nesses 5%, porque não entendiam o novo produto. Então, pegamos completamente 5% do código, o que nos permitiu terminar o primeiro lançamento no prazo.

Mais trabalhos de manutenção começaram e descobrimos que estávamos freqüentemente fazendo alterações quase idênticas no código quase idêntico. A equipe antiga também tem uma compreensão muito melhor do novo produto agora, por isso estamos gradualmente reintegrando o que forqueamos e encontrando maneiras arquitetônicas mais eficientes de expressar as diferenças.

Então, quando você diz que as estruturas de dados são diferentes e as bases gerais de código são díspares, a pergunta que eu faria é se elas têm que ser assim ou é assim que elas evoluíram devido à conveniência do momento. Obviamente, você deve considerar as diferentes regras e requisitos de negócios, mas a chave é isolar essas diferenças no menor módulo possível. Se você costuma implementar o mesmo recurso para vários clientes de maneiras ligeiramente diferentes para diferentes bases de código, a consolidação pode realmente ajudar, e eu suspeito que esse seja o caso ou o gerenciamento provavelmente não estaria propondo isso.

Provavelmente, você não conseguirá consolidar vários aplicativos na mesma base de código , porque isso exigirá bastante esforço e, para programas antigos e negligenciados, isso pode ser muito mais trabalhoso do que o inicialmente esperado.

Dito isto, não há nada errado em ter todos os seus aplicativos no mesmo repositório de código , onde cada aplicativo possui uma área separada. Isso permite, por exemplo, gerar qualquer documentação on-line gerada para toda a base de código em uma única exibição consistente, o que geralmente é uma coisa boa, pois você deseja obter a maior visibilidade possível.

Aqueles que decidem isso devem considerar fortemente por que querem fazê-lo e quanto trabalho desejam gastar para chegar lá.

Se existe uma coisa que torna o desenvolvimento empresarial tão ineficiente e caro, é a ilusão de que é possível criar um sistema único que faça tudo. Se você tivesse um único proprietário do produto que entenda todos os detalhes do sistema e possa tomar todas as decisões sem precisar de uma semana de reuniões, pode funcionar, mas nunca vi isso acontecer.

Em geral, você estará melhor se o tratar como se estivesse desenvolvendo para a Internet - basta criar seu próprio aplicativo, admitindo que, na prática, você tem controle zero de qualquer coisa fora do seu próprio código. Você pode obter praticamente toda a consistência que deseja com o OAuth e uma API simples para configurações do usuário e um pouco de CSS compartilhado.

Isso é bastante semelhante à intenção original da SOA, mas se você chamar isso, você acabará com um tipo diferente de sistema grande e pouco funcional que tenta fazer tudo.

Meu primeiro pensamento é que este seria um total de PITA para lançamentos.

Dividir em partes gerenciáveis ​​de funcionalidade é muito mais sensato, apenas para evitar todas as camadas de gerenciamento e aprovação.

Dividir coisas comuns em componentes / serviços e padronizar dessa maneira seria muito mais fácil IMHO.

Você pode abordar isso de maneira diferente, usando uma tecnologia de integração, como o Deliverance, para colocar temas em todos os aplicativos da Web da mesma forma. Basicamente, cada aplicativo ainda está separado; O Deliverance usa regras XSLT para converter sua saída em um modelo HTML estático projetado por você. Isso permite que um tema HTML / CSS estático relativamente simples seja aplicado a um conjunto inteiro de aplicativos com um mínimo de desgraça.