You are tasked with managing the initial phase of development of an application platform which will support mission critical enterprise applications. The platform will implement standard functionality for data access, access control, presentation, etc across all applications that leverage it. In short, the application platform will provide a native api for managing the data access and presentation layers of each supported application.

Applications will be developed directly for this platform, based on the requirements we set. We do not have any initial requirement to support legacy systems, even though many exist (legacy systems are built on any number of fragmented technologies -- they will be ported to our platform once complete). Our initial target for presentation is the web.

We are experienced developing and managing projects in Java, .Net, Python, and C++. The in-house development staff for this project is yet to be selected, so we have flexibility in regards to what our development team will look like in terms of knowledge capital. We also have a green light to employ any new hardware/infrastructure we need to complete the project.

Okay, so that's the hypothetical scenario; We need to build a platform that supports the development of critical enterprise applications. We have no legacy code to support, no brainwashed dev team to work around, and no hardware that we are required to use. What details impact your decision of the technology stack that you employ to complete this project?

Stack's OP is currently contemplating:
Python >
Hardware = unix
programming language = python & c++
db = postgres
mvc = Werkzeug + Jinja2 + sqlalchemy.
Positives: Meta programming (impacting simplicity for supporting applications). Very loosely coupled and relies on only open source technology. Development time expected to be most rapid.
Negatives: No private objects (impacting some decisions in API development). Developers (acceptance of python as core language?)

.Net >
Hardware = windoze
programming languages = c#, f#, ironpython, vb.net
db = sqlserver
mvc = asp.net mvc 4 + ndjango + entity framework.
Positives: Public/Private objects. Consolidated stack. 'Enterprise' solutions (whatever the eff that means, but it counts to some people). Support for multiple languages. Possibly greater developer acceptance???
Negatives: Infrastructure is more expensive. Development time expected to be greater. Tightly coupled stack limiting flexibility.

OP's note: I understand that these requirements do not limit the technology used to achieve them. I also understand that we should use tools that we are comfortable with, and focus on what we know, blah blah blah. This is not meant to be a holy war over whether a certain python stack is cooler than .net or whatever. Simply would like input on what makes an impact on others when planning out infrastructure, and what would shape their decision on this specific project.

Cliffs: I wrote a bunch of pretty words to ask the following: If you were tasked with developing an application framework that supports mission critical applications, what would impact the technology stack you chose. What stack would you choose, and why?

This is kind of a weird question, as I do not think you are drilling down deep enough on the infrastructure part. If I were desiging a system:

Hardware- Openstack (this is a huge discussion right here in regards to hardware, storage, proxy requirements)

Configuration managment- Chef

programming language - it doesnt metter to me, whatever the developers like, but I would go with rails/ruby.

DB- postgres

with chef, you can deploy any stack of virtual machine instantly (staging, production, dev), so the stack the apps are built on is of less importance, and doesn't need to be homogenous.

Out of the above choices I'd probably go with GWT with Java.

Being able to write both your server and client code in 1 language (GWT will cross compile javascript for you based off the Java you write) is going to save a lot of development time and make your code way easier to deal with.

I won't even look at a tech now unless it has something that can be used on both the server and browser. That pretty much leaves Node.js or GWT w/ Java. Your team doesn't seem to have good JS experience so that eliminates node.

Wow, I never would have guessed you would support something like GWT.

I think you're vastly overstating the productivity gains of using the same language on server and browser. Any decent developer is going to be able to handle two languages with minimal problems and you can a lot better than Node.JS/Java for the server.

This is a vague set of requirements. "Mission critical applications" don't mean anything. Presumably, any application anyone earns money from is "mission critical" from the perspective of that revenue stream. Facebook may not be "mission-critical" for me but I bet Facebook loses far more money from Facebook.com being down than most companies do from their "mission critical applications" being down. Anyway, here are some questions you can ask yourself:

1) What's your team like? What's your potential team like? What kinds of developers do you tend to recruit? Is your team capable of supporting the underlying technologies should the need arise (or are you capable of assembling such a team) or are they strictly application programmers?

2) Who is going to judge your technology choices? Who do you have to justify them to?

