Make some suggestion for a technology stack

except that you will continue to be paying in order to make modifications or move off the tool set which you've invested in. This is a silly cost to incur if you can avoid it altogether and direct those costs towards skills training on a longer term solution.

He quite specifically said that he does not have a "current stack" - which I'd assume includes a code base. By all means advocate Sharepoint and Azure but the moment you are looking at developing across for mobile devices to act as data gathering devices you aren't in a territory where Microsoft solutions are making the most sense and thats before the other draw backs.

You know that Azure for South Africa is hosted in Dublin, Ireland, looking at the POPI perspective. In my opinion it will not be a viable deployment on this specific platform.
 
You know that Azure for South Africa is hosted in Dublin, Ireland, looking at the POPI perspective. In my opinion it will not be a viable deployment on this specific platform.

Well i would use Amazon over Azure anyways.
 
You know that Azure for South Africa is hosted in Dublin, Ireland, looking at the POPI perspective. In my opinion it will not be a viable deployment on this specific platform.
Indeed
Windows Server 2013 though isn't
but yes that is an additional draw back - I had actually discarded it on the simple basis that Microsoft are an interesting lot
 
Yes and you skipped his post where he said 90% of his code base is in C# or the .NET platform, or where he said licensing wont be a problem as its funded.

He quite specifically said that he does not have a "current stack" - which I'd assume includes a code base.

To clear this up. I have a huge C# code base developed over the years. All nicely organised into assemblies and I leverage that in all my projects. If I can leverage this is it would be great and it will save lots of time and money.

What I meant with 'not have a current stack' is that for this project I want to keep an open mind and see what options there are. I have not made a stack choice yet and want to choose the right stack for this type of system and not use my existing code base if it will not scale or be appropriate for whatever reason.

In terms of the application, it is a trading ecosytem for a niche industry. The whole supply chain is integrated. It is not a portal in the common sense, but it functions as a brokering system between all the parties, but also provides the end-user UIs for many of the functions. This type of integration is part of the system http://en.wikipedia.org/wiki/Single-window_system.
 
Last edited:
If you have a lot of C# to recycle a Microsoft solution looks somewhat better.

I would be quite weary of thinking about a Microsoft solution for a Single-window System because of various countries adoption of OSS policies and so on.

I strongly believe that you will want information to be collectable using mobile devices so if you look at the UN pamphlet diagram you need to be able to cover computer (laptop/desktop), mobile devices, server generation and paper inputs into the single window. In this sense I think scaling is a problem.

The computer and server side of things on a C# code base makes a really strong case notwithstanding my weariness in favour of OSS (even if only for political reasons) makes it possibly viable.
 
It sounds like you are deciding on technologies before you have a solid architecture. If the potential to grow is as vast as you think, the overall architecture is far more important.

If you continue without finalising the architecture as far as possible, you will run into problems later unless you get lucky.

The questions you need answered ASAP are around the non-functional requirements of the solution. These answers, combined with a small but sound set of principles, will guide your choice of technologies.
 
When I read

I have a huge C# code base developed over the years. All nicely organised into assemblies and I leverage that in all my projects.

I get scared.
 
because it is a sharp implement ....
*drumroll

there is a lot of unjustified criticism of C#
however I do think the OP needs to think quite hard about adopting a much broad scope for this project
 
Im curious why are you scared?

Because it sounds a lot like non business code that needs to be maintained. I have be developing at a very hi level for 12 years and have pretty much zero "libraries".
But, maybe that's how things are done in MS land? Or maybe it's just me, after all, if you said to me "here's my custom zip library I wrote for dealing with normal zip files", I would say "idiot" :D
I am happy to be convinced otherwise though

Edit: I lie, back in my Delphi days I did have a bunch of shared code that I used in different projects. Maybe I just have my java blinkers on :)
 
Last edited:
Because it sounds a lot like non business code that needs to be maintained. I have be developing at a very hi level for 12 years and have pretty much zero "libraries".
So you dont use any frameworks/libraries and develop everything from scratch each time? Or, heaven forbid, copy & paste code from one project to the next?

Yes it is non business code (non domain specific code) that I use in almost every project. E.g. application blocks for email notifcations and templates. Or MVVM framework for WinForms. Yes once in a while I tweak the code or add features.

But, maybe that's how things are done in MS land?
Yes and javascript land and java land etc etc etc

Or maybe it's just me, after all, if you said to me "here's my custom zip library I wrote for dealing with normal zip files", I would say "idiot" :D
Well that would be idiotic.

