In-Depth
Cloud Computing Success: 11 Ways to Prevent Analysis Paralysis (Part 3 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
In the previous article of this series, we looked at three techniques relating to achieving success with your cloud-based solution. We reviewed that the one must be a systems analyst to lead a successful effort and that one should have at least basic knowledge across the cloud computing stack and that knowledge should involve an understanding of basic integration patterns.
This article provides additional and specific words of advice to achieve your goals and avoid the paralysis of analysis.
Technique #4: Know How to Right-Size Your Design
I could hear you sigh as you read the previous article in which I mentioned data marts and SOA governance. While working with one customer, I mentioned the data mart. They slumped in their seats and a sense of darkness filled the room. I asked them to identify the problem to which they responded, "Frank, anytime we engage our enterprise data warehouse team, everything comes to a grinding halt. The enterprise process is so heavy that we cannot accomplish anything in a reasonable amount of time. If we need a data mart to satisfy business requirements, then life is over."
Likewise, I was at a customer site where I suggested the use of SOA governance techniques to manage their business process inventory. Again, I saw the ghost of projects past descend upon the room. They, too, had an enterprise SOA governance process that was extremely heavy. Using it would doom their implementation.
To both these groups I replied, "I did not say that you needed an enterprise data warehouse or SOA governance solution. You can implement a data warehouse or SOA governance implementation 'in the small.'" By that I meant that you can apply the same standard concepts and techniques (see Ralph Kimball, The Open Group SOA Governance Framework) on a small scale. One person might perform in many roles and tools used could be as simple as spreadsheets. The key is to be aware of the issues and approaches required to keep your solution in good working order.
That's not to say that your needs will not increase over time. You can scale up later as the scenario demands. In the event that some of your artifacts are valuable at the enterprise level (master data management and master SOA governance), then those specific artifacts can be replicated into the enterprise-level solutions.
Technique #5: Obtain and Analyze Current Business Artifacts Prior to Starting Your Implementation
Picture a common problems scenario -- the analyst meets with the business stakeholder and, in front of a blank whiteboard says, "Tell me what you want." Often, the business stakeholder replies, "What have you got?" and things quickly come to a grinding halt.
The key to kick-starting your analysis is to understand that your current business artifacts contain much information about your environment. That information can quickly bootstrap your implementation. For example, I was scheduled to work with a client from South Africa to produce an accounting system for their IT services. Prior to my seventeen hour flight from New York, I had obtained sample invoices and sample service usage data. With the combination of their service usage information and the related invoices, I was able to formulate a fairly accurate hypothesis of their business context and accounting algorithms, before ever arriving in Cape Town, saving many days of effort and defusing potential paralysis of analysis.
I have seen similar artifacts that can jumpstart your implementation. They include reports, process models, and so forth. You might ask, "Frank, what if the goal of the project is to improve the current state? Won't analyzing current artifacts slow us down?" The answer, again, is "No." Even though the goal is to improve your current environment, the "straw man" derived from your current artifacts becomes a wonderful starting point for identifying why you do it that way. Then you can determine which business rules, policies, and procedures are negotiable and which are not.
Another benefit of analyzing existing artifacts is detecting misinformation. Misinformation is a common problem. I can't tell you how many times I've run in to a "definitive" business rule only to find that many exceptions exist. Because of the preliminary analysis of artifacts, I am able to detect the problem early on. Often, the "rule" is contradicted by the artifacts -- it does not pass the "sniff" test. It is not strange to have to iteratively elaborate and redefine so called "definitive" business rules until a precise business rule has been formulated.
Misinformation is a consequence of our abstract nature. We think in terms of "sort of" and "approximately." This level of understanding will not suffice if we are to automate business processes. Business rules don't have to be 100 percent concrete. Trying to force a business rule into such a scenario is another reason why analysis paralysis sets in. The key is to define the scenarios where the business rule is hard and fast. Those scenarios can be fully automated, then the scenarios that are more abstract can be routed to a human for manual processing.
Technique #6: Prepare to Own Your Cloud Solution
I have arrived at many sites where I have asked customers to identify their business and technical owners, only to have them tell me, "We didn't think we needed a business or technical owner. That's why we sought out a cloud-based solution." Well, consider that I can stand up a "sandbox" of the product, but that product is not production useful until it is configured to reflect your optimized business environment. There is no way that optimization can be achieved without the participation of your staff.
As an analogy, consider if I sold you a word processing package. It would be insane to think that the word processor would be able to generate a new Pulitzer Prize-winning novel out of the box. I encounter such expectations for business systems all the time. Also, consider the fact that your business, like everyone else's, is rapidly changing. You will have to reconfigure your solution over and over again to meet changing requirements. Without having client staff able to perform that reconfiguration, your optimized-system will quickly become less-than-optimal.
As one client came to understand, implementing business systems is a process, not a project. You might then ask yourself why you selected a cloud-based solution. The answer is that your only other option is to code your own product from scratch. My friend from New Jersey would say, "Good luck with dat!" After you code it from scratch, you still must deal with the reality that the world and your business are volatile and rapidly changing anyway. No, you must be grateful that you don't have to create a solution from scratch but be fully prepared to understand your cloud-based solution and your business context so you can reconfigure it regularly as your business context changes.
Technique #7: Perform an Enablement Workshop
Given that your staff will have to own and manage your cloud-based solution, I recommend leading with education provided by an experienced Subject Matter Expert (SME). Cloud-based implementation is emerging as the norm. The need for business agility has driven many information technology groups to eschew "build over buy." Cloud computing represents the next step in that cultural transformation. But many think that because you no longer own the application or infrastructure, and because the tool comes with predefined content, education is not a requirement.
Nothing can be farther from the truth. First, consider that ready-made content contains many implied business rules. Now consider what the odds are that the vendor-defined business rules are optimized for your business environment. The existence of OOTB content is a strong selling point and highly-desired by customers, but you are going to have to reconfigure your cloud-based solution to map to your specific requirements.
"But Frank," you say, "Won't stopping to learn the tool slow us down and increase time-to-value?" My answer is "No." It is better to take a couple of weeks to understand the solution that you have chosen and how to use it efficiently and effectively than to run one-hundred miles per hour in the wrong direction. For example, I often work with IT departments that are transforming to become cloud providers. I typically see them define their services abstractly (e.g., obtain a virtual server) and then create overly-complex forms (to capture request metadata) and even more complex workflows to manage the approval and provisioning processes.
In my workshops I demonstrate that defining services more concretely (e.g., obtain a Unix server with high-availability and disaster recovery) often leads to targeted forms that are intuitive for the service requester, and simple, straight-through workflows (more on this use case below). Many clients have had to re-factor or discard six or more months of work upon understanding the tool and best implementation practices. The reason enablement workshops work is because you are solving an abstract problem (discovering requirements and mapping them to the toolset) using an abstract method -- cloud solution immersion.
Just as my two-year-old (whom I mentioned in the first article in this series) learned to speak by immersion, your customer will learn to implement and own their solution by immersion via the workshop. Contrast the immersion method with what I call "The Questionnaire Approach." That attempts to capture requirements with a series of canned questions. In my experience that approach rarely works. That is because it is an attempt to solve an abstract problem using a concrete method. That's when things get difficult. As we've already seen, customers can rarely provide definitive business rules, policies, and processes. When you add the need to provide business context in terms of a cloud-based system they are unfamiliar with and the challenge is even more difficult.
The typical response to initial questionnaire failure is to increase the number of questions and to increase the amount of documentation, which also proves fruitless. Remember that in our humanness we can intuitively perform extremely complex processing. Leading with an "Enablement Workshop", run by an experienced SME can quickly bootstrap your implementation and eliminate much wasted time and effort trying to complete questionnaires.
The next and final article is this series will provide four more techniques that will facilitate your cloud computing success and reduce the probability that you will experience analysis paralysis.
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 [email protected].