Technology Stack at The Enterprise Level

The choice of technology stack at the enterprise level, especially when extending or expanding the offerings has lots of considerations:
* What does my tech ops know how to install, deploy, support? Introducing new technology is expensive.

* What does my existing staff know? Introducing new technology is expensive.

* What technology stack can I get indemnified libraries for? Introducing new technology is risky?

* What is the existing technology stack I need to interface with? Cross architecture connectivity can be expensive and suffer performance issues.

* What technology stack is used for the supported open-source solutions I might be interested in deploying? Bleeding edge can be expensive.

* What technology stack is used for the proprietary solutions I might be interested in deploying? Asking/paying for porting to my preferred stack is expensive.

* What does everyone else use? It’s politically safer to be a technology follower, especially with the high rate of software project failure.

* What makes programmers most efficient and effective? They are a major cost factor.

There are other considerations
* Technical fit – not likely to do browser plug-ins in COBOL.

* Maturity of the stack – what’s proven, secure, performing,

* The “–abilities”, support, scale, secure, maintain, development, port, upgrade, use, interopera, etc.?

* What does the CTO believe?

* What does the “though leaders” in the development organization believe?

* What does the company you are about to acquire use?

* What does the company about to acquire you use?

* What does your parent (or child) company use?

I’m sure I’m forgetting some, and clearly these all don’t carry the same weight. And, depending on the scope of the project, there’s different weights as well.

You get the picture. The choice is seldom based simply on the technical purity of the programming language. While that’s fun to debate, from a purely academic point of view, the real world is much messier.

Why Enterprises uses java? because enterprise apps are not about UI widgets only. Enterprise apps are running on multiple devices, supporting millions of concurrent users, with 99.99% of uptime.

So to achieve this its not about choosing the language only but the whole solution. Which includes Security, Persistence api, Transaction management, Clustering, Messaging, Webservices, ESB, Connectors for heterogeneous applications, Web support etc. You can see the reason why enterprise uses Java as its major programing language as JEE answers for most of these issues. Other than that there are many opensource solutions available and there is a big community behind it.

Enterprises are also using Javascript as a key component for their front end development regardless of what backend used. Specially for AJAX and SPA.

And if by Javascript you meant node.js, than we probably talking about the microservices and may be MEAN stack. which is a different application architecture. In that case you have opportunity to write Javascript both on server and client side, but even in that case there are still some Java components being used for integration.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s