Edit: I lie, back in my Delphi days I did have a bunch of shared code that I used in different projects. Maybe I am just have my java blinkers on :)
Well do you or dont you use any java frameworks? If not, then I would say 'idiot'. Why reinvent it each time. I think not using libraries and thus not promoting code reuse is foolish and shortsighted. I own my software company so reusable code that can save me time and money allows me to sell that reusable module again and again. Someone that does not see the value of code reuse probably just works for a salary...

<d!cksw!ing>
My code libraries are frameworks on their own. I use it where needed. They are well designed, open and extensible. I have 30 years of experience under the belt and have a knack for identifiying and extracting patterns and putting generalised pattern implementations into place. Some of my code was bundled with a commercial product many years ago. I have also developed a few systems that were worlds firsts. So whatever... </d!cksw!ing> ;)
 
Last edited:
because it is a sharp implement ....
*drumroll

there is a lot of unjustified criticism of C#
however I do think the OP needs to think quite hard about adopting a much broad scope for this project

Yes it is a massive and ambitous project. And I still need to build a team for this. I do have 25 years' experience in the domain, so I at least I am not walking into a new project blind, not knowing where the devils lie. And there are many...
 
If you have a lot of C# to recycle a Microsoft solution looks somewhat better.

I would be quite weary of thinking about a Microsoft solution for a Single-window System because of various countries adoption of OSS policies and so on.

I strongly believe that you will want information to be collectable using mobile devices so if you look at the UN pamphlet diagram you need to be able to cover computer (laptop/desktop), mobile devices, server generation and paper inputs into the single window. In this sense I think scaling is a problem.

The computer and server side of things on a C# code base makes a really strong case notwithstanding my weariness in favour of OSS (even if only for political reasons) makes it possibly viable.

Very valid point re the political motivation for OSS. Up to know my customers have only really cared about the solution and not the technology , but working with governments is likely to put a different spin on it...
 
It sounds like you are deciding on technologies before you have a solid architecture. If the potential to grow is as vast as you think, the overall architecture is far more important.

If you continue without finalising the architecture as far as possible, you will run into problems later unless you get lucky.

The questions you need answered ASAP are around the non-functional requirements of the solution. These answers, combined with a small but sound set of principles, will guide your choice of technologies.

True, but at the moment I am playing devil's advocate with myself. Seeing what technologies have become mainstream, may, to an extent influence an architecture decision. I believe that one cannot come before the other. Technologies are enablers for certain architectures. Certain architecture decisions may fall flat without the supporting technologies.
 
based on the size of the project and my understanding of what you are trying to do

I would actually recommend going the following route:
The project is going to be multistage and there is a definite lifecycle to it so consider having 3 separate life cycles each starting at a separate phase.

Phase 1 - you've got a lot of C# / .NET stuff together and Sharepoint / MS Office always has its strengths so setup a Server 2013 based smaller system without mobile application support. The focus here being on a desktop application and a server backend to perform the Single Window System you are needing. Thereby starting your "Microsoft Cycle".

Phase 2 - Start up your Web Services side
The next step of the Microsoft Cycle is to start farming off you backend.

Phase 3 - Mobile Devices Cycle starts up
At this juncture you can retire your Microsoft stuff or (which I suspect you will) find that having some Sharepoint stuff up and running really useful for internal stuff. At this juncture you essentially should be able to separate your development of device and browser front ends from the backend that then communicates on with the different departments.

-- the phases I am proposing will come in rapid succession and might be a big bunch to bite off but it should allow you to be accomplishing both the RAD that you need (the Microsoft Cycle) while getting your SaaS teams in play and sourcing in the right staff.
 
based on the size of the project and my understanding of what you are trying to do

I would actually recommend going the following route:
The project is going to be multistage and there is a definite lifecycle to it so consider having 3 separate life cycles each starting at a separate phase.

Phase 1 - you've got a lot of C# / .NET stuff together and Sharepoint / MS Office always has its strengths so setup a Server 2013 based smaller system without mobile application support. The focus here being on a desktop application and a server backend to perform the Single Window System you are needing. Thereby starting your "Microsoft Cycle".

Phase 2 - Start up your Web Services side
The next step of the Microsoft Cycle is to start farming off you backend.

Phase 3 - Mobile Devices Cycle starts up
At this juncture you can retire your Microsoft stuff or (which I suspect you will) find that having some Sharepoint stuff up and running really useful for internal stuff. At this juncture you essentially should be able to separate your development of device and browser front ends from the backend that then communicates on with the different departments.

