In-Depth
Cloud Computing Success: 11 Ways to Prevent Analysis Paralysis (Part 4 of 4)
Our final set of recommendations for avoiding analysis paralysis in your cloud computing project.
By Frank Bucalo, Enterprise Architect, CA Technologies
In the previous article in this series, we looked at four topics that reduce the probability that you will experience analysis paralysis. Our advice is designed to help you bootstrap your cloud computing implementation success. This article examines the last set of techniques to help you prevent analysis paralysis when implementing a cloud solution.
Technique #8: Know When to Separate Analysis from Design
Systems analysis purists claim that analysis must be completely separate from design. They argue that considering design during analysis is problematic. Premature design may lead to compromised requirements. Imagine if you have been assigned to join two pieces of wood together. Once you have decided that you need a hammer your world -view gets twisted. For example, even though a screw will hold the wood together better, you will start to rationalize that nails are much easier to manage.
Now let us consider the tool-driven systems analyst. They argue that designing without considering your tool is foolish. After all, if, indeed, you have purchased a hammer, discussing implementing using screws is a pointless and wasteful exercise.
Both viewpoints are correct! This is one of those abstract, human areas where one must use a balanced approach. Consider the analogy of assembling a jigsaw puzzle. Your business requirements are like the picture -- the pieces must be assembled to produce the desired picture. The capabilities and limitations of your cloud-based solution are like the shapes of the pieces. You cannot force a piece that looks like it should fit into a shape that it does not fit. Rather than give in to the temptation to pound the piece in place because you prematurely decided that it should go there, you need to back away and look at another piece.
So it is with your cloud-based analysis and design. While determining your business requirements, you can and should consider the capabilities and limitations of your tools. But, if you find yourself tempted to “pound” your requirements into place, back away from the tool for a moment and consider another approach.
I remember one such example. A client had defined a design that required a dynamic service catalog. Much effort had gone into determining the user’s context and defining what services they should be presented with in real-time by assembling a catalog on the fly. This proved to be extremely complex, and unnatural use of the cloud-based solution, and, quite frankly an incorrect business rule that brought their implementation to a halt. I was called in to assist. When I arrived, I backed up to the analysis phase by drilling into their requirements by iteratively asking “Why? until I got past the pre-mature design to the business requirement itself.
It turned out that there were a number of business units, each of which had a static catalog of services. The actual business driver was that users can change business units. The catalogs were not dynamic -- the user’s business unit was. Once the correct business rule was determined, we were able to quickly configure the cloud solution to determine the user’s current business unit and set it appropriately at the point of login. Then they were presented with the appropriate catalog. The premature design drove the client down the wrong path. Also, you see that ignoring the cloud solution capabilities and limitations was problematic.
Technique #9: Prefer Feature-Rich to Feature-Poor
I have often seen customers drawn to cloud solutions with minimal features. They reason that if they have few features, then they will have to make few design decisions. This is another example of the fear of analysis. I’ve even seen cloud providers dumb down their solution, removing features from one release to the next with the hope that analysis can be reduced and implementation simplified. However, after a short time of attempting implementation, customers find themselves “painted into a corner.” That is, by choosing a feature-poor solution, they find that the solution cannot be configured to meet their business requirements. This often results in an effort to shoehorn their requirements to fit the tool (see technique #8, Know When to Separate Analysis from Design, above).
Ask yourself what is more difficult --– changing a business process or reconfiguring a tool? It is obvious that reconfiguring a tool is simpler. That’s not to say that business processes don’t need to be changed and optimized. The point is that you do not want your business process dictated by the use of feature-poor solution. No, you need a solution that provides many features.
The best solutions I have seen provide many configurable options. Such a solution might allow you to satisfy 95 percent of your requirements via configuration. Then, it might allow you to satisfy 4 percent of your requirements using scripting (e.g., cross-field validation). Finally, it might provide hooks so that you can realize the 1 percent of remaining requirements using Java, C++, SQL, HTML, XSL, or other low-level programming environment.
Again, let me address the angst that the mention of a low-level programming environment typically triggers. Your business is complex. You need the “safety -valve” that low-level programming hooks provide. They key is that without a feature-rich tool that provides such hooks, you would either have to use low-level programming to satisfy 100 percent of your requirements or you would have to settle for a sub-optimized design due to the limitations of your cloud-based solution. I urge you to select a feature-rich tool, and then use it wisely, accessing low-level features only when it is absolutely necessary. In other words, configure your solution as simple as possible, but no simpler.
Technique #10: Understand that the Real World Does Not Fit One Single Paradigm
I have seen analysis paralysis set in when system analysts are inflexible. These inflexibilities often result from trying to shoe-horn a solution design into one approach. For example, in the SOA world, interface design is a critical, complex topic. A subtopic of interface design is how coarse or granular an interface is. The coarse vs. granular interface choice has implications.
For example, a coarse request interface, using an XML document, can provide many options but be difficult to understand and use. In one case, I saw a cloud provider offer a single request interface – a common pattern for applications that have been ported to the Web. However, to use that interface, one needed expert knowledge that required weeks of hands-on experience and knowledge of mail- merge techniques to generate appropriate request documents.
Likewise, a coarse response, using an XML document, can reduce the number of requests but increase the amount of network traffic and the need for parsing, making it more difficult to use. These designs decisions have consequences and many a cloud-analyst has brain locked when trying to resolve these tradeoffs. When I encounter such a situation, I simply remind the analyst that the answer might be to build both a coarse interface as well as a granular interface. It is amazing how many times the analyst failed to consider each approach might be correct given a specific scenario.
For example, a coarse interface when reading an entity service (e.g. getCustomerAddress) is often optimal to avoid multiple requests (e.g. getCustomerStreet, getCustomerCity, getCustomerPostalCode,…) for small objects. However, a granular interface is often optimal for requests for update (setCustomerMiddleName), which reduces the scope of locks, or for large objects where network packet size might be exceeded by including extraneous information. The key is to not commit to a single design paradigm. Instead, consider each scenario and choose a design that makes sense for that scenario.
Technique #11: Use Top-Down Analysis and Bottom-Up Design
Most useful cloud-based solutions provide many rich features. When we addressed this topic above, we cited the fact that some think that by removing features their analysis will be simplified. Hopefully, we established that removing features is an anti-pattern, to be avoided, because it removes options. How do you perform analysis for a feature-rich tool and avoid the paralysis of analysis?
Consider a cloud-based tool that provides twenty different configurable features, each with ten options. That results in 1020 (100,000,000,000,000,000,000) configuration combinations. You can see why an analyst might experience the paralysis of analysis and customers and management incorrectly conclude that fewer features and options are better. The problem, however, is not the number of features. Rather, it is taking a bottom-up approach. As in the previous topic, if you start with business requirements, the optimal configuration combination usually makes itself evident avoiding the need to consider each individual combination.
Go Fast but Don’t Hurry
In closing, my old football coach once advised me to “Go Fast but Don’t Hurry.” By that he meant that I should move quickly but I should be aware of my surroundings and make moves that achieve maximum yardage. After all, quickly running into that grasp of a 6’ 4’’ linebacker would not yield much benefit to me or the team. Rather, he told me to run quickly but use my judgment to determine an efficient and effective time to dash through a hole in the line.
So it is with your cloud-based solution. You cannot run quickly in the wrong direction. Under time pressure, you must utilize all your knowledge, skill, experience, and judgment to avoid the analysis paralysis to enable a successful solution. This series has provided both general and specific recommendations for going fast while achieving success in your cloud-based solution.
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].