In my last post I covered the five elements of a business value chain (Marketing & Sales, Service, Inbound Logistics, Outbound Logistics, and Internal Operations). I displayed the diagram below and made the following comment:
The arrows that flow across this diagram actually represent business scenarios that involve applications talking to each other and pushing data between different business activities.
During this post I'd like to project a set of application images on top of the diagram above and begin a dialogue about application patterns. Consider the application projection view depicted below:
I've listed several dozen applications in the diagram above; the truth is that a large enterprise customer may have several hundred disparate applications and application workloads. Mapping the demand characteristics of hundreds of applications onto an appropriately capable IT infrastructure is a daunting task. However, the proper placement should indeed be the target state of any business' IT infrastructure.
My EMC colleague Peter Kraatz has written a quite useful article describing best practices on how to get started down this path. He recommends techniques for narrowing down the list of applications from hundreds of workloads to dozens, with a special emphasis on avoiding the temptation to analyze the most gnarly, mission critical workloads. I like the practical nature of his advice and believe it should be followed.
Once his advice has been followed, however, how can these application workloads be subsequently (and appropriately) characterized? How can each workload translate into demand characteristics that should be run on the best-fit match from a supply-side IT infrastructure?
In order to answer this question I turned to the writing of another EMC colleague: Sheppard Narkier. Sheppard has learned through experience that most applications follow design patterns and that these design patterns can be fully articulated by using less than ten categories. What are the value of patterns? I strongly recommend Sheppard's article on the topic, which in part reads:
My colleagues and I have used IT patterns extensively because of its power to convey so much information in such a compact form. We have been able to codify a collection of patterns (functional, data, storage, application, deployment, etc.) and have plans for several more categories. We have found that working in patterns allows problem solvers to get to the essence of an implementation without getting bogged down into the details.
By projecting applications onto their location in the Business Value Chain, the Adaptivity team has uncovered that there is significant pattern commonality among applications in the same (or adjacent) section of the chart above. Sheppard points out in a separate article that....
....while each workload is typically viewed as unique by their owners or creators, our experience has shown that the large class of enterprise workloads exhibit behavioral patterns that can be classified into a small number of consumption types (we have found less than 10). Characterizing these types of demand consumption is critical to consistently managing a complex environment that ensures optimal value in terms of cost, efficiency and the quality of the user experience. We had coined the phrase ‘fit-for-purpose’ to describe this business demand driven approach.
So what is the relationship between workload patterns and underlying IT capabilities? Do the sections of the chart shown above map down nicely onto different forms of IT infrastructure?
The answer, generally, is yes. I will dive down into an examination of this phenomenon in future posts.