Archive

Monthly Archives: October 2014

Architecture and technology decision making.

Making decisions

Making decisions

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.

    1. Who is using the solution?
    2. Review the user population, the business growth plans, and volume peaking factors
  1. Understand the associated risk with type of application.
    1. What type of Application is supporting the business function? Is is a messaging application, a reporting and analysis, etc.
    2. For instance, messaging, ERP module(s), reporting and analysis, Business or consumer portal.
  2. Understand the associated risk with the technology the application or solution is dependent upon
    1. Is this a new technology platform or solution for the Enterprise?
    2. Has the technology been demonstrated to work at the expected load?
    3. Is there a critical technology required from a third party?
    4. Will part or all of the solution be hosted externally?
  3. Understand the risks associated with the Application release strategy
    1. Expected frequency of releases
    2. Degree of change per Release
    3. Added business units at each Release increasing volume
    4. Will the application be on a brand new release of the product
  4. Understand the risks associated with the entire Solution Architecture (logical and Physical layers)
    1. Is there a critical new component required for application
    2. What is the configuration testing environment
    3. What reference can the vendor introduce you to, are they using the version and features you will be using?
    4. What is the team depth of the vendor
    5. Who will be making the changes for you, the consulting organization or the development organization?
  5. Understand the risks associated with the team organization and structure
    1. Has the Solution architect done this before
    2. How distributed is the team?
    3. Does the team understand the development methodology
    4. Is the technology new and requires a scarce skillset?

Hopefully this will help you get to the running car and not the chain saws.

 

DevOpsProblem

DevOps is a popular trend in IT and have been gathering steam. The challenges with DevOps for large companies are plentiful. One of the key roadblocks comes from the Vendor Management and Vendor Contracting groups.  Nothing to do with the actual task at hand. Large companies often outsource development to one or more large System Integrators.  They develop the code or assemble the solution and hand it off to another company doing the operations support. The contracts these companies write are usually very specific on who is responsible for what.  If you want one Integrator to support your performance testing, that must be in the contract and part for the price or bid.

How do we get the two or more SI’s to work towards a DevOps model? The customer must adjust their contracting terms to accommodate this and provide a path.

Starting the DevOps culture in a Large fortune 500 company is no small task. You can define and start a pilot within your Performance testing team. A meaningful performance test requires multiple disciplines to execute and analyze results and for root cause analysis.
The Performance engineer drives the process, the application architect can see the application under load or stress to see how their design is working, the operations team can see the installation and configuration process, can help with the automation and deployment scripts or approach.  All can benefit from the APM monitoring that is required for critical transactions. I think it might a smaller challenge to get some SI buying for this type of approach.  Then perhaps more onto a Production application.