2011 2011 NinthNinth Working Working IEEE/IFIP Conference Conference on Software on Software Architecture Architecture

A Supportability Framework
Nagaraju Pappu
Canopus Consulting, Bangalore, India pnr@canopusconsulting.com

Satish Sukumar
Canopus Consulting Bangalore, India satish@canopusconsulting.com

Feroz Sheikh
Canopus Consulting Bangalore, India feroz@canopusconsulting.com

Abstract Stakeholder concerns extend beyond end-user functionality and often go beyond error free operation, fast response times, high throughput, high availability and security. A large set of stakeholder concerns relate to the cost of building, owning and managing an IT-system in terms of quality attributes such as the ease of modifiability, configurability, manageability, usability and maximizing the systems ROI. Consequently, the realization of these quality attributes can be verified by how the system is built rather than what goes into the system. Because of this these quality attributes tend to be ambiguously specified and are hard to verify using conventional QA techniques. This paper presents a Supportability Framework that uncovers and links together concerns of 3 major types of stakeholders and transforms these concerns into a set of features and functionality to be realized in the system to be used by these stakeholders. This is accomplished using supportability scenarios, which use quality attributes as focal points with a specific productivity goal such as optimizing resources, time or money. The degree of realization of each of the quality attributes is described in terms of the conceptual tools of architecture such as use-cases, architecture styles and patterns, platform services and allocation views. The resultant architecture description and features produced by the supportability framework makes it simpler to establish the inherent relationship of the productivity concerns of the organization with respect to the system and their eventual architectural realization as a set of quality attributes. Keywords: Quality attributes, Stakeholder concerns, Software Architecture

I.

INTRODUCTION

The stakeholders of modern enterprise IT-Systems are many and varied. They include not only business, operational and IT-departments and their respective teams but also the organizations that developed and the organizations that manage the IT-System as well as technology and business partners and vendors. Stakeholder concerns span not only the functionality of the system, but also how the system is architected and engineered. Stakeholder concerns can be broadly classified into three categories. There is a class of stakeholder concerns that are verifiable and measurable constraints on the system's functionality. For example throughput, response time, reliability and fault-tolerance are well known concerns that can be measured by observing the runtime behavior of the system. There are well-defined architecture techniques for
978-0-7695-4351-2/11 $26.00 2011 IEEE DOI 10.1109/WICSA.2011.26 137

dealing with these concerns as described in the SEI-CMM Technical Report on Quality Attributes [1] and by Bass et al [2] and Buschmann et al [3]. There is a second class of stakeholder concerns that are related to the effect of the system on the organization, on people and on society in general. A CEO is concerned with the profit the particular product may bring to the organization, a stockholder is concerned with the stock price of the company and its relation to the system, and an enduser is concerned with the privacy of the information and its protection. Similarly the concerns of governments and other social systems fall into this category. This category of stakeholder concerns is similar to the goals stakeholders of the supra-system as defined by Otto Preiss [4] The focus of this paper is yet another class of stakeholder concerns that are related to a stakeholders own productivity with respect to the work done with and for the system. For example, the cost of building and ownership as well as the ease of maintenance and the time, effort and money it takes to make any change to the system are concerns directly related to the productivity and efficiency of the stakeholders with respect to the system's life cycle. In general, these productivity concerns of the stakeholders are related to a particular class of quality attributes of the system such as the modifiability, usability, analyzability, testability, manageability and deployability. Since these quality attributes deal with how the system is built rather than what goes into the system as features and functionality, they are perceived to be 'external' to the system. Consequently, they are often ambiguously specified and cannot be verified and validated in the system using conventional QA methods. The supportability framework presented in this paper makes it possible to specify the degree of realization of each quality attribute as a set of system functionality that are required to support the desired productivity goals of the stakeholders. II. PRODUCTIVITY CONCERNS, QUALITY ATTRIBUTES AND SUPPORTABILITY

Gerrit Muller [5] stated the essence of organizational productivity challenge is to keep the team sizes constant as the complexity of the systems increase exponentially. Though Mullers observations are with in the context of developing complex software, the same argument can be extended to the entire organization, in other words the productivity challenge encompasses not only the making of

