| June 2007 |
| By John Kallipolites |
The mission of the Performance Architect (PerfArch) is to take the initiative in implementing applications of the highest quality. Why? Because when applications with flaws or poor performance characteristics are put into production, the customer suffers and, in the end, the company loses business. We have all heard the truism that “time is money” and it is also true that “a company’s reputation is based upon customer perception.” Perception and efficiency are both presented to the user by application programs which provide services.
The PerfArch has two primary tasks: to mitigate risk within an application and to optimize the testing plan for that application. As a PerfArch, I work closely with the Information and Application Architect to identify, prioritize, and characterize risk in the forms of impact to other systems, lengthy service times due to coding or configuration issues, and to assess the merits of competing solutions. The development of a testing plan is a task which deals with workload considerations, population studies, the identification of critical transaction types, and workflow issues. The ideal test plan will critically test the application in a controlled way such that the behavior of the system can be extrapolated to greater workloads.
It is in the Design Phase of the project life cycle that the PerfArch can have the greatest impact to a project. Which technology option or coding option do you take if there are two equally-good, but radically different, solutions proposed. The PerfArch may model the approaches and produce a quantitative analysis of the contending solutions. In many cases the PerfArch is dealing with application performance issues prior to the existence of the application, data, or business volumetrics. This means that Performance Architecture is often, a precursor to performance and capacity planning analyses.
So, if the code and the data do not exist, then how does the PerfArch predict how a given application will perform? This is a very good question and it is centered on the use of design patterns. A design pattern considers the rudimentary level of operation of a given task (e.g. the minimum time to access 1 row in a database), and that knowledge is applied to an estimated quantity of transactions. Another means of prediction, applicable to existing systems which are undergoing upgrade or modification, is to use a discrete simulation tool (HyPerformix, GoldSim, etc.) to model end-to-end response times of the system of applications. This method requires great amounts of analysis of the business flow, transaction types, data formats, knowledge of the systems (hardware) and operating systems (Solaris, AIX, Windows) and key software (Oracle, DB2, etc). Using the modeling software, the PerfArch builds what amounts to a SimCity-like model of a complex computer system that does not (yet) exist, and with basic assumptions, predicts critical performance levels and scalability options.
The advantages of the model building approach are that the full-scale production environment can be constructed (in software, of course) and stressed regardless of whether the testing environment exists, whether its size and capabilities are adequate, or the schedule is available. Because the model is theoretical, it has a certain amount of portability. It can be demonstrated to different groups at different times in order to obtain their buy-in, or to profile certain results such as doubling or tripling the volume of transactions.
The proof of course, is in the pudding – and that is where the testing plan comes in. Do the tests support the predictions of the model? Can they be extended to handle system growth 2- or 4-years from today? A good PerfArch will have done his homework well, and the model that he builds will minimize testing time by providing a means for testing the most extreme conditions of a system.
All right, so you want to get into Performance Architecture – what is needed to do that? Good question; here’s part of the answer. First, realize that there is no single answer for this question. Second, you need to like working with math and statistics. A knowledge of queuing theory would be helpful – perhaps even a requirement. Third, you need to understand how computer hardware and operating systems operate – at a detailed level. These minutiae will be a part of the model that you create. Fourth, use your core expertise – bring to the role of PerfArch your own expertise in capacity planning, database administration, system architecture, or performance modeling. Programming skills are nice to have but are, largely, secondary in importance. Fifth – be a ‘people person.’ You will work with many people and interpersonal skills are mandatory. The best architect is a failure if he cannot gather the information needed. Sixth – learn the language of architecture – UML. Seventh, you really have to like this type of work; if you find the aforementioned material to be boring and useless then you should look for work elsewhere.
The challenge for PerfArchs as with other Information professionals, is keeping current with the state of technology. The best way to do this is through periodic classes – free ones as well as the paid classes. Read everything in sight, analyze it and re-consider it; make the material that you read work FOR you. When the opportunity is present, jump in with both feet – take the position as PerfArch and do not worry too much about gaps in your skill set – work to repair them. No one has a perfect set of skills – that’s what makes the job so unique – it is challenging all the time and in every way. Professional maturity comes from learning, and if you like to learn, this is one way to provide services to your company and to your customers.
If you would like to submit an article providing an insider’s view of your tech or engineering job, please send your article to us at ITtrenches@dice.com.
Comments on this article? Share your feedback on our discussion forum, Dice Discussions.
*Please note, you must be a registered job seeker in order to submit your question to Dice Discussions.
|
|
|