-- the phases I am proposing will come in rapid succession and might be a big bunch to bite off but it should allow you to be accomplishing both the RAD that you need (the Microsoft Cycle) while getting your SaaS teams in play and sourcing in the right staff.

Yes this is a good approach for the dev portion. My first step is the BA part and documenting all the process flows and use cases. The fact is that the business users will have to sign off on specs and they find process flows and use cases easy to understand as the diagrams are eas to interpret. I have written a small 'How to read Uses Case Diagrams' doccie that I give to total noob customers. Use case diagrams are fantastic and allows you to thrash out requirements from the very top down to the very bottom as low as you want to go. Use cases also indentifies all the actors and to a large extent, documents a lot of the essence of the interfaces and interactions between actors. Once the interfaces are nailed, one can start development and through a series of actor implementation substitutions (fully funcitonal mocks) like you describe above (at least that is how I interpret it) converge on the full solution. I have used this approach before and it works well. But it relies on the interfaces/interactions to be fairly solid and well scripted.
 
So you dont use any frameworks/libraries and develop everything from scratch each time? Or, heaven forbid, copy & paste code from one project to the next?

Yes it is non business code (non domain specific code) that I use in almost every project. E.g. application blocks for email notifcations and templates. Or MVVM framework for WinForms. Yes once in a while I tweak the code or add features.


Yes and javascript land and java land etc etc etc


Well that would be idiotic.


Well do you or dont you use any java frameworks? If not, then I would say 'idiot'. Why reinvent it each time. I think not using libraries and thus not promoting code reuse is foolish and shortsighted. I own my software company so reusable code that can save me time and money allows me to sell that reusable module again and again. Someone that does not see the value of code reuse probably just works for a salary...

<d!cksw!ing>
My code libraries are frameworks on their own. I use it where needed. They are well designed, open and extensible. I have 30 years of experience under the belt and have a knack for identifiying and extracting patterns and putting generalised pattern implementations into place. Some of my code was bundled with a commercial product many years ago. I have also developed a few systems that were worlds firsts. So whatever... </d!cksw!ing> ;)

Guess there was some misunderstanding. of course I use frameworks and libraries, I never said otherwise. doing everything from scratch is the height of idiocy.
I just don't call these things "tons libraries that I have developed over the years"
 
Last edited:
pretty much although a minor addition if you've got an interface that users understand even if its not perfectly functional you can at least do you are on the right page as you are writing implementation of of the actors and so on. If you have a SaaS orientated backend (as it were - I am being really imprecise with terminology here but I think you know what I mean) it is a lot easier to then develop a web/mobile/non-windows client interface. My general view is that Microsoft has managed to hold onto a king of the business pc world because they are able to allow developers to have an interface ready very quickly whilst various forms of actions and processes get put together and are reusable. Unfortunately though this hasn't carried as well over to a mobile device platform and looking at what you are needing to do you do want people to be able to fill out lading information at loading point or for customs inspectors to get the "paperwork" of a tablet at the reception site.
 
pretty much although a minor addition if you've got an interface that users understand even if its not perfectly functional you can at least do you are on the right page as you are writing implementation of of the actors and so on. If you have a SaaS orientated backend (as it were - I am being really imprecise with terminology here but I think you know what I mean) it is a lot easier to then develop a web/mobile/non-windows client interface. My general view is that Microsoft has managed to hold onto a king of the business pc world because they are able to allow developers to have an interface ready very quickly whilst various forms of actions and processes get put together and are reusable. Unfortunately though this hasn't carried as well over to a mobile device platform and looking at what you are needing to do you do want people to be able to fill out lading information at loading point or for customs inspectors to get the "paperwork" of a tablet at the reception site.

Correct. The interfaces and endpoints can evolve over time. E.g. while in development I like to have a laptop and a RAD desktop app performing the 'point of activity' functions to refine and discover use cases or new interaction requirements right there where the users perform their task. In this particular industry, practical considerations of how tasks are executed on the floor has a big impact on how the user needs to interact with the system. Very easy and quick (cheap) to make changes and nail it down when you have a RAD tool on the desktop and the app acting as a sustitute for the mobile app.
 
well keep us posted
you have me very intrigued

but yes looking at it I reiterate my initial statement (with few additions) your master plan should see things mapping to the various technologies under the Apache umbrella:
http://projects.apache.org/indexes/quick.html
the C# aspect of your existing code is a challenge but probably less so than we (myself included) are assuming

while building use your existing resources and tools - after all you are eating an elephant
 
Top
Sign up to the MyBroadband newsletter
X