3) How much time do you have? What much money do you have? How complex are the required features? In terms of requirements, how do cost/feature/correctness/time stack up?

4) How is the application likely to evolve? What's the likely lifespan of the application?

5) What other systems and technologies do you have to interoperate with in the future?

6) How many people are going to be using the application? How many people are going to be involved the development?

I don't use Java for anything but I do try to keep up with techs from all languages. I wouldn't discount anything without a good reason not to use it. I also took his team's experience into account.

It's also not about being able to handle more than 1 language because it's too hard. It's being able to write a bunch of stuff once and share it. Imagine writing a game where you have the state of the game running on both the client and server.

If you don't use the same language you basically have to implement the game once in each language. That is a massive burden to undertake.

It's less painful for more standard web application (not games) but it really does have its uses for both productivity and overall happiness. What's your definition of "a lot better than node/java" for a server?

This example isn't what we were talking about and in no way proves your general point.

In a standard browser/server application the logic you're writing for the browser is different than what you're writing on the server. Most people aren't writing the same thing twice even though they're using JS/Flash/Whatever for the browser and Java/PHP/Python/Ruby/Whatever for the server.

Whatever floats your boat. Pick the features you personally care about (testing, easy deployment, hosted options, fast prototyping, IDE support, whatever) and you're often going to be able to pick something better than node/java. I'm going to stay out of a specific language/platform/framework war though.

This is obviously true, to be more clear the proper term would be financially significant applications, that would be in scope to SOX and SOC reporting compliance.

Potential team will be small group with a mix of experience. Potential team is 1 PM, 2 senior devs, 1 sysadm, 1 dba, 3-5 intern/junior devs. In addition, we will have a support network for potential issues.

We will need to please 2 generic parties; end-users, and developers. Platform end-users will be LOB IT management and business users. These will be the people who decide the general direction of the platform and the funding. Our developers (3rd party) will be the people building the applications directly on the platform. They will likely be the most important, because we need them to build and deploy quality software to succeed.

We have somewhere between 12 and 18 months to get into a beta. I have exactly as much money as the budget to pay the above alloted potential team for 12 and 18 months. Features aren't groundbreaking, a lot of real estate to cover, but most complex requirements have proof of concept prepared. I don't know that I've ever thought in terms of 'cost/feature/correctness/time'. I think as an answer we have more than enough time/cost to complete the featureset, but the correctness is the piece of most importance. This is something that could probably be built in 6-12 months with said team, but execution must be flawless for this to be of value to management.

The application is likely to evolve in terms of featureset, and retain a very focused scope. The lifespan of the application can only be determined once developed. At the outset management would like to see this as a long term solution, so say 10+ years.

This is one arena in which we may see some increased scope. Currently no support for legacy systems is required, and that isn't 'expected' to change. I believe it will, and will require support for LOB manufacturing infrastructure and likely some mainframe support (legacy apps that likely never move). We would have a lot of input on modifying the legacy infrastructure, but are likely to have to address this if we are successful.

The framework would see traffic from around 20,000 unique business users, who would be accessing some array of the application supported. Initial traffic would be much smaller (500-1000 unique users) and focused on 1-2 applications.

How many people are involved in the devlopment will be greatly influenced by the success of its development. If current operations on other home brewed applications is translated based on risk, I'd say this project would be supported by a staff of 20-40 if in pruduction.

Which language is better than JS when it comes to:

- testing
- fast prototyping
- ide support

I haven't came across anything better than mocha/jasmine and testacular in any language for testing. IDE/Editor support along with debugger support (thanks to Chrome) is ridiculously good too.

You can also get pretty good code analysis with linters and general tooling (doc generators, etc.) are quite good.

My experienced is skewed because of the type of work I do. That said, I have been around several large framework projects of this type that were in the process of failing.

For example, one was at a large logistics software provider. the framework was j2ee / hibernate. on top of the usual config xml associated with hibernate circa 2002, the team had built their framework to require another level of xml based config that was just horrible. The framework project was about 2.5 years in, and the LOB application teams were a year in or less. Nothing was in production yet.

The developer teams responsible for building on top of this were largely offshore, and all the projects were in yellow or red status by the time i got involved. The framework was bloated, complex, and incomplete. combine that with a big communications gap, slow iteration on getting needed features, bad project controls that allowed for massive billing with no real consequences and indeed if anything resulting in more headcount being added, etc.