the software system, but also the cost of ownership and cost of management and maintenance. There is a strong relationship between the productivity concerns of the stakeholders and the quality attributes of the architecture. For example, in globally used web systems, usability is an important productivity challenge. It is expensive and even impossible to train all users to use the system, therefore compliance with well-established user interface metaphors is a way of productivity improvement. Similarly, interoperability of a product with other systems within the enterprise and across other enterprises leads to lesser staff, faster response times and increases its lifespan. Service Oriented Architectures enable highly configurable, modifiable and extensible systems without extensive reprogramming and re-engineering, reduces time to market and total cost of ownership in the long run. Therefore, the quality attributes such as usability, modifiability, extensibility and configurability stem from productivity challenges and concerns of the stakeholders. This is perhaps the reason why these quality attributes cannot be validated using what is in the system, but can only be verified by watching how the system is built. One of ADDs [2] modifiability scenario statements that the developer must be able to modify a user interface with no side-effects within 2 hours illustrates the productivity relationship of these quality attributes. Martin Glinz [6] pointed out that quantification is not feasible for attributes like usability, modifiability etc. This is because they mean different things to different stakeholders, and there is also a huge variance of their desired degree of realization among the stakeholders. This makes it difficult to capture them unambiguously. Another challenge is that realizing these concerns often leads to several concerns for other stakeholder who build, deliver and manage the system. A modifiability concern like the ability to add new features at a rapid pace is a business differentiator. In order to realize this concern, the development stakeholders would have to provide APIs, interfaces, templates and abilities for continuous integration. Rapid addition of new features using APIs and its consequent continuous integration means that the QA teams will need automated test suites to ensure that new features do not break or introduce errors in existing functionality. The Operations and IT teams need a way to roll out new versions and changes without bringing the service down. The interrelationship between the productivity concerns also leads to interrelated and sometimes conflicting requirements of quality attribute realization. For example, a particular usability improvement may lead to performance degradation. One way to address the above challenges as depicted in Fig-1 is to (a) explicitly link the stakeholder productivity concerns with the quality attributes of the architecture of the system, (b) describe the quality attributes related to the productivity concerns in such a way that they are not only expressed as constraints on existing functionality, but also as a set of concrete functionality in the system specifically meant for the stakeholders with respect to those quality attributes (c) extend the quality attribute realization to encompass not only how the system should be built, but also how the system should be used, operated and managed

by all the stakeholders involved. In other words, the system should have specific support for each stakeholder and her productivity concerns. The degree of this support establishes the realization of the degree of the quality attributes such as modifiability, usability, manageability, testability etc. Therefore the heart of supportability lies in converting all stakeholders into 'active users' of the system. From an architecture standpoint, the system must provide features not only for end users, but also for all stakeholder groups. Intuitively, the supportability framework involves asking a simple question to all stakeholders - "if you were to use the system to do your daily work better and accomplish your goals in relation to the system functions you own, what features would you want for yourself?" This is very different from including the business-user as an actor in a functional flow of a use case. This distinction is important from a supportability framework point of view because there is a strong relationship between the scale and complexity of the system and the organizational work involved in managing, supporting and maintaining it. A system that is used by a million users requires a different order of magnitude of organizational work as compared to a system that is used by a few hundred users. The administration and management of the system would have to be considered as a first-class functionality in itself. The organizational work (or its productivity) is a function of one of the following three: resources (the number of people), effort (how much work by an employee) and the money (technology, tools, partnerships etc.). All three are 'affected' as the scale of the system increases significantly. The organizational work which influences its productivity is of various kinds - management related work, administrative work, daily and periodic work, business reporting and analytics to manage risk, the IT-System management which involves keeping a large data-center up-to-date, secure and reliable, and constant development work which includes adding and upgrading the under-the-hood functionality of the system. Supportability brings the above relationship into focus by making the organizational productivity in relation to the size and complexity of the system. The transformation involves the following: a) Specify the functionality of the system for supportability -- by making each stakeholder an active, first-class user of the system and building features for them. b) Constructing productivity scenarios for the organizational work required to build, operate and manage the system, and relate this org-work to the quality attributes of modifiability, analyzability, deployability and usability. From a supportability perspective, the stakeholders belong to three distinct dimensions people from business functions such as product or account managers belong to the first dimension. These are people who are sponsors and users of the system within the organization. They are the owners of the system.

138

Figure 1. The supportability framework

The IT-Administrators including system and data center administrators or help-desk staff who manage and maintain the system belong to the second dimension. These stakeholders own the systems day-to-day management, and the people who develop and maintain the system belong to the third dimension. This classification makes it possible to extend the supportability and the quality attribute realization to all three areas of productivity concerns which can be measured in terms of effort, time and resources to own, operate and build the system. Essentially, the supportability framework is used to produce a set of supportability features. These features constitute the under the hood functionality that is otherwise hard to capture in a typical end-user focused architecture analysis. These features establish the relationship between the productivity concerns of the stakeholders and the quality attributes of the system. Any existing architecture description such as use-cases, component interfaces etc., are enhanced and modified accordingly. The supportability framework is an architecture framework as defined in ISO 42010 [11] that focuses specifically on the productivity concerns of the three stakeholder categories mentioned earlier. The method of applying the supportability framework is described along with a case study in the following sections. III. THE SUPPORTABILITY SCENARIOS Scenarios are used to frame two variables in a particular context. An example scenario would be to observe the effect of the size of data in the database to the response times of a particular query, by fixing the rest of the environment constant during the execution of the scenario. Scenario based techniques are used in Software Architecture Design. Bass et al [2] popularized scenario based methods to frame quality attributes in their Attribute Driven Design method. The Supportability Framework presented in this section is similar to the ADDs scenario method. Figure 2 illustrates the various aspects of the supportability framework.

