|
ObjectWatch Newsletter # 43 CONTENTS
Feel free to forward this newsletter, but don't make any changes. Thanks. There are now over 18,000 subscribers to this newsletter and over 70,000 readers! To find out about sponsoring an ObjectWatch Newsletter, contact janet@objectwatch.com. For your own free email subscription, send mail to sub@objectwatch.com saying: subscribe your-name, your-email For example, subscribe William Shakespeare,william@objectwatch.com To unsubscribe, send mail to sub@objectwatch.com saying unsubscribe your-name, your e-mail QUOTATION OF THE MONTH:LINUX: FREE AND PORTABLE"’Enterprises now realize that they are writing to a distribution, not to Linux in general. What works on Red Hat Advanced Server will not work on SuSE Linux,’ Schwartz [Sun's executive vice president of software] said. ... There is little doubt that the notion of ‘Linux and free have gone away. Red Hat's pricing model now makes that clear,’ he said.” - Sun Drops Its Linux Distribution, in eWeek, March 28, 2003By Peter Galli http://www.eweek.com/article2/0,3959,981455,00.asp The winner of the Quotation of the Month Contest is Roger Sessions who gets a choice of a personally autographed copy of Roger Sessions's just released book, " Software Fortresses; Modeling Enterprise Architectures", or the ObjectWatch BBQ apron. Send in your nominations for Quotation of the Month to roger@objectwatch.com, and you too can get a personally autographed book/apron! MAIN ARTICLE:PREDICTING ENTERPRISE COSTSWhich is the better breakfast restaurant, Burger King, Starbucks, or El Arroya? Those readers that carefully follow the ObjectWatch Newsletter know that this question is unanswerable. They know from Issue 41 (“Shootout at the Transaction Coral”) that the correct answer is that all three of these restaurants are best. Each of these restaurants has one category in which it excels. In the fries category, Burger King wins. In the breakfast taco category, El Arroya wins. In the all important doppio macchiato category, Starbucks wins. The trick to getting a good breakfast is not asking which restaurant is best, but asking which restaurant is best in which category. Once I have chosen my categories correctly, I can get the ideal breakfast: a breakfast taco from El Arroya, a side of fries from Burger King, and then wash the whole thing down with a doppio macchiato sitting in the home office of ObjectWatch, namely the corner window seat at the Starbucks at route 183 and Anderson Mill Road in Northwest Austin. Had I chosen to purchase my entire breakfast from only one of these restaurants, I would have been much less happy with the result. I would be either munching muffins at Starbucks or drinking dishwater at Burger King. Neither is very appealing. Now you may think I just threw together my morning breakfast. Not so. I have taken a very methodical approach. Specifically, I have gone through the following steps.
Here is how it worked out. The result of my categories analysis was three categories:
Adding in the requirements analysis adds some more bulk: Requirement: R001 Requirement: R002 Requirement: R003 Now I can come up with my various configuration specifications. Notice that I can have multiple configurations specifications for a given category, as I do for breakfast taco, as long as each configuration meets all of the requirements listed for the category. Configuration: C001 Configuration: C002 Configuration: C003 Configuration: C004 I might consider this additional configuration specification for the coffee category: Configuration: C005 However this configuration is not valid. It does not fit the requirements specification for coffee (R001). While it meets the first two requirements (double espresso, foam on top), it fails the last requirement, that it be located within 1/4 mile of 183 and Anderson Mill Road. The closest Seattle’s Best to 183 and Anderson Mill Road is at least 2 miles away. Now I have everything I need to start playing with different enterprise (breakfast) configurations. The only rule now is that I must choose one and only one configuration from each category. Following this rule, there are two possible enterprise configurations: Breakfast: E001 Breakfast: E002 I now know every possible breakfast combination that meets my requirements. I have two. E001 costs $4.61 and E002 costs $4.69. Which one am I going to choose? Since both fully meet my requirements, I will choose the one that does so at the least cost. This is E001. That saves me eight cents. The hardest part of this whole analysis is the first two steps: determining the categories and the requirements. I am lucky than I have such simple breakfast needs. Sometimes we are trying to put together enterprise configurations that are considerably more complicated than my morning breakfast. For example, a large enterprise computing architecture. Such an architecture is going to cost just a little more money than my morning breakfast, and the stakes involved in making poor decisions will cost a lot more than eight cents. Fortunately, the same analytical approach that worked so well for my morning breakfast can be used to make good enterprise systems decisions. Again, those steps are:
Just as it was in my breakfast analysis, the first two steps (categories and requirements) are the most critical, because they drive the rest of the analysis. I’ll therefore spend the most time on these. For a large enterprise IT architecture, with potentially hundreds of computers, dozens of software systems, and multiple platforms, categories and requirements analysis can be very difficult to complete. Unless, that is, one has a methodology to simplify the process. Fortunately, there is such a methodology. It is part of a model that is familiar to most readers of this newsletter, the software fortress model. The software fortress model decomposes a large enterprise into multiple discrete functional units called software fortresses. A typical software fortress might run an accounts receivable system, for example. The software fortress model recognizes six different categories of fortresses. The are:
Within each of these fortress, there are two main categories of systems: worker systems and data strongbox systems. Worker systems are those that manage the overall work of the fortress. In a presentation fortress, these systems would be accepting HTTP requests, preparing work requests for business application fortresses, and generating HTML browser responses. Data strongbox systems are those that manage the data needs of the fortress. For a presentation fortress, these needs are relatively simple, being primarily the state of the various browsers currently working with the fortress. For other fortresses, such as business application fortresses, these data strongbox systems may require high-end databases to store the mission critical data of the enterprise. With six standard fortresses and two component types, we get twelve possible categories. These categories are:
In addition to these, we also have machines that are assigned to deal with infrastructure issues. There are two common categories for infrastructure machines: asynchronous backbone and enterprise data storage. Machines in the asynchronous backbone category are those responsible for managing the messaging infrastructure use to implement the fortress-to-fortress drawbridges. Machines in the enterprise data storage are those used to coordinate any enterprise-wide data storage. The second category, enterprise-wide data storage is a somewhat controversial area. On one hand, I prefer to think of every fortress as owning its own data, including the database and the machines on which the database runs. On the other hand, high reliability databases are very expensive to set up, and once set up, have capabilities far in excess of what any one fortress is likely to need. In a recent enterprise fortress architecture on which I worked, we decided that a reasonable compromise would be to have one group of machines dedicated to enterprise data services and then have those machines run multiple database instances, one instance assigned to each fortress. We then considered the cost of those machines and related software systems to be part of the overall enterprise infrastructure cost. If we follow this strategy, then the previous list of system categories becomes simplified. We can eliminate the six systems assigned to strongbox functionality and replace them by the single category of enterprise data storage as part of infrastructure. We now have these eight categories, with category IDs assigned for future reference:
The enterprise is starting to look a little less complicated, isn’t it? Any of the hundreds of software/hardware combinations can be fitted into one of these eight categories. Each of these eight categories will have at least one associated requirements specification. Many will have more than one. For example, we may have one business application fortress that cannot be down for more than five minutes at a time while another can survive six hours of down time. These two requirements could be expressed as two different requirements specifications, both under the same general category of BAF/WS. After completion of the requirements analysis, we will have a collection of at least as many requirements specifications as we had categories. Here is one example of what one such requirements specification might look like: Requirements Specification: RS005 Category: BAF/WS Our next step is to perform configuration analysis. In this step, we want to look at every reasonable way to satisfy each of our requirements specifications. For example, we might want to consider two possible configurations that both satisfy requirements specification RS005, one based on Microsoft’s .NET technologies and one based on IBM’s WebSphere technologies. A different pair of configuration specifications for RS005 could be developed to compare the cost of Dell and Compaq hardware. Here are two sample configuration specifications that both fulfill RS005. Both are based on Dell hardware. One is based on Microsoft’s .NET/Windows and the other on IBM’s WebSphere/Linux. Note that all prices are based on company catalog information and your prices may vary. Configuration Specification: CS003 Configuration Specification: CS004 Once all of the configuration specifications have been completed, we are ready for an Enterprise Analysis. In the Enterprise Analysis, we list every fortress in our enterprise. For each fortress, we list the component systems (worker or strongbox, if we are using fortress specific strongboxes). For each component system, we give its requirements specification and proposed configuration specification. We can then calculate the total enterprise cost by totaling the chosen configuration specification costs. We can also play with the total enterprise cost by “trying out” different configuration specifications. This may all sound a bit tedious, but the end result is well worth it. At the end of this exercise, you have a good handle on the following information:
I am currently writing an in-depth white paper that goes through a full software fortress enterprise analysis for a typical commerce organization. The white paper will also have an accompanying spread sheet that you can use to try out your own configurations. When that white paper is completed, I will let subscribers of this newsletter know how to find it. Stay tuned. Those readers not familiar with software fortress model for large enterprise architectures might consider attending an upcoming public class on this topic (information on this is earlier in the newsletter). In the meantime, I hope this gives you some ideas as to how to use the software fortress model to help you better analyze your enterprise computing needs and predict your enterprise systems costs. Perhaps we can discuss it sometime over breakfast. I just happen to know the perfect one: E001. You pay the $4.61. I’ll get Janet to cover the tip. We’ll both split the taco when she isn’t looking. - Roger Sessions OBJECTWATCH SERVICESObjectWatch and Roger Sessions can help your company build successful enterprise caliber systems. We offer training at all levels in the software fortress methodology, architectural reviews and consulting services. For more information on how we can help you, see our web site at www.objectwatch.com or contact janet@objectwatch.com. We INVENTED the software fortress methodology. Let us help you use this methodology to create a secure, manageable, scalable, and flexible enterprise architecture. ERRATAIn the ObjectWatch Newsletter #42, the article on the J2EE versus .NET benchmark included the following statement: “The TMC benchmark considered two J2EE products identified only as Application Server A and Application Server B. The reason, TMC said, for doing this was because of licensing restrictions. Apparently the major J2EE vendors include a licensing restriction that prohibits anybody from using their product in a public benchmark, a prohibition that is not included in the .NET licensing.” This last statement was incorrect. Microsoft’s licensing agreement includes the following statement: “You may not disclose the results of any benchmark test of the .NET Framework component of the OS Components to any third party without Microsoft's prior written approval." We are sorry for this error. Legal NoticesThe ObjectWatch Newsletter does not rent out its subscription list. ObjectWatch accepts one sponsoring advertisement per issue. To find out about sponsoring an ObjectWatch Newsletter, contact janet@objectwatch.com. This newsletter is Copyright (c) 2003 by ObjectWatch, Inc., Austin, Texas. All rights are reserved, except that it may be freely redistributed provided that it is redistributed in its entirety, and that absolutely no changes are made in any way, including the removal of these legal notices. ObjectWatch is a registered trademark (r) of ObjectWatch, Inc., Austin, Texas. Software Fortress is a trademark (tm) of ObjectWatch, Inc., Austin Texas. All other trademarks are owned by their respective companies. |