On the other hand, I have seen a successful project of this nature also. The major differences as I see them:

- failed project just added a layer of abstraction over generic ORM, plus a bunch of required bloat to map down to horrible generic tables. good one provided a concrete and well designed model layer for the type of data floating around in the enterprise already. Less flexible, but infinitely clearer, objectively helpful to application developers, etc. Gaps were handled mainly by having the core team add to the model layer.

- failed project rolled their own ui system that basically involved helper classes for building up html in servlets, which is a terrible workflow because every change goes through a developer who is looking at a mishmash of java code, not a template or something.

- successful project had the core team managing all of the hosting and ops for the backend, including integrations to legacy systems, etc. They exposed useful APIs, and left the app builders pretty much wide open from there. There was a project template with data layer classes designed to talk to the main backend apis, some example views, and a bunch of helpful utilities, but the app developers were also free to do other things if it made sense.

If I were building this, I would see if that approach would work for your situation. Briefly:
- survey the first set of applications in the pipeline. Figure out a sane data model that covers most of what they will need, at least the sensitive stuff.

Build a backend that exposes good APIs over that. go beyond CRUD, make them as smart as possible, with the traceability, validation, workflow, etc that you want to enforce managed in the platform.

Build a reference application template. pick the most productive framework that your team will embrace. I would pick rails or django personally, but only if that was a fit for the app teams.

Include:
1. a nice model layer that handles talking to your core system
2. base classes that can be extended (e.g. a base controller that logs requests and handles authentication)
3. Maybe set up bootstrap + corporate customization or whatever, if you want consistent look and feel.
4. Provide some basic HTML view template examples (forms, list views, etc)
5. If you need it, maybe an angular.js example backed with rest api, or whatever equivalent you like
6. Examples of how to direct upload files to your central store, embed a payment form served by the framework, etc. whatever specific stuff you have like that
7. utility helpers for whatever else you want to enforce, e.g. tracking javascript to include in pages, etc.

The idea would be to have the core team work pretty closely with the app teams, help with design and code reviews, and keep all the smart stuff in the backend.

For the backend, there might be advantages to the JVM if you need to plug in jboss rules, bpm, solr, etc. I would evaluate that first, and maybe try to do most of the backend in jruby, with a rails template for app developers, so as to have the rails productivity boost for application developers, be able to use jvm stuff on the backend, and have a common language with the backend team to facilitate code reviews, etc.

I love python but I don't really trust jython as much as jruby. A python stack would be good though if you don't care about jvm stuff. I recently had a project where we rewrote a dotnet backoffice system into django that worked out well. The existing team transitioned from C# pretty easily and reported productivity improvements. They really didn't know C#/asp.net mvc that well in the first place, so if you have real experts around it might be a different story.

I know i'm probably way off on understanding your situation but wanted to give some encouragement on considering ruby or python.

So you're building an inhouse ERP? Sorry but from your OP I don't quite get what you're actually trying to do

Are you building software for your company or for customers?

Either way I think "no legacy" in an ERP environment is a tad naive. How will you get data into the system? You'll have to interact with other systems...most common case: security related stuff/identity management (oh the dreaded active directory it's everywhere)

---
From your second post it seems like the chances of failure are really, really high. You should treat the entire project like a startup and not a plan ahead 1.5 years kind of deal. If you're in the financial compliance field I really don't get the "no legacy" disclaimer you started with. Who uses this stuff that doesn't want it working with their ERP/accounting?
So I'd basically pick a team that is as entrepreneurial as possible and highly cross functional and not the one you proposed that seems rather specialized.

If you guys nerd out on this stuff like I do, you will really enjoy The Pheonix Project:

http://www.amazon.com/gp/product/098...=reddit09ee-20

I randomly bought it on my kindle as it was a recommended read and I couldn't put it down until I finished.

Thanks for sharing your experiences. One question, in your successful implementations (with this type of scope), did you feel that your initial technology decisions had a large impact on the end project? My thoughts are this can be achieved in pretty much any stack, and no matter what we choose there are going to be sacrifices we need to make.

