iGOR Design/Architecture Philosophies

The iVision Way

Actually, we don’t have a codified ‘way’, as far a project architecture goes, but we have guiding principles that allow us to deliver quality work in volume. I am going to steal an analogy from a co-worker (thanks Brian!).

Software projects are like trying to build a tower out of blocks. The higher the tower, the more features and business value is delivered. Some will start putting bricks one on top of the other and the tower gets high very quickly. This method involves little to no strategic planning or processes to support the development cycle. Thus the tower is unstable, and seemingly small changes can topple whole thing. These kinds of projects are rarely delivered on time or on budget. Others will build a wide and stable base and only start building upwards when they are sure there are no issues with the blocks already placed. These teams create reams of documentation and analysis of the business space and all interconnected systems. Analysis paralysis, it eats at deadlines and produces little of actual value to the business. These kinds of projects never deliver. Other projects are built with a solid base, just wide enough to support the pieces above. The tower goes up at a reasonable pace, with a stable support that allows for flexibility in case of change or the unexpected. This final method is far more likely to deliver on time and on budget and is what allows iVision to succeed where others fail.

I will assume you know how to download the Azure SDK and set up a new cloud project with the correct setting. I won't bore you with those details. I also won't subject you to testing plans and UI control minutia. Let’s get right to the fun.

iGOR Specifics

We have identified four separate projects to make up the solution; a web site, an API, an Azure worker and a desktop application. As we progress we will add more as the design dictates. Our initial solution looks like this:

iGOR is the Azure project and iGOR.Portal is our web site. The rest should be self exploratory. We are going to start with the desktop app (iGOR.App). This is because we need to be able to create and submit fake data tracks to iGOR for testing and demonstration (remember this is not a real production app). Also I find it to be an interesting problem to solve.

Here is a mock up of the main layout of the app we are going for:

As you can see we are looking at eight tabs, each with a distinct role in tracking remote employee locations, solution maintenance and settings. Next post will be a deep dive (including code) into generating fake device tracks using Google Maps.