A. Supportability scenario dimensions The supportability scenarios are used to frame a particular productivity concern of a stakeholder, a department or an organizational unit. The stakeholder categories as mentioned earlier include business, IT-Administration and development stakeholders. The context of the concerns is always a particular aspect or area of functionality of the system. Productivity is measured in terms of resources, money or time. For example, if we consider a large scale Email Service, it is an important productivity concern to be able to manage thousands of corporate Email customers with a small staff, as the cost of human resources is always the highest in a system's management life cycle. Consequently, the supportability scenarios seek to optimize a particular productivity concern. The second dimension consist of the quality attributes: Modifiability refers to the ability to make changes to a software system with minimal effort and impact on the rest of the system. ISO 9126 [7] and Pattern Oriented Software Architecture (POSA) [3] use the term changeability with a similar definition. POSA identifies maintainability (fix defects or repair a software system), extensibility (extend the functionality), restructuring (re-organization of the components of the system most often due to refactoring) and portability (adapting the system to operate on different hardware or software platforms) as four aspects of changeability/modifiability. Configurability (modify the behavior or structure of the system at run-time using configuration information) is also an important aspect of modifiability. Usability is a measure of how much effort it takes for the target users to learn to interact comfortably the systems functionality. Bass [2] identifies learning system features, using a system efficiently, minimizing the impact of errors, adapting the system to user needs and increasing confidence and satisfaction of users as important characteristics of usability. Analyzability as defined by ISO 9126 refers to the systems ability to be diagnosed for deficiencies, causes of failure or identifying parts that need to be replaced. However in systems governed by operating practices such as ITIL, analyzability also extends to providing information about service usage, user behavior, demand and capacity, resource consumption, run-time behavior and errors. Diagnosability and debuggability are frequently used to mean analyzability. Testability refers to the ease with which the software can be made to demonstrate its fault through testing, in other words the capabilities within the software that support testing such as the ability to test parts of the system in isolation, to control the internal state of components and to observe the outputs of the components. Deployability refers to the ease with which the software system can be installed or deployed in a specified environment. In many systems today, deployability also requires software to be installed without a break in services. ISO 9126 refers to deployability as installability.

139

Manageability refers to the ease with which the software system supports operational support tasks such as resource management, archival, pruning log files, backup of data etc. B. Conceptual tools of architecture The quality attributes are used as the focal point to transform the stakeholder productivity concerns into system features. In order to accomplish this, the supportability scenarios use the conceptual tools of the architecture used in architecture design. These conceptual tools are broadly categorized as Use-cases which are used to decompose and represent functionality Architecture styles, patterns, principles and tactics which play a crucial role in the design of architecture The structural elements of architecture like component models, Service Oriented Architecture Frameworks, aspect oriented programming facilities etc. The underlying platform services such as services offered by J2EE, .NET and so forth Allocation aspects of architecture like infrastructure deployment and allocation of development to teams Any quality attribute realization as well as realization of any system functionality can only be done using the above conceptual tools.

Since supportability involves making organizational stakeholders as active and primary users and its goal is to relate the degree of realization of quality attributes to the productivity goals, it results in modifications of the architecture of the system using the above conceptual tools. The supportability scenarios dealing with configurability tend to optimize the resources required to support business and IT Operations. This leads to creating new use cases with these stakeholders as primary actors, and produces extensions to component interfaces in order to support different behaviors based on configuration settings. Similarly extensibility scenarios typically require architecture patterns that support generalization such as plugin or microkernel patterns with existing component interfaces modified to behave as extension points. Likewise, analyzability scenarios require modifications to existing use cases to generate metrics about number of requests, usage patterns, classification of errors. Analyzability also leads to the definition of new use cases that describe dashboards for various stakeholders to support their planning and diagnostic work. Testability and deployability lead to modifications of component structures so that parts of the system can be decoupled and installed or run independently or additional tools for diagnosis or monitoring be added, debug levels set etc. These attributes are also supported by platform services such as instrumentation and management, aspect orientation and resource management.