Some background originally omitted. I am a consultant at a big 4 accounting firm. My firm has been engaged to lead a client team to develop a custom platform. Our client is a multi national publicly traded company. Said company has gone through 2 failed 'full ERP' implementations and is currently leveraging 3 ERPs for different module needs (SAP, PeopleSoft and Hyperion). In addition they have built and support 300+ in house applications.

This project is not to build an ERP and get it into production as quickly as possible. It is not to build an ERP that supports their current software or hardware. The project is take a clean slate and build a platform that can support the clients technology needs in a unified manner. These needs include supporting ERP modules and LOB applications (a mix of applications, some interact with ERP data others do not). The applications will be built, or ported, for this platform.

We are not concerned with legacy code or data currently, because we CANNOT go into production any time prior to approximately 1/1/2015. If we are successful in building a platform that can support the needs of the entity, and we can successfully port and integrate some selected applications, then the company MAY decide to implement this solution. If it goes into production, the company would implement parallel infrastructures and begin migrating data/applications. I will never be involved in this, but I do understand that it should be a concern. In short, this is purely R&D for a company that has the both the people and economic capital to support it.

OP Restated: You have to build a platform that supports ERP modules and LOB business applications. You have no limitations in terms of experience, funding or time. The major focuses of the platform are shared access control, data, and interface. You need to deploy this solution to the web. If you were faced with this project, which technology stack would you select and why?

OP Restated in 1 Sentence: If you wanted to build a web based platform to support building and hosting ERP other applications with a shared interface, data model, and access control, what technology stack would you use?

I don't think the actual tech stack is as important as the difference between:

- hey developer, here's a normal stack in your technology with some prebuild models for you to use

and

- hey developer, here's a custom stack that means your existing knowledge is not very usable, please learn our custom ORM and custom presentation layer code before you can do even the simplest thing. PS, they are half baked and buggy

And further, giving them everything needed to spin up test and staging environments, etc - support their development process.

Since you might have to work with SAP eventually you should keep in mind that some of their stuff assumes the existence of at least one Windows machine (management console needed etc).

Also I think they only support MS-SQL and Oracle (+their own DB) so Postgres integration could turn out tricky as well (I have no experience with this and it could actually be trivial).

Since you will probably be doing a lot of compliance stuff I'd think about the access model quite a bit. You also want some technology stack that provides a solid workflow engine (unless you want to roll your own).
I know all this can be built with a Python based stack (Linux+MySQL/ZODB hybrid+Zope), we never did SOX but I assume it's conceptually the same as working on BASEL.
Compliance with government regulations can get messy quickly I'd probably build a "compliance DSL" which allows domain experts to encode their knowledge quickly.

Since it's banking/finance I think the safest bet would be some Java based stack though. I do not like Java but banking=Java these days :P

I know you can build from scratch but keep interop in mind from the getgo. It's a lot easier to get the green light if you can import data relatively easy...my guess is that access control stuff is currently spread across the existing systems+AD. I think reading up on "identity management" before the project kicks off is a good idea because that seems to be one of the key aspects.

I'm interested in this idea of a compliance DSL. Can you give a little more detail on how that might work? (I know python pretty well, so specifics are welcome)

Wat? You do realize that mocha/jasmine are just ports of RSpec and mocha from Ruby, right? (And RSpec is a port of JBehave from Java, more or less)

In browser debugging is decent, but it's really the only option with JS so in comparison to using window.alert()s and console.log()s all over your code it's ****ing fantastic. Most other languages have great REPLs and bindings you can use.

I'm just going to say this now: People in the JS world that tout their debugging/testing tools are only comparing what they have now to what the JS world had in the past. Just about every other programming language is well ahead of JS in dev tooling.

This this this this this this this thsi thsi thiststhsit thsithisthsi thsi thisthis this.

Well said. Of course I didn't respond to his post since I figured it was just a trolling attempt.

Irrelevant, because it exists. There's node inspector too which lets you use Chrome to debug your server side JS too. Not only do you get to write JS on both ends, you get to use the same debugger too.

Anyways I'm not getting into this. I personally don't care what the OP decides to use. I just gave advice based on his team's skill set.