In-Depth
Cloud Computing Success: 11 Ways to Prevent Analysis Paralysis (Part 2 of 4)
From becoming a more effective system analyst to understanding the cloud computing stack, we continue our series with advice to help you achieve your goals and avoid the paralysis of analysis in your cloud computing project.
By Frank Bucalo, Enterprise Architect, CA Technologies
In the first article of this series, we identified that analysis is an absolute necessity for you to succeed at implementing your cloud computing solution. We saw that the challenge is to discover the details of abstract, human systems and map them to the capabilities of concrete systems.
We saw one example that demonstrated how painful of a process this can be, which explains why people desperately want to believe that they can avoid analysis. However, we also saw that one can learn to perform analysis using knowledge, skills, and techniques. In this series, we will review specific mechanisms for achieving cloud-computing success.
Technique #1: Become an Effective System Analyst
This is harder than it sounds. It seems that the industry has many conceptual thought leaders at one end of the spectrum and many knowledgeable, highly-technical individuals at the other. The problem is that there are few that can discover and completely understand requirements and translate them to the concrete level required to support automation. There seems to be a hole in training, curriculum, and experience in the area of systems analysis. There are many books on systems analysis and many MBA and Computer Science programs include systems analysis in their curriculum, but evidently there is a lack of practical knowledge.
Technique #2: Understand the "Cloud Computing Stack"
To understand cloud computing, you must understand what I call the "Cloud Computing Stack." That is, cloud computing is anything but mist. From the top down, understanding the stack involves understanding:
Business Process Orchestration: Every solution is a business process. Without correctly understanding and orchestrating the business process, you have no solution. Millions spent on the following layers have no purpose or value separate from optimizing and automating your business process. I heard one architect describe orchestrated business processes as a money-making machine. He put it this way: "You put money into automating the business process, which reduces your costs or increases your production, and profits come out the other end."
IT Infrastructure Library (ITIL): This conceptual library describes every aspect of providing business-aligned IT services. It provides an overlay, a vocabulary, and abstract processes to understand and manage any Information Technology environment. ITIL covers such topics as defining and maintaining your service definitions, service accounting methods, service support, and so forth.
Some have thought that cloud computing eliminates the need for ITIL. Without going too far in depth, I suggest that cloud-computing has made an understanding of ITIL more, not less, important. That is because introducing additional layers and partners makes the formalization of agreements and processes an absolute necessity.
For example, organizations that previously did not have to consider the impact of operational-level agreements (OLAs) on their service-level agreements (SLAs) must now be acutely aware of the relationship.
Agile Methodologies: The software development method of choice for many software-as-a-service (SaaS) providers. The requirement for rapid change across distributed environments "drives a stake through the heart of waterfall development."
Service-Oriented Architecture: The default standard for architecting distributed software systems.
Virtualization: The technology that supports the ability to efficiently and quickly provide infrastructure in a cost-effective manner.
Physical Infrastructure: The actual hardware that supports virtualization.
These are all broad and deep topics. You do not have to be expert in all of these topics, but you must have a general understanding of the issues, options, and best practices for each layer. Armed with that knowledge, you can quickly categorize your requirements to the appropriate layer of the stack and map them to known best practices for design. Otherwise, one can "brain-lock" -- experiencing the paralysis of analysis.
I recommend that you constantly read sources about these topics. You might believe one can only learn by hands-on experience, however, those days are over, at least for the systems analyst. There is no way a systems analyst can afford to take two years of hands-on experience to master a technology concept. This is especially true when you consider that technology is changing at light speed and the stack is getting broader and deeper continually. This is where your human abstractness is of great value. You must read continually to build a library of knowledge and concepts to draw upon during analysis and design.
Again, it is the combination of human abstractness with the concrete capabilities of computers that produce miraculous results. If you read voraciously, write notes in margins, read sources multiple times, and read multiple sources on the same topic, you will gain a degree of conceptual expertise and be able to avoid the paralysis of analysis.
For example, just last month I was on a customer site architecting business processes orchestration. While I was there, they asked for advice related to their business process governance. After a few moments of thought, I realized that governing their automated business processes mapped directly to SOA governance, a topic I had researched extensively. Rather than brain-locking, I was able to locate and download an SOA governance framework, including templates, which fit their needs.
Pleased with my rapid response and solution they told me that they intended to start using offshore resources for process development and if I knew of any recommendations pertaining to distributed development. I had come across a framework for doing geographically dispersed agile development called DH2A (design for hybrid agile adoption). Again, we quickly located material about that framework. These use cases demonstrate that the world of cloud computing is full of common issues and challenges as well as solutions. By reading voraciously, across the cloud computing stack, you can become aware of them, thus avoiding the paralysis of analysis.
Technique #3: Understand General Integration Design Patterns
The fact is cloud computing solution components are typically not built from the ground up to integrate with each other. Most solution components are built in silos, often being acquired and assembled into one or more solution suites. The good news is that open standards have evolved, which facilitate integration. Also, integration approaches have become somewhat standardized. You must understand common integration design patterns and know when and how to use them. For example, I perform cloud implementations that combine eight or more independently constructed physical products, which must act as a single seamless logical system. Some patterns I encounter include:
Functional Integration via Web Services or REST: Almost every cloud product component provides a programmatic interface. This provides for functional integration via event engines and orchestration engines to make disparate functions synchronize.
Orchestration: Although functional integration provides touch points between solution components, an orchestration tool is required to integrate those touch points into a seamless, holistic, integrated system.
Integration via a Data Mart: Typically a business process view is required to monitor, measure, and report on business process progress across multiple components. No matter how much we would like, it is not reasonable to believe that solution components were created with your specific business process in mind. I often design a data mart, where process steps across disparate products can be recorded, correlated, and reported to support business and operational analysis. In a future, article I will provide advice as to how to do this in an effective and efficient manner.
Integration via a Portal: This is often the simplest possible integration. Users hate having to log in and out of disparate systems to see what is transpiring with their business processes. For example, one client has a service catalog (where requests for service were made) and a service desk tool (where services were deployed). Their users were quite upset and their project was being viewed as a failure. Using the portal technology embedded in their service catalog, I was able to integrate multiple product screens into a single portal screen, giving users the impression that they are in a single logical application.
Integration via Reporting: Combining cross-product reports is another way users can have access to the required information across cloud computing solution components to do their job at their fingertips. In the case of the customer above I used the catalog's embedded report writer to create a top-level report of user requests, each of which drilled into the deployment details in their service desk.
Armed with the aforementioned techniques, basic knowledge across the cloud computing stack, and integration patterns in the context of cloud-based solutions, companies will be able to quickly achieve success with their cloud-based deployments.
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].