Architecture and technology decision making.
Lets hide behind the chain saws
In the spirit of Halloween, Chain saws. What a great commercial from Geico to highlight the subject of poor decision making; when you’re in a horror movie, you make poor decisions. There is a running car that is ready to go, but they decide not to take it. How many of us realize that after the architecture has been defined and the development starts, that maybe, in hind sight, we choose to hide behind the chain saws. Another familiar scenario is after your business selected a software product that met the functional requirements, however it wasn’t even close meeting the performance and scalability requirements. The product was selected, and then later in the SDLC it was very apparent that the software product was not going to meet the performance goals without a significant amount of rework from the vendor and three times the original capacity plan, from the vendor.
What is the decision making process? How do we make the right or wrong decision? The more difficult it is to undo the decision, the more information we need. To help make the choices, we have our personal experience, there are best practices, we have mentors and peers we consult, you have situational information and often times not enough information. How much information do you need to be comfortable to commit? One quote comes to mind, from General George Patton, “Perfect is the enemy of the good”. His approach being the most important thing you can do is to make the decision quickly and move on, then adjust when new information becomes available. Though, some decisions are tough to undo. Like committing to a new software product without the proper information.
When selecting a product that will be part of the key business function, you should make sure these items are part of your decision making process;
Understand the risks from the User population.
- Who is using the solution?
- Review the user population, the business growth plans, and volume peaking factors
- Understand the associated risk with type of application.
- What type of Application is supporting the business function? Is is a messaging application, a reporting and analysis, etc.
- For instance, messaging, ERP module(s), reporting and analysis, Business or consumer portal.
- Understand the associated risk with the technology the application or solution is dependent upon
- Is this a new technology platform or solution for the Enterprise?
- Has the technology been demonstrated to work at the expected load?
- Is there a critical technology required from a third party?
- Will part or all of the solution be hosted externally?
- Understand the risks associated with the Application release strategy
- Expected frequency of releases
- Degree of change per Release
- Added business units at each Release increasing volume
- Will the application be on a brand new release of the product
- Understand the risks associated with the entire Solution Architecture (logical and Physical layers)
- Is there a critical new component required for application
- What is the configuration testing environment
- What reference can the vendor introduce you to, are they using the version and features you will be using?
- What is the team depth of the vendor
- Who will be making the changes for you, the consulting organization or the development organization?
- Understand the risks associated with the team organization and structure
- Has the Solution architect done this before
- How distributed is the team?
- Does the team understand the development methodology
- Is the technology new and requires a scarce skillset?
Hopefully this will help you get to the running car and not the chain saws.