¿Qué tan prudente es que una compañía SAAS basada en Linux / Oracle adquiera una compañía SAAS basada en MSFT / SQLServer e intente integrarlos estrechamente?

La pregunta es ¿por qué preguntas? Si es porque está considerando la pregunta como CEO, entonces nuestras respuestas no son significativas, ya que ha evaluado la opción de acuerdo con su propio sentido comercial y ha tomado una decisión. Si es porque su CEO acaba de adquirir la empresa y desea evaluar su elección (yo diría “la suya”, pero hoy en día tengo un 5% de posibilidades de estar equivocado), nuestras opiniones vuelven a carecer de sentido, ya que la decisión ha tenido e independientemente de nuestras opiniones, como empleados, seguimos la dirección de nuestro líder y “Hazlo así”.
La pregunta en sí deja de lado el hecho de que las adquisiciones rara vez se refieren a la tecnología y menos aún a la compatibilidad, ya que la fuerza impulsora está adquiriendo participación de mercado y reduciendo la competencia. Hay una adquisición de un proveedor “vertical” en la cadena de suministro que ocurre ocasionalmente, pero rara vez alguien preguntaría sobre la compatibilidad de los sistemas, ya que generalmente la integración entre los sistemas de suministro ya existe y el objetivo es reducir el costo de los suministros o aumentar fiabilidad o exclusividad del material. A veces, una gran empresa, como Microsoft o Facebook, puede adquirir el desarrollador de un producto de software que se ejecuta en sus plataformas, pero la compatibilidad de los sistemas rara vez se tiene en cuenta, ya que esa empresa opera como una entidad separada y los sistemas ERP pueden descartarse fácilmente a favor de las compañías más grandes o los datos exportados a los sistemas de las compañías más grandes.

Independientemente de la plataforma, cualquier tipo de fusión requiere rediseñar dos productos diferentes para que trabajen entre sí de manera integrada. En mi experiencia, el esfuerzo asociado con él no es diferente si dos plataformas son iguales o diferentes. La ventaja de tener dos compañías en la misma plataforma está en el conjunto de personas y habilidades. Cuando migra una línea de productos de una plataforma a otra, ha reducido su conjunto de habilidades disponibles a la mitad para el producto combinado (lo estoy haciendo demasiado simplista, pero entiende el punto). Mi consejo, deje de preocuparse por la plataforma, concéntrese en el valor comercial y los aspectos de la fusión de las personas. La tecnología se cuidará sola. Haga que sus arquitectos y su equipo de producto dibujen una estrategia de transición de producto muy sistemática (durante un período de tiempo) y asegúrese de que RR.HH. sea parte de cualquiera de esas discusiones desde el principio para que no tenga problemas de talento, que es la más difícil.

Si con “estrictamente” quiere decir que desea brindar a sus usuarios finales una experiencia fluida al usar la aplicación, entonces no hay razón para que no pueda construir API en una aplicación y una capa de consumo sobre la otra para brindar aparición de una experiencia de aplicación única.

Si quiere decir algo más con “estrictamente” (como si quisiera combinar las bases de código), entonces ese podría ser un problema mayor.

Quería agregar a lo que Shrivatsan Rajagopalan, Robert Habibi ha mencionado en su publicación.

Si las 2 plataformas pueden integrarse dependerá de su arquitectura. Si ambos sistemas usan algún tipo de Arquitectura Orientada a Servicios (SOA), entonces sería fácil. Podrían complementarse entre sí, en cierto sentido, los servicios de Oracle \ Java pueden consumir servicios de Mircosoft y viceversa.

Puede mantener las dos marcas separadas y realizar ventas cruzadas o ventas adicionales entre una y otra.

Se trata más de lo que beneficia a sus clientes y genera ingresos, en lugar de una cuestión tecnológica.

¿Cuáles son sus razones para adquirir la otra compañía?

Es necesario si desea una nueva línea de productos, pero la venta de la integración cruzada tiene un mercado limitado, por lo general resuelve seleccionar cualquiera de las tecnologías. Las organizaciones gubernamentales y reguladas pueden estar interesadas en dicha habilidad, por lo general tienen problemas entre departamentos debido a plataformas tecnológicas heterogéneas.

Dejas que el usuario y los requisitos del mercado impulsen las decisiones tecnológicas. Como mencioné antes, a través de varios métodos, como una estrategia API sensible, puede ocultar las tecnologías / arquitecturas de múltiples proveedores para darle al mercado lo que necesita.

En última instancia, las personas constituyen una empresa.

Tener dos equipos tecnológicos y dos equipos de ingeniería aumentaría el costo operativo neto de administrar la empresa unificada.

A pesar de estos desafíos, si aún desea comprar la otra compañía SaaS, solo hay dos razones:

• Usos
• Datos

Siguiendo el camino de muchos otros aquí … esta es una mala idea si lo está comprando por tecnología o talento de ingeniería, ya que tendrá que tirar tanto lo que compra como las personas que lo acompañan, ya que no puede ofrecer una experiencia transparente y escalable para sus clientes.

Si desea comprar la compañía por otras razones (talento, clientes, know-how), el caso de negocios debe hacerse por esos motivos.

Un equipo sólido de DBA y Dev puede integrarse en el lado de la base de datos.

Si MSFT SaaS está realmente basado en Java o PHP, no hay problema. Pero no creo que lo llames MSFT en ese caso.

Suponiendo que no lo sea, ya sea un lado de la capa de aplicación u otro necesitará una reescritura para conciliar el comportamiento y las reglas comerciales.

Es mejor que tenga un sólido caso de negocios y mucho potencial para garantizar que los clientes actuales no se vean afectados por la integración.

Mucho más allá de mi grado de pago técnico