In-Depth

Cloud Computing Success: 11 Ways to Prevent Analysis Paralysis (Part 1 of 4)

Why analysis is an absolute necessity for you to succeed at implementing your cloud computing solution.

By Frank Bucalo, Enterprise Architect, CA Technologies

I was on a project recently where my customer stated, "We tried systems analysis but it didn't work, so we don't do it anymore." I've either heard or observed this sentiment expressed many times throughout my career. Sometimes it is explicitly stated, as with this customer. Other times it is implied. In the past I remember a colleague insisting that iterative prototyping (we nicknamed that approach "idiotive prototyping") would eliminate the need for analysis.

Another such example is when an agile methodology is embraced with the hope that analysis can be eliminated. Other times it is expressed in the hope that out-of-the-box content will eliminate the need for analysis.

A colleague once told me that he was studying fuzzy logic because it would eliminate the need for analysis. I think some consider embracing cloud computing with the secret hope that the need for analysis will be eliminated. Although all of these approaches and methods have strengths and benefits (and a place in the system implementation process), none of them eliminates the need for analysis.

What is it about analysis that makes people cower in fear and projects come to a grinding halt? I believe that the key is that we, as humans, are abstract beings. Contrast that with computers that, as machines, are completely concrete. In my years as a trading systems architect, I passed through Pennsylvania Station in New York City every day. I observed tens of thousands of people walking in many different directions at high speed drinking coffee, reading the newspaper, and talking on their cell phones. They were able to avoid, for the most part, collisions.

I started to consider what kind of system I would have to create to capture and process the massive volume of data that was being processed by each and every person, in a completely abstract and intuitive fashion. It boggled my mind.

Likewise, I have a two-and-a-half year-old at home. He has figured out how to walk and talk with no formal training. (Of course, as some have pointed out, the challenge now is to teach him to sit down and be quiet.) As you can imagine, I beamed when he told me, "Pa, you are irritating me" after I insisted that he clean up after himself. I am amazed at the human mind and its ability to achieve complex results with little or no concrete effort. What complex creatures we are!

Now contrast that with computer systems. They, too, are amazingly complex, but they are completely concrete. I know of no computer that can unload itself from the box, much less learn how to deploy and manage itself. I, as a cloud computing systems analyst and architect, have to use all of my years of knowledge, talent, skills, creativity, and ingenuity to make a concrete system of hardware, software, and wires to appear to be just mist.

The challenge of cloud system implementation is discovering and mapping human systems -- abstract and intuitive -- to computer systems -- concrete and quite literal. Performing such mapping is a painful, exhausting experience for most people because it is counterintuitive to the way we are wired. I once worked with a team from a company that was rapidly expanding. They had chosen a cloud-based solution, hoping that by simply accessing it they would eliminate the need to add staff proportional to their growth rate.

Instead, they were disappointed to find that the software did little for them. After six months, they found that they were adding new staff for each and every new customer. They were angry and disappointed. I was dispatched to determine why the software was not working as hoped. I discovered that the problem was not with the cloud-based software. Rather, they had not understood the capabilities and limitations of the software. Nor had they discovered their business rules, policies, procedures, and processes and made them concrete so that the software could be configured to automate their abstract tasks. More important, they did not have staff skilled in systems analysis to lead the effort.

This led me to hold what I call an "enablement workshop." Its goal was to start the mutual discovery of software capabilities and business context and to teach their staff to map the two to achieve desired results.

On the first day of the workshop, we took one of their services and decomposed its life cycle. We answered questions about what it was composed of, how it was requested, how it was approved, how it was deployed, how it was monitored, how it was measured against SLAs, and how it was billed for. By the end of the first day, my customer's staff was completely exhausted by the act of discovering all the details for this service instance lifecycle.

When they showed up the next morning, I could sense that a deep depression filled the room. When I asked why they told me, "Frank, we only did one service yesterday. We have one hundred services. We'd rather die than do this ninety-nine more times." I was able to encourage them by telling them that first service is the hardest.

I showed them that with the first service they identified business rules that applied to many of their services and could be re-used. Moreover, I told them that they had endured the initial learning curve of understanding the universal steps for defining a service instance lifecycle.

By the end of day two they had defined three more services and modeled them in the tool. Even though this abstract-to-concrete mapping was still exhausting, they were relieved and excited to see that their rate of mapping was increasing at an exponential rather than a linear rate (more on "enablement workshops" in future articles).

The remainder of this series will present eleven techniques to avoid analysis paralysis and enable cloud-based system implementation success.

Frank Bucalo is an enterprise architect at CA Technologies and the author of our previous and highly popular series, Traits of a Total Architect. Prior to his time at CA Technologies, he was an architect and a consultant with banking and brokerage clients. He is a member of the Global Association of Risk Professionals (GARP) and an ITIL Service Manager. Mr. Bucalo is knowledgeable and experienced across business, technology, and technology management domains -- a true Total Architect. You can contact the author at frank.bucalo@ca.com.

Must Read Articles