Years and years ago, I presented a session at a conference and called it My Nirvana model. The drawing to the left is what I presented at the time. Basically the premise was having a model to find the proper platform for your business application. The arrows on the chart meant the price went up based on various parameters. The key point I was making with the presentation though was to not only worry about the platform but to ensure you were asking the right questions in the first place.
In the drawing, I designed it so that you could change the players in the boxes. For example, the drawing is what I presented years ago. You can tell this quickly because of the names of the key products. You can take that model, empty out the boxes, and start adding in names like Cloud, Hybrid, Local, Java, .Net, mobile, tablet, etc. Those are more current terms, but interestingly enough have some of the same components – it’s just the names of the players and some terminology that have changed. At the core, though, you have to choose where you run your application – and it should not always be based on price. The adage “you get what you pay for” applies here too.
You need middleware to act as glue or plumbing holding applications together. You need languages that allow for portability so you can design it once and use it anywhere. You need hardware that will support all your data in the way you need it.
However, anything on the model is all for naught if you don’t ask the fundamental key questions. They are:
- How much data is involved
- How real time does the data need to be
- Who will need access to the system
- How will the users access the system
- Must the application be scalable – to allow for adding data
- How much money do you have to spend
- How flexible does the application need to be – will the environment change often
- How soon does this need to be ready to implement.
It always amazes me, as a project manager and analyst, when people come to me to design and build an application and they haven’t a clue how to answer the questions above. That means the project is potentially doomed from the start. In fact, that is why I gave the session in the first place – it was addressing why projects fail.
It’s more than just “we need an app to do this…” You need to define as much as possible before starting the implementation to ensure you end up with a result you can use. Don likes to say, as part of capacity planning, “speed, reliability and cost, pick two. ” It’s true of project planning as well. How often does the data get updated – how fast does it need to be available (real time or updated overnight) - can it be down for 2 days (like some cloud environments have been recently) – how much can you spend on the app and the environment.
So many questions and so many choices. The trick is weeding through it all and finding the right solution. And you don’t have a magic wand to make it happen. You have dig for the answers. To steal a line from I Robot, “That, Detective, is the right question. “
The Message here is clear. The model stays the same. Only the names of the players change. Keep asking the right questions