Figure 2. Representation of the supportability framework

140

3. 4. 5.

6.

Figure 3. Under the Hood Complexity of a large scale email-system

uncovering process is using the functional and nonfunctional requirements of the system as an input, identify specific work done by the stakeholder that is impacted as the system scales. Describe the specific productivity scenario for the stakeholder as a statement of the time, effort or resources to be optimized Analyze the scenario using the quality attributes to identify the features required to realize the desired optimization Describe features of the system using the conceptual tools of architecture modifications or additions to use cases, architecture patterns, styles and decisions, components and their interfaces, deployment decisions and so on Add the features back to the original set of requirements prior to the analysis of the next stakeholder concern. The features used to realize the productivity concerns of one stakeholder tend to impact the work to be done by other stakeholders. Adding them back to the requirements that is the input to the scenarios serves to bring out these dependencies. APPLICATION OF THE SUPPORTABILITY FRAMEWORK

In essence, on one hand the supportability scenario takes a particular stakeholder's productivity concern as an optimization of resources, money and time and on the other hand it uses the quality attributes and the conceptual tools of architecture to specify what changes and additions are done to the system to provide supportability related features as well as what changes and additions are done to the system's structure. The elements of a supportability scenario are: The dimensions: The productivity concern of a particular stakeholder, department or organizational entity. Quality Attributes such as modifiability, testability, analyzability, usability and deployability. The environment: Productivity Context, which is used to relate the stakeholder's productivity concern to a particular aspect or functionality of the system and what productivity measurement variables to be optimized The conceptual tools of architecture - use-cases, styles, patterns, structural elements, platform services and allocation views. The process of applying the supportability framework is as follows: 1. Identify stakeholders whose productivity concerns must be addressed. The key is to look for stakeholders whose work is some ways affected by the system. 2. Identify the stakeholders functions that are impacted by the addition of the new system. As the system scales, the stakeholder will have to expend more effort, time and resources to accomplish work associated with these functions. The prominent question used in the

IV.

In this section, the framework is illustrated with the example of a large-scale email system. The particular example is chosen because email and email applications are functionally and are universally used and therefore the supportability aspects can be illustrated without focusing too much on the domain aspects. As depicted in Fig-3, end user functionality related to sending, receiving and reading email is more or less the same across all email applications irrespective of whether the application is designed to support a small set of users or whether the system is a globally operated large scale service supporting millions of users. However real complexity lies in the "functionality" designed for their scale including geographically spread servers, automatically optimizing disk quotas, spam detection etc. In this section, the under-thehood functionality is enumerated using supportability scenarios. I-Mail offers free and premium email services to individuals and corporate organizations globally. I-Mail expects to grow to over 2 million customers over four years, provide local language email across geographies and support a large number of configurable services. I-Mail is a 40person organization with a 5-person product/account management team, 6 people dedicated to IT operations, 4 to QA and testing and a 10-person software development team. The rest of the people belong to sales, finance, HR and senior management. End user customer support is outsourced. I-Mails architecture primarily uses an MVC pattern, and its important components are illustrated in Figure 4.

141

Figure 4. I-Mail system components

The user interface components for web, POP3 and WAP clients form the views, the bridge and the Programmable Enterprise Integrator (PEI) serve as the controller and messages, folders, users, mailboxes etc. are the model elements exposed by XMAP and the user profile management agent (UPMA). Components that manage user profiles, mail data, sending and receiving emails and administration are decoupled and communicate via a message based integration bus coordinated by the PEI. IMail uses data center hosted Intel based servers running Linux and multiple network attached storage units. I-Mail requires the average cost per mailbox to be less than 1USD per year to ensure profitability of the business. The two primary constituents of this cost are people and IT infrastructure. The analysis presented below assumes that IMails people and technology costs are already close to the 1 USD per mailbox limit. The supportability scenarios analyzed relate to what I-Mail requires to do to ensure that it can continue to scale its user base and operations with little increase in either headcount or IT infrastructure. The details of the analysis for the configurability, extensibility and manageability quality attributes is presented below. A. Supportability scenario for configurability Scenario: Reduce the effort required to configure and manage corporate email accounts Stakeholder: corporate email account manager (business stakeholder domain) Stakeholder Function and analysis of work to be done: Account managers have to perform several activities as part of the administrative work to setup and manage email accounts including: Setting up new corporate customer accounts including setting custom domain names, setting up billing related information, customizing the user interface etc. Managing corporate accounts including setting up user accounts, creating mailboxes, user profile, password and rights management, backing up mailbox data, allocating additional storage, making change to billing plans In addition, account managers depend on IT teams to setup the virtual hosts and domain name support, to

physically allocate the account to servers and storage and to add additional storage. Productivity concern: As the number of I-Mail corporate accounts increase, the volume of administrative work increases. Current estimates indicate that a team of 4-5 people supported by an equal number of IT resources can handle 5000 mailboxes, but I-Mail will soon grow beyond this number. The concern is thus to reduce the effort required in setting up and managing these accounts so that the same team can handle a significantly larger number of accounts. Quality attribute: This is a configurability problem because account managers require to "program" the tasks related to account management by themselves so as to reduce the effort and time taken to perform these tasks and eliminate dependencies on other teams Supportability scenario analysis and features produced: A simple configuration tool to setup and manage accounts that reduces the manual effort involved in creating the account by automating all the background tasks is required. An account manger now uses this tool to setup and configure the account in terms of themes, multi-protocol access, users, billing plans, storage required and so on. To provide configurability at the business user level, the email system required the following: 1. Use cases: The use cases describing account, user creation and mailbox creation scenarios were modified to support selection of a pre-configured template and to support bulk uploading of user details in a delimited file. New use cases with the account manager as the actor were defined to describe the configuration related functionality and related workflows. Since most of the activities are now automated background tasks, a dashboard for account managers to monitor the status of these tasks is also required. 2. Components and interfaces: a. Additions to the database schema to support pre-defined configuration templates is required. This reduced the amount of data entry required at configuration time via pre-filled in data. b. Enabling a custom domain name required identifying a cluster of servers that would serve the account, the creation of new virtual hosts in the web servers and adding new DNS records that pointed to these servers. These are modifiability related tasks normally done by IT administrators using scripts, but again the scale precludes manual activity related to executing these scripts. The logic within the scripts is instead implemented as services provided by some of the major components such as the Universal Management Console. c. Services exposed by the UPMA were modified to support bulk creation of user accounts and mailboxes d. The UMC was modified to call provisioning programs that automated tasks such as allocation of new mailboxes to a cluster of servers based on a load distribution algorithm

142

and allocation of required storage to these mailboxes. e. The orchestration of the tasks was accomplished by introducing additional query coordination logic into the programmable enterprise integrator components. 3. Allocation decisions: The functionality related to setting up and managing accounts includes many batch operations. A separate instance of the application with the components required to support these operations was created to execute these tasks without impacting the performance of the email system. Impact on other stakeholders: Configurable provisioning of new accounts requires server and storage capacity to be pre-available. This has an impact on the capacity planning work done by IT operations teams. This is addressed by generating metadata as part of the configuration tools that allows the IT ops teams to track metrics such as the rate at which new accounts are added, the number of mailboxes that are provisioned and the rate at which storage and server capacity is being allocated. Summary: New supportability features include a account configuration tool, bulk upload functionality for account creation, configuration templates and programmatic creation of virtual hosts and new domains. Each of these features is verifiable using functional test cases. These features are supported by new services that orchestrate and automate various administrative tasks that eliminated all dependencies on the IT operations teams. Together this reduced the effort involved in setting up and managing email accounts. In the future, I-Mail plans to make this tool directly available to users from these accounts. This degree of configurability will enable I-Mail to scale the number of accounts to be supported without needing to increase the headcount of the account management team thereby accomplishing the business goal. B. Supportability scenario for extensibility Scenario: Reduce the effort and time required to add new email features and functionality Stakeholder: Product management teams (business stakeholders) and development teams Stakeholder function and analysis of work to be done: Providing new email features are an important part of IMails strategy to differentiate it from its competitors. Some of these features include multi-language support to compose and send local language mail, attachment preview functionality, mobile phone integration, calendar integration and to-do list creation from email, import and export of contacts, emails and attachments from existing mail software and standards based single sign-on and widget support to plug-in to other portal sites The process of addition of a new feature includes requirement definition, design - including changes required to the existing system, developing the new feature, making modifications to the existing system to integrate the new feature, testing the feature with the rest of the system and then deploying the changes into the production environment without causing a service downtime.

Productivity concern: With new features requiring modifications to the existing system, the dependencies amongst features has to be carefully planned and extensive integration and testing effort is required. Therefore the estimated effort for feature addition is in the order of person months and features can be released only as part of planned larger releases typically once a quarter. The key concern for product management is to reduce the effort required to add most new features to two person weeks and enable new features to be released every fortnight. This will enable the required rate of features to be added without increasing the headcount in the development and QA teams. Quality attribute: A considerable portion of the effort required to add new features relates to making modifications to the existing system to integrate the new feature and to then test and validate the integrated feature set. Designing the system for extensibility will enable most new features to be "plugged-in" with minimal impact on the existing system. Supportability scenario analysis and features produced: Feature extensibility while minimizing the impact on the existing system is accomplished by adopting a plug-in based model. A feature developer is required to wrap the functionality provided in a pluggable component that is then loaded into the email system. The new plugin component adds processing elements to existing core email services and also to other plugins thereby increasing the functionality provided by the system. An example of such a plugin is an attachment format converter that converts a variety of binary file formats to a SVG format for preview. The new process defined for feature development consisted of developing feature using the APIs provided by I-Mail, uploading the code and test cases for the feature to a staging area, the testing and validation of the feature by the QA team and its release into the production environment. To support extensibility, the email system required the following: 1. Use cases: A feature developer now becomes an actor in a new use case that describes a user interface driven mechanism to upload the code with test cases and track its progress through QA. The basic assumption of the plug-in model of extensibility is that existing functionality is not impacted; existing use cases therefore did not require to be modified. 2. Architecture patterns a. The architecture patterns used to support extensibility are based on the Microkernel pattern [8] and the plugin design patterns. The microkernel encapsulates infrastructure functionality related to storage, resource management, accessing mailboxes and the sending and receiving emails. The microkernel defined a series of APIs for the plugins to leverage via the query coordinators implemented in the PEI. Plugins in turn implemented callback functions that are invoked during method execution by the PEI and the Bridge components. 3. Components and interfaces

143

Existing component services were organized into externally callable APIs b. User interface components were made composable to enable a plugin to interact with users through existing interfaces 4. Platform services: Platform services were used provide a repository to register plugins, mechanisms to dynamically load or unload a plugin, and a hook and event framework to implement the callback functionality 5. Allocation decisions: A continuous integration tool is used to automate the process of integrating approved plugins with the rest of the environment to create new builds on a frequent basis. Impact on other stakeholders: Enhancing the rate of feature development potentially meant more testing and QA work. This was simplified by the introduction of an automated test suite that ran a set of core and developer provided unit test cases automatically when a new plugin was added. Summary: The extensibility scenario resulted in features for plugin developers including tools to upload, register and automatically test a new plugin. These were in turn supported by a set of APIs. The functionality of the APIs and the features are verifiable by testing. The plugin based development model and the automation provided to load and test plugin functionality reduces the work required to modify the system and to test integrated functionality. Most new email features can be added and released in within the 2week period without breaking existing functionality. This enabled I-Mail to increase the rate of feature development without an increase in head count and to partner with external product vendors to make extensions to the email system on a revenue sharing basis. C. Supportability scenario for manageability Scenario: Optimize the return on investment on resources such as storage as the scale of the email system increases Stakeholder: IT operations teams Stakeholder functions and analysis of work to be done: IT operations teams require planning and augmenting the storage capacity available so that new accounts are provided with appropriate storage space. Productivity concern: Cost of storage is a significant component of I-Mails IT spend. At 2 GB per mailbox and 30,000 new mailboxes a month, I-Mail would potentially need to add 60TB of storage a month. However, the cost of adding such capacity is much higher than the revenue earned from the additional users. Therefore, optimizing the use of the storage space is an important concern. Quality attribute: Manageability - optimizing storage capacity requires the automatic management of available storage by allocating only what is required and retrieving unused storage. Supportability scenario analysis and features produced: Though I-Mail offers 2 GB storage per mailbox, most mailboxes remain well below that number at around 40-50

a.

megabytes even after a few years. Therefore, when a new mailbox is created all 2 GB need not be allocated only a few MB needs to be allocated. As a user mailbox size increases, additional capacity is dynamically allocated. Secondly, on an average there are 6-7% of the total mailboxes that become inactive. The space allocated to them should be retrieved and added to available storage. Both allocation and retrieval of storage space are continuous operations that span the email system and must be done automatically. To support these operations, metrics on the average size of a mailbox is required to plan the initial space allocation. In addition mailboxes that are approaching the limit of allocated space must be identified to automatically allocate more space to them and inactive mailboxes must be identified to retrieve storage space. To support the management of storage, the email system requires the following: 1. Use cases: The email functional use cases related to user sessions, manage mailboxes, and read/compose emails were augmented to generate additional information on mailbox sizes, mailbox growth rate, last usage time, and frequency of usage. New use cases with the IT operations stakeholder as the actor were defined. This use case defined the operations of a dashboard that displayed the metrics and also the status of storage allocation and the automatic allocation and retrieval tasks. 2. Architecture patterns: Observer patterns and dependency injection were employed to dynamically add new metrics to be gathered 3. Components and interfaces: a. The services exposed by the UPMA, XMAP and UMC components were modified to provide metrics about average mailbox sizes, and mailboxes that required additional storage allocation b. The storage layer components were modified to allocate fixed blocks of storage to mailboxes based on configurable settings c. A batch program run once a day by the UMC automatically identified accounts not accessed for over three months and flagged them as inactive, moved their data to offline storage and freed up disk space to the common pool for allocation 4. Platform services: Management extensions provided by the underlying platform were used to publish metric related data to the dashboards and enterprise management tools. Impact on other stakeholders: Customer support teams occasionally need to identify inactive accounts and restore them to an active status and make their data available again. To support this, the location of the archived data is stored as part of the customer account data. Summary: By implementing the features for automated management of storage, I-Mail now needs to add only around 3 TB a month. The manageability features related to automatic storage allocation and retrieval are also verified using test cases.

144

D. Tradeoff analysis and Architectural Decisions One advantage of the supportability framework is that as more quality attributes and stakeholders from across the organizational divisions and their productivity concerns are included, the architectural complexity of the system becomes self evident in simple functional terms to all the stakeholders involved. The ability to enumerate under-the-hood complexity in functional terms makes it easy to make build vs. buy decisions as well as planning incremental feature releases. In most cases, there is also a certain degree of precedence of functionality of the system that can be obtained as result of the supportability analysis. For example, it is possible to articulate to and convince all I-Mail stakeholders that it is important to first build extensibility features and programmability such as APIs as a prerequisite for providing configurability at a business user level as illustrated in the first scenario. Similarly programmatic control of I-Mail services and the ability to run multiple load-balanced instances of services is a pre-requisite for staged deployment. Stakeholder groups and architecture decisions: Business stakeholders typically come from all organizational groups and divisions that are concerned directly with the operation of the core business services such as marketing, sales, product management and operations. In many systems including I-Mail, business support functions such as HR are not directly concerned, as their functions are not impacted by the system. On the other hand business support functions such as finance are highly automated and require integration of customer and billing information with the core financial management systems. Among the business stakeholders, typically there is a classification of type of work. For example, I-Mail has senior management roles, middle management roles, and clerical or operational roles in each business function. Irrespective of the type of the organization, and scale of the organization, the productivity concerns have some relation to the role of a stakeholder or the organizational groups. Consequently, for each type of business function, on an average there are two/three productivity concerns (senior management, middle management, operational) and related feature groups. In the IMail case a total of 14 stakeholders led to 40 scenarios. Build Vs. Buy Decisions: Such grouping of stakeholder concerns by their functions is useful in making certain build vs. buy decisions. For example, the analyzability concerns associated with I-Mails business users requires providing business analytics and configurable reporting. This functionality is not very specific to I-Mail and is used by a small set of users and so can be accomplished using a generic COTS based solutions instead of custom developing it. This saves both development effort and time. However this buy decision meant providing an asynchronous publish/subscribe mechanism to export the data generated as part of user operations to the database used by the analysis tool. It is also well known that reporting requirements evolve over time, so a means of extending the data captured as part of user operations is required and was implemented as

programmable aspects. Similarly, the manageability concerns of operational stakeholders using ITIL based processes are standard and thus remote management of the IMail is accomplished via integration with commercial enterprise management applications. The supportability framework helps in enumerating the features and functionality required from such COTS systems, their need and justification of their cost-benefit analysis. Many supportability features are not specific to an application or a system, but are specific to a particular stakeholder community. Therefore, it is possible to build reusable frameworks, models and components and use them across many systems. However there is also a large set of supportability functionality that is either specific to the system, stakeholder and organization such as the email product configuration interface; that requires modification to existing use cases such as gathering analyzability data from user operations or functionality directly used by end-users which would require very large number of licenses. In each of these cases COTS based solutions are not feasible or may become too expensive because of exponential license costs. In such cases, the supportability framework is used to enhance the existing business use-cases as illustrated in the configurability scenario enhance or even re-design the usecases keeping the productivity goal such as maintaining a specific ratio of number of employees to the amount of work to be done. Supportability Scenarios and Quality Attributes: The features and structural changes required have an impact on the realization of other quality attributes including throughput, response times and availability. For example, a decision to provide end-user configurability of the user interface requires the user specific page elements to be retrieved and interpreted at run-time and this has an adverse impact on the page loading time. In I-Mail both page load times and individual-user configurability were deemed to be equally critical so the page caching strategy had to be revisited to handle both the common and the user specific page elements. V. CONCLUSIONS In our experience, one of the best by-products of the application of supportability framework is that either the stakeholders reduce their desire for highly flexible, configurable and extensible systems or it leads to a better appreciation of the quality attributes. The use of the supportability framework leads to the following benefits: 1. It bridges the gap between an ambiguous productivity concern of a stakeholder and one or more quality attributes of the system that are required to address the concern. 2. Since the productivity concerns are realized as features and there is clear traceability between a concern and the feature, the validation of if the productivity concern has been addressed in the system is now transformed to validating if the feature has been realized.

145

3.

The question of how much of a quality attribute such as modifiability is required in a system is now determined from stakeholders productivity concerns that in turn are driven by business goals. Instead of an ad-hoc quantification, the features now become verifiable using QA. Secondly, the degree to which the quality attribute has to be realized is justifiable against the business goals of the system. 4. It enables the dependencies between stakeholders requirements to emerge as a natural consequence of the method. 5. The degree of realization of the quality attributes, and the reason for making certain architectural choices are clearly captured using the architecture design techniques such as use-cases, architecture styles and patterns, platform services and allocation views. Supportability makes it easier to communicate the complexity of architecture in business and functional terms. More importantly, it makes the connection between the scale of the system and the scale of the organization as a systematic and methodological architecture analysis work. As presented in the case study, there appears to be a strong relationship between specific quality attributes and architecture design choices, for example analyzability almost always leads to enhancing, augmenting the existing information model of a system with new entities. Extensibility requires generalization schemes that transform a specific domain model into a computing model. This is to be investigated further. The supportability scenarios presented in this paper describe the supportability functionality in terms of additions, changes and modifications to the existing functional use-cases, architecture styles and patterns, platform services and allocation. This approach is analogous to 4+1 view [9] and the method proposed is similar to bringing architecture patterns within the MDA framework as presented by Daniel Perovich et al[10] The supportability framework works well with stakeholders who have operational jobs. Even though it is useful in other stakeholder groups like auditors, external partners and vendors to some extent it may not produce very precise drill drown of their concerns. Certain quality attributes such as security cannot be captured purely using the supportability framework alone. Security mostly translates as constraint on functionality, which includes the supportability related functionality as well. Similarly, reliability is both a constraint on functionality and also can be a productivity concern. We need to extend the supportability framework to include stakeholder concerns that span both functional as well as productivity related concerns.

REFERENCES
[1] Barbacci, Mario, et al., Technical Report - Quality Attributes. s.l. : Software Engineering Institute, 1995. [2] Bass, Len, et al., "Understanding Quality Attributes." [book auth.] Len Bass, Paul Clements and Rick Kazman. Software Architecture in Practice - Second Edition. s.l. : Pearson Education, pp. 75-98. [3] Buschmann, Meunier, et al., "Non-functional Properties of Software Architecture."[book auth.]Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sornmerlad and Michael Stal. Pattern-Oriented Software Architecture - A System of Patterns.: John Wiley and Sons, pp. 404-410. [4] Preiss, Otto and Wegmann, Alain., "Stakeholder Discovery and Classification Based on Systems Science Principles." s.l. : IEEE Computer Society, 2001. Second Asia-Pacific Conference on Quality Software. [5] Muller, Gerrit., "The Importance of System Architecting for Development." www.gaudisite.nl. [Online] http://www.gaudisite.nl/ImportanceOfSAforDevelopmentSlides.pdf. [6] Glinz, Martin., "A Risk-Based, Value-Oriented Approach to Quality Requirements." IEEE Software. March/April 2008, pp. 34-41. [7] "ISO/IEC 9126-1: Software Engineering Product Quality Part 1: Quality Model." s.l. : International Organization for Standardization, 2001. [8] Buschmann, Henney, et al., "Microkernel."[book auth.]Frank Buschmann, Kevlin Henney, Douglas C Schmidt. Pattern-Oriented Software Architecture - A Pattern Language for Distributed Computing.: John Wiley and Sons, pp. 194-197. [9] Kruchten, Philippe., "Architectural BlueprintsThe 4+1 View." IEEE Software. November 1995, Vol. 12, 6, pp. 42-50. [10] Perovich, Daniel, Bastarrica, Maria Cecilia and Rojas, Cristian., "Model-Driven approach to Software Architecture design." s.l. : IEEE Computer Society, Washington, DC, USA, 2009. Proceedings of the 2009 ICSE Workshop on Sharing and Reusing Architectural Knowledge. pp. 1-8. [11] "Recommended Practice for Architectural Description of SoftwareIntensive Systems." ISO-Architecture.org. [Online] http://www.isoarchitecture.org/ieee-1471/docs/ISO-IEC-FCD-42010-v27.pdf. ANSI/IEEE Std 1471 :: ISO/IEC 42010.

146