A Supportability Framework

7/28/2019 A Supportability Framework

1/10

A Supportability Framework

Nagaraju Pappu

Canopus Consulting,Bangalore, India

[email protected]

Satish Sukumar

Canopus ConsultingBangalore, India

[email protected]

Feroz Sheikh

Canopus ConsultingBangalore, India

[email protected]

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 thesupportability 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. INTRODUCTIONThe stakeholders of modern enterprise IT-Systems are

many and varied. They include not only business,operational and IT-departments and their respective teamsbut also the organizations that developed and the

organizations that manage the IT-System as well astechnology and business partners and vendors. Stakeholderconcerns span not only the functionality of the system, butalso how the system is architected and engineered.

Stakeholder concerns can be broadly classified into threecategories. There is a class of stakeholder concerns that areverifiable and measurable constraints on the system'sfunctionality. For example throughput, response time,reliability and fault-tolerance are well known concerns thatcan be measured by observing the runtime behavior of thesystem. There are well-defined architecture techniques for

dealing with these concerns as described in the SEI-CMMTechnical 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 arerelated to the effect of the system on the organization, onpeople and on society in general. A CEO is concerned withthe profit the particular product may bring to theorganization, a stockholder is concerned with the stock priceof the company and its relation to the system, and an end-

user is concerned with the privacy of the information and itsprotection. Similarly the concerns of governments and othersocial systems fall into this category. This category ofstakeholder concerns is similar to the goals stakeholders ofthe supra-system as defined by Otto Preiss [4]

The focus of this paper is yet another class of stakeholderconcerns that are related to a stakeholders own productivitywith respect to the work done with and for the system. Forexample, the cost of building and ownership as well as theease of maintenance and the time, effort and money it takesto make any change to the system are concerns directlyrelated to the productivity and efficiency of the stakeholderswith respect to the system's life cycle.

In general, these productivity concerns of the

stakeholders are related to a particular class of qualityattributes of the system such as the modifiability, usability,analyzability, testability, manageability and deployability.Since these quality attributes deal with how the system isbuilt rather than what goes into the system as features andfunctionality, they are perceived to be 'external' to thesystem. Consequently, they are often ambiguously specifiedand cannot be verified and validated in the system usingconventional QA methods.

The supportability framework presented in this papermakes it possible to specify the degree of realization of eachquality attribute as a set of system functionality that arerequired to support the desired productivity goals of thestakeholders.

II. PRODUCTIVITY CONCERNS,QUALITY ATTRIBUTESAND SUPPORTABILITY

Gerrit Muller [5] stated the essence of organizationalproductivity challenge is to keep the team sizes constant asthe complexity of the systems increase exponentially.Though Mullers observations are with in the context ofdeveloping complex software, the same argument can beextended to the entire organization, in other words theproductivity challenge encompasses not only the making of

2011 Ninth Working Conference on Software Architecture

978-0-7695-4351-2/11 $26.00 2011 IEEE

DOI 10.1109/WICSA.2011.26

137

2011 Ninth Working IEEE/IFIP Conference on Software Architecture

978-0-7695-4351-2/11 $26.00 2011 IEEE

DOI 10.1109/WICSA.2011.26

137


2/10

the software system, but also the cost of ownership and costof management and maintenance.

There is a strong relationship between the productivityconcerns of the stakeholders and the quality attributes of thearchitecture. For example, in globally used web systems,usability is an important productivity challenge. It isexpensive and even impossible to train all users to use the

system, therefore compliance with well-established userinterface metaphors is a way of productivity improvement.Similarly, interoperability of a product with other systemswithin the enterprise and across other enterprises leads tolesser staff, faster response times and increases its lifespan.Service Oriented Architectures enable highly configurable,modifiable and extensible systems without extensive re-programming and re-engineering, reduces time to market andtotal cost of ownership in the long run. Therefore, the qualityattributes such as usability, modifiability, extensibility andconfigurability stem from productivity challenges andconcerns of the stakeholders. This is perhaps the reason whythese quality attributes cannot be validated using what is inthe system, but can only be verified by watching how the

system is built. One of ADDs [2] modifiability scenariostatements that the developer must be able to modify a userinterface with no side-effects within 2 hours illustrates theproductivity relationship of these quality attributes.

Martin Glinz [6] pointed out that quantification is notfeasible for attributes like usability, modifiability etc. This isbecause they mean different things to different stakeholders,and there is also a huge variance of their desired degree ofrealization among the stakeholders. This makes it difficult tocapture them unambiguously.

Another challenge is that realizing these concerns oftenleads to several concerns for other stakeholder who build,deliver and manage the system. A modifiability concern likethe ability to add new features at a rapid pace is a business

differentiator. In order to realize this concern, thedevelopment stakeholders would have to provide APIs,interfaces, templates and abilities for continuous integration.Rapid addition of new features using APIs and itsconsequent continuous integration means that the QA teamswill need automated test suites to ensure that new features donot break or introduce errors in existing functionality. TheOperations and IT teams need a way to roll out new versionsand changes without bringing the service down. Theinterrelationship between the productivity concerns alsoleads to interrelated and sometimes conflicting requirementsof quality attribute realization. For example, a particularusability 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 productivityconcerns with the quality attributes of the architecture of thesystem, (b) describe the quality attributes related to theproductivity concerns in such a way that they are not onlyexpressed as constraints on existing functionality, but also asa set of concrete functionality in the system specificallymeant for the stakeholders with respect to those qualityattributes (c) extend the quality attribute realization toencompass not only how the system should be built, butalso how the system should be used, operated and managed

by all the stakeholders involved. In other words, the systemshould have specific support for each stakeholder and herproductivity concerns. The degree of this support establishesthe realization of the degree of the quality attributes such asmodifiability, usability, manageability, testability etc.

Therefore the heart of supportability lies in converting allstakeholders into 'active users' of the system. From an

architecture standpoint, the system must provide features notonly for end users, but also for all stakeholder groups.Intuitively, the supportability framework involves asking asimple question to all stakeholders - "if you were to use thesystem to do your daily work better and accomplish yourgoals in relation to the system functions you own, whatfeatures would you want for yourself?"

This is very different from including the business-user asan actor in a functional flow of a use case. This distinction isimportant from a supportability framework point of viewbecause there is a strong relationship between the scale andcomplexity of the system and the organizational workinvolved in managing, supporting and maintaining it.

A system that is used by a million users requires a

different order of magnitude of organizational work ascompared to a system that is used by a few hundred users.The administration and management of the system wouldhave to be considered as a first-class functionality in itself.The organizational work (or its productivity) is a function ofone 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. Theorganizational work which influences its productivity is ofvarious kinds - management related work, administrativework, daily and periodic work, business reporting andanalytics to manage risk, the IT-System management whichinvolves keeping a large data-center up-to-date, secure and

reliable, and constant development work which includesadding and upgrading the under-the-hood functionality of thesystem.

Supportability brings the above relationship into focus bymaking the organizational productivity in relation to the sizeand complexity of the system. The transformation involvesthe following:

a) Specify the functionality of the system forsupportability -- by making each stakeholder an

active, first-class user of the system and building

features for them.

b) Constructing productivity scenarios for theorganizational 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 stakeholdersbelong to three distinct dimensions people from businessfunctions such as product or account managers belong to thefirst dimension. These are people who are sponsors and usersof the system within the organization. They are the owners ofthe system.

138138


3/10

Figure 1. The supportability framework

The IT-Administrators including system and data centeradministrators or help-desk staff who manage and maintainthe system belong to the second dimension. Thesestakeholders own the systems day-to-day management, andthe people who develop and maintain the system belong tothe third dimension.

This classification makes it possible to extend thesupportability and the quality attribute realization to all threeareas of productivity concerns which can be measured interms of effort, time and resources to own, operate and buildthe system.

Essentially, the supportability framework is used toproduce a set of supportability features. These featuresconstitute the under the hood functionality that isotherwise hard to capture in a typical end-user focusedarchitecture analysis. These features establish therelationship between the productivity concerns of thestakeholders and the quality attributes of the system. Anyexisting architecture description such as use-cases,component interfaces etc., are enhanced and modifiedaccordingly.

The supportability framework is an architectureframework as defined in ISO 42010 [11] that focusesspecifically on the productivity concerns of the threestakeholder categories mentioned earlier. The method ofapplying the supportability framework is described alongwith a case study in the following sections.

III. THE SUPPORTABILITY SCENARIOSScenarios 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 SoftwareArchitecture 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 thesupportability framework.

A. Supportability scenario dimensionsThe supportability scenarios are used to frame a particular

productivity concern of a stakeholder, a department or anorganizational 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 thesystem.Productivity is measured in terms of resources, money or

time. For example, if we consider a large scale EmailService, it is an important productivity concern to be able tomanage thousands of corporate Email customers with a smallstaff, as the cost of human resources is always the highest ina system's management life cycle. Consequently, thesupportability scenarios seek to optimize a particularproductivity 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 restof the system. ISO 9126 [7] and Pattern Oriented SoftwareArchitecture (POSA) [3] use the term changeability with asimilar definition. POSA identifies maintainability (fixdefects or repair a software system), extensibility (extend thefunctionality), restructuring (re-organization of thecomponents of the system most often due to refactoring) andportability (adapting the system to operate on differenthardware or software platforms) as four aspects ofchangeability/modifiability. Configurability (modify thebehavior or structure of the system at run-time usingconfiguration information) is also an important aspect ofmodifiability.

Usability is a measure of how much effort it takes for thetarget users to learn to interact comfortably the systemsfunctionality. Bass [2] identifies learning system features,using a system efficiently, minimizing the impact of errors,adapting the system to user needs and increasing confidenceand satisfaction of users as important characteristics ofusability.

Analyzability as defined by ISO 9126 refers to thesystems ability to be diagnosed for deficiencies, causes offailure or identifying parts that need to be replaced. Howeverin systems governed by operating practices such as ITIL,analyzability also extends to providing information aboutservice usage, user behavior, demand and capacity, resourceconsumption, run-time behavior and errors. Diagnosabilityand debuggability are frequently used to mean analyzability.

Testability refers to the ease with which the software canbe made to demonstrate its fault through testing, in otherwords the capabilities within the software that support testing

such as the ability to test parts of the system in isolation, tocontrol the internal state of components and to observe theoutputs of the components.

Deployability refers to the ease with which the softwaresystem can be installed or deployed in a specifiedenvironment. In many systems today, deployability alsorequires software to be installed without a break in services.ISO 9126 refers to deployability as installability.

139139


4/10

Manageability refers to the ease with which the softwaresystem supports operational support tasks such as resourcemanagement, archival, pruning log files, backup of data etc.

B. Conceptual tools of architectureThe quality attributes are used as the focal point to

transform the stakeholder productivity concerns into system

features. In order to accomplish this, the supportabilityscenarios use the conceptual tools of the architecture used inarchitecture design. These conceptual tools are broadlycategorized as

Use-cases which are used to decompose andrepresent functionality

Architecture styles, patterns, principles and tacticswhich play a crucial role in the design ofarchitecture

The structural elements of architecture likecomponent models, Service Oriented Architecture

Frameworks, aspect oriented programming

facilities etc.

The underlying platform services such as servicesoffered by J2EE, .NET and so forth

Allocation aspects of architecture likeinfrastructure deployment and allocation of

development to teamsAny quality attribute realization as well as realization of

any system functionality can only be done using the aboveconceptual tools.

Since supportability involves making organizationalstakeholders as active and primary users and its goal is torelate the degree of realization of quality attributes to theproductivity goals, it results in modifications of thearchitecture of the system using the above conceptual tools.

The supportability scenarios dealing with configurabilitytend to optimize the resources required to support business

and IT Operations. This leads to creating new use cases withthese stakeholders as primary actors, and producesextensions to component interfaces in order to supportdifferent behaviors based on configuration settings.

Similarly extensibility scenarios typically requirearchitecture patterns that support generalization such asplugin or microkernel patterns with existing componentinterfaces modified to behave as extension points.

Likewise, analyzability scenarios require modificationsto existing use cases to generate metrics about number ofrequests, usage patterns, classification of errors.Analyzability also leads to the definition of new use casesthat describe dashboards for various stakeholders to supporttheir planning and diagnostic work.

Testability and deployability lead to modifications ofcomponent structures so that parts of the system can bedecoupled and installed or run independently or additionaltools for diagnosis or monitoring be added, debug levels setetc. These attributes are also supported by platform servicessuch as instrumentation and management, aspect orientationand resource management.

Figure 2. Representation of the supportability framework

140140


5/10

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

In essence, on one hand the supportability scenario takes aparticular stakeholder's productivity concern as anoptimization of resources, money and time and on the otherhand it uses the quality attributes and the conceptual tools ofarchitecture to specify what changes and additions are doneto the system to provide supportability related features aswell as what changes and additions are done to the system'sstructure.

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 thestakeholder'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 mustbe addressed. The key is to look for stakeholders whose

work is some ways affected by the system.

2. Identify the stakeholders functions that are impactedby 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

uncovering process is using the functional and non-

functional requirements of the system as an input,

identify specific work done by the stakeholder that isimpacted as the system scales.

3. Describe the specific productivity scenario for thestakeholder as a statement of the time, effort or

resources to be optimized

4. Analyze the scenario using the quality attributes toidentify the features required to realize the desiredoptimization

5. Describe features of the system using the conceptualtools of architecture modifications or additions to use

cases, architecture patterns, styles and decisions,

components and their interfaces, deployment decisions

and so on

6. Add the features back to the original set ofrequirements 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 thescenarios serves to bring out these dependencies.

IV. APPLICATION OF THE SUPPORTABILITY FRAMEWORKIn this section, the framework is illustrated with the

example of a large-scale email system. The particularexample is chosen because email and email applications arefunctionally and are universally used and therefore thesupportability aspects can be illustrated without focusing toomuch on the domain aspects.

As depicted in Fig-3, end user functionality related tosending, receiving and reading email is more or less the sameacross all email applications irrespective of whether theapplication is designed to support a small set of users or

whether the system is a globally operated large scale servicesupporting millions of users. However real complexity lies inthe "functionality" designed for their scale includinggeographically spread servers, automatically optimizing diskquotas, spam detection etc. In this section, the under-the-hood functionality is enumerated using supportabilityscenarios.

I-Mail offers free and premium email services toindividuals and corporate organizations globally. I-Mailexpects to grow to over 2 million customers over four years,provide local language email across geographies and supporta large number of configurable services. I-Mail is a 40-person organization with a 5-person product/accountmanagement 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 andsenior management. End user customer support isoutsourced.

I-Mails architecture primarily uses an MVC pattern, andits important components are illustrated in Figure 4.

141141


6/10

Figure 4. I-Mail system components

The user interface components for web, POP3 and WAPclients form the views, the bridge and the ProgrammableEnterprise Integrator (PEI) serve as the controller andmessages, folders, users, mailboxes etc. are the modelelements exposed by XMAP and the user profilemanagement agent (UPMA). Components that manage user

profiles, mail data, sending and receiving emails andadministration are decoupled and communicate via amessage based integration bus coordinated by the PEI. I-Mail uses data center hosted Intel based servers runningLinux and multiple network attached storage units.

I-Mail requires the average cost per mailbox to be lessthan 1USD per year to ensure profitability of the business.The two primary constituents of this cost are people and ITinfrastructure. The analysis presented below assumes that I-Mails people and technology costs are already close to the 1USD per mailbox limit. The supportability scenariosanalyzed relate to what I-Mail requires to do to ensure that itcan continue to scale its user base and operations with littleincrease in either headcount or IT infrastructure. The details

of the analysis for the configurability, extensibility andmanageability quality attributes is presented below.

A. Supportability scenario for configurabilityScenario: Reduce the effort required to configure and

manage corporate email accountsStakeholder: corporate email account manager (business

stakeholder domain)Stakeholder Function and analysis of work to be

done: Account managers have to perform several activitiesas part of the administrative work to setup and manage emailaccounts including:

Setting up new corporate customer accountsincluding setting custom domain names, setting upbilling related information, customizing the userinterface etc.

Managing corporate accounts including setting upuser accounts, creating mailboxes, user profile,password and rights management, backing upmailbox data, allocating additional storage, makingchange to billing plans

In addition, account managers depend on IT teams tosetup the virtual hosts and domain name support, to

physically allocate the account to servers and storage and toadd additional storage.

Productivity concern: As the number of I-Mailcorporate accounts increase, the volume of administrativework increases. Current estimates indicate that a team of 4-5people supported by an equal number of IT resources canhandle 5000 mailboxes, but I-Mail will soon grow beyond

this number. The concern is thus to reduce the effort requiredin setting up and managing these accounts so that the sameteam can handle a significantly larger number of accounts.

Quality attribute: This is a configurability problembecause account managers require to "program" the tasksrelated to account management by themselves so as to reducethe effort and time taken to perform these tasks and eliminatedependencies on other teams

Supportability scenario analysis and featuresproduced: A simple configuration tool to setup and manageaccounts that reduces the manual effort involved in creatingthe account by automating all the background tasks isrequired. An account manger now uses this tool to setup andconfigure the account in terms of themes, multi-protocol

access, users, billing plans, storage required and so on. Toprovide configurability at the business user level, the emailsystem required the following:1. Use cases: The use cases describing account, user

creation and mailbox creation scenarios were modifiedto support selection of a pre-configured template and tosupport bulk uploading of user details in a delimited file.New use cases with the account manager as the actorwere defined to describe the configuration relatedfunctionality and related workflows. Since most of theactivities are now automated background tasks, adashboard for account managers to monitor the status ofthese tasks is also required.

2. Components and interfaces:a.

Additions to the database schema to supportpre-defined configuration templates is required.This reduced the amount of data entry requiredat configuration time via pre-filled in data.

b. Enabling a custom domain name requiredidentifying a cluster of servers that would servethe account, the creation of new virtual hosts inthe web servers and adding new DNS recordsthat pointed to these servers. These aremodifiability related tasks normally done by ITadministrators using scripts, but again the scaleprecludes manual activity related to executingthese scripts. The logic within the scripts isinstead implemented as services provided by

some of the major components such as theUniversal Management Console.c. Services exposed by the UPMA were modified

to support bulk creation of user accounts andmailboxes

d. The UMC was modified to call provisioningprograms that automated tasks such asallocation of new mailboxes to a cluster ofservers based on a load distribution algorithm

142142


7/10

and allocation of required storage to thesemailboxes.

e. The orchestration of the tasks wasaccomplished by introducing additional querycoordination logic into the programmableenterprise integrator components.

3. Allocation decisions: The functionality related to settingup and managing accounts includes many batchoperations. A separate instance of the application withthe components required to support these operations wascreated to execute these tasks without impacting theperformance of the email system.

Impact on other stakeholders: Configurable provisioningof new accounts requires server and storage capacity to bepre-available. This has an impact on the capacity planningwork done by IT operations teams. This is addressed bygenerating metadata as part of the configuration tools thatallows the IT ops teams to track metrics such as the rate atwhich new accounts are added, the number of mailboxes thatare provisioned and the rate at which storage and servercapacity is being allocated.

Summary: New supportability features include aaccount configuration tool, bulk upload functionality foraccount creation, configuration templates and programmaticcreation of virtual hosts and new domains. Each of thesefeatures is verifiable using functional test cases. Thesefeatures are supported by new services that orchestrate andautomate various administrative tasks that eliminated alldependencies on the IT operations teams. Together thisreduced the effort involved in setting up and managing emailaccounts. In the future, I-Mail plans to make this tool directlyavailable to users from these accounts. This degree ofconfigurability will enable I-Mail to scale the number ofaccounts to be supported without needing to increase theheadcount of the account management team thereby

accomplishing the business goal.B. Supportability scenario for extensibility

Scenario: Reduce the effort and time required to addnew email features and functionality

Stakeholder: Product management teams (businessstakeholders) and development teams

Stakeholder function and analysis of work to be done:Providing new email features are an important part of I-Mails strategy to differentiate it from its competitors. Someof these features include multi-language support to composeand send local language mail, attachment previewfunctionality, mobile phone integration, calendar integrationand to-do list creation from email, import and export ofcontacts, emails and attachments from existing mail softwareand standards based single sign-on and widget support toplug-in to other portal sites

The process of addition of a new feature includesrequirement definition, design - including changes requiredto the existing system, developing the new feature, makingmodifications to the existing system to integrate the newfeature, testing the feature with the rest of the system andthen deploying the changes into the production environmentwithout causing a service downtime.

Productivity concern: With new features requiringmodifications to the existing system, the dependenciesamongst features has to be carefully planned and extensiveintegration and testing effort is required. Therefore theestimated effort for feature addition is in the order of personmonths and features can be released only as part of plannedlarger releases typically once a quarter. The key concern for

product management is to reduce the effort required to addmost new features to two person weeks and enable newfeatures to be released every fortnight. This will enable therequired rate of features to be added without increasing theheadcount in the development and QA teams.

Quality attribute: A considerable portion of the effortrequired to add new features relates to making modificationsto the existing system to integrate the new feature and to thentest and validate the integrated feature set. Designing thesystem for extensibility will enable most new features to be"plugged-in" with minimal impact on the existing system.

Supportability scenario analysis and featuresproduced: Feature extensibility while minimizing theimpact on the existing system is accomplished by adopting a

plug-in based model. A feature developer is required to wrapthe functionality provided in a pluggable component that isthen loaded into the email system. The new plugincomponent adds processing elements to existing core emailservices and also to other plugins thereby increasing thefunctionality provided by the system. An example of such aplugin is an attachment format converter that converts avariety of binary file formats to a SVG format for preview.

The new process defined for feature developmentconsisted of developing feature using the APIs provided byI-Mail, uploading the code and test cases for the feature to astaging area, the testing and validation of the feature by theQA team and its release into the production environment. Tosupport extensibility, the email system required the

following:1. Use cases: A feature developer now becomes an actor ina new use case that describes a user interface drivenmechanism to upload the code with test cases and trackits progress through QA. The basic assumption of theplug-in model of extensibility is that existingfunctionality is not impacted; existing use casestherefore did not require to be modified.

2. Architecture patternsa. The architecture patterns used to support

extensibility are based on the Microkernelpattern [8] and the plugin design patterns. Themicrokernel encapsulates infrastructurefunctionality related to storage, resource

management, accessing mailboxes and thesending and receiving emails. The microkerneldefined a series of APIs for the plugins toleverage via the query coordinatorsimplemented in the PEI. Plugins in turnimplemented callback functions that areinvoked during method execution by the PEIand the Bridge components.

3. Components and interfaces

143143


8/10

a. Existing component services were organizedinto externally callable APIs

b. User interface components were madecomposable to enable a plugin to interact withusers through existing interfaces

4. Platform services: Platform services were used provide arepository to register plugins, mechanisms to

dynamically load or unload a plugin, and a hook andevent framework to implement the callback functionality

5. Allocation decisions: A continuous integration tool isused to automate the process of integrating approvedplugins with the rest of the environment to create newbuilds on a frequent basis.Impact on other stakeholders: Enhancing the rate of

feature development potentially meant more testing and QAwork. This was simplified by the introduction of anautomated test suite that ran a set of core and developerprovided unit test cases automatically when a new pluginwas added.

Summary: The extensibility scenario resulted in featuresfor plugin developers including tools to upload, register and

automatically test a new plugin. These were in turnsupported by a set of APIs. The functionality of the APIs andthe features are verifiable by testing. The plugin baseddevelopment model and the automation provided to load andtest plugin functionality reduces the work required to modifythe system and to test integrated functionality. Most newemail features can be added and released in within the 2-week period without breaking existing functionality. Thisenabled I-Mail to increase the rate of feature developmentwithout an increase in head count and to partner withexternal product vendors to make extensions to the emailsystem on a revenue sharing basis.

C. Supportability scenario for manageabilityScenario: Optimize the return on investment onresources such as storage as the scale of the email system

increasesStakeholder: IT operations teamsStakeholder functions and analysis of work to be

done:IT operations teams require planning and augmenting the

storage capacity available so that new accounts are providedwith appropriate storage space.

Productivity concern: Cost of storage is a significantcomponent of I-Mails IT spend. At 2 GB per mailbox and30,000 new mailboxes a month, I-Mail would potentiallyneed to add 60TB of storage a month. However, the cost ofadding such capacity is much higher than the revenue earnedfrom the additional users. Therefore, optimizing the use ofthe storage space is an important concern.

Quality attribute: Manageability - optimizing storagecapacity requires the automatic management of availablestorage by allocating only what is required and retrievingunused storage.

Supportability scenario analysis and featuresproduced:

Though I-Mail offers 2 GB storage per mailbox, mostmailboxes remain well below that number at around 40-50

megabytes even after a few years. Therefore, when a newmailbox is created all 2 GB need not be allocated only afew MB needs to be allocated. As a user mailbox sizeincreases, additional capacity is dynamically allocated.Secondly, on an average there are 6-7% of the totalmailboxes that become inactive. The space allocated to themshould be retrieved and added to available storage.

Both allocation and retrieval of storage space arecontinuous operations that span the email system and mustbe done automatically. To support these operations, metricson the average size of a mailbox is required to plan the initialspace allocation. In addition mailboxes that are approachingthe limit of allocated space must be identified toautomatically allocate more space to them and inactivemailboxes must be identified to retrieve storage space.

To support the management of storage, the email systemrequires the following:1. Use cases: The email functional use cases related to user

sessions, manage mailboxes, and read/compose emailswere augmented to generate additional information onmailbox sizes, mailbox growth rate, last usage time, and

frequency of usage. New use cases with the IToperations stakeholder as the actor were defined. Thisuse case defined the operations of a dashboard thatdisplayed the metrics and also the status of storageallocation and the automatic allocation and retrievaltasks.

2. Architecture patterns: Observer patterns and dependencyinjection were employed to dynamically add newmetrics to be gathered

3. Components and interfaces:a. The services exposed by the UPMA, XMAP

and UMC components were modified toprovide metrics about average mailbox sizes,and mailboxes that required additional storage

allocationb. The storage layer components were modified toallocate fixed blocks of storage to mailboxesbased on configurable settings

c. A batch program run once a day by the UMCautomatically identified accounts not accessedfor over three months and flagged them asinactive, moved their data to offline storageand freed up disk space to the common pool forallocation

4. Platform services: Management extensions provided bythe underlying platform were used to publish metricrelated data to the dashboards and enterprisemanagement tools.

Impact on other stakeholders: Customer support teamsoccasionally need to identify inactive accounts and restorethem to an active status and make their data available again.To support this, the location of the archived data is stored aspart of the customer account data.

Summary: By implementing the features for automatedmanagement of storage, I-Mail now needs to add onlyaround 3 TB a month. The manageability features related toautomatic storage allocation and retrieval are also verifiedusing test cases.

144144


9/10

D. Tradeoff analysis and Architectural DecisionsOne advantage of the supportability framework is that as

more quality attributes and stakeholders from across theorganizational divisions and their productivity concerns areincluded, the architectural complexity of the system becomesself evident in simple functional terms to all the stakeholdersinvolved. The ability to enumerate under-the-hood

complexity in functional terms makes it easy to make buildvs. buy decisions as well as planning incremental featurereleases. In most cases, there is also a certain degree ofprecedence of functionality of the system that can beobtained as result of the supportability analysis. For example,it is possible to articulate to and convince all I-Mailstakeholders that it is important to first build extensibilityfeatures and programmability such as APIs as a prerequisitefor providing configurability at a business user level asillustrated in the first scenario. Similarly programmaticcontrol of I-Mail services and the ability to run multipleload-balanced instances of services is a pre-requisite forstaged deployment.

Stakeholder groups and architecture decisions:

Business stakeholders typically come from all organizationalgroups and divisions that are concerned directly with theoperation of the core business services such as marketing,sales, product management and operations. In many systemsincluding I-Mail, business support functions such as HR arenot directly concerned, as their functions are not impacted bythe system. On the other hand business support functionssuch as finance are highly automated and require integrationof customer and billing information with the core financialmanagement systems.

Among the business stakeholders, typically there isa classification of type of work. For example, I-Mail hassenior management roles, middle management roles, andclerical or operational roles in each business function.

Irrespective of the type of the organization, and scale of theorganization, the productivity concerns have some relation tothe role of a stakeholder or the organizational groups.Consequently, for each type of business function, on anaverage there are two/three productivity concerns (seniormanagement, middle management, operational) and relatedfeature groups. In the IMail case a total of 14 stakeholdersled to 40 scenarios.

Build Vs. Buy Decisions: Such grouping of stakeholderconcerns by their functions is useful in making certain buildvs. buy decisions. For example, the analyzability concernsassociated with I-Mails business users requires providingbusiness analytics and configurable reporting. Thisfunctionality is not very specific to I-Mail and is used by a

small set of users and so can be accomplished using ageneric COTS based solutions instead of custom developingit. This saves both development effort and time. Howeverthis buy decision meant providing an asynchronouspublish/subscribe mechanism to export the data generated aspart of user operations to the database used by the analysistool. It is also well known that reporting requirements evolveover time, so a means of extending the data captured as partof user operations is required and was implemented as

programmable aspects. Similarly, the manageabilityconcerns of operational stakeholders using ITIL basedprocesses are standard and thus remote management of the I-Mail is accomplished via integration with commercialenterprise management applications. The supportabilityframework helps in enumerating the features andfunctionality 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 particularstakeholder community. Therefore, it is possible to buildreusable frameworks, models and components and use themacross many systems.

However there is also a large set of supportabilityfunctionality that is either specific to the system, stakeholderand organization such as the email product configurationinterface; that requires modification to existing use casessuch as gathering analyzability data from user operations orfunctionality directly used by end-users which would requirevery large number of licenses. In each of these cases COTSbased 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 theconfigurability scenario enhance or even re-design the use-cases keeping the productivity goal such as maintaining aspecific ratio of number of employees to the amount of workto be done.

Supportability Scenarios and Quality Attributes: Thefeatures and structural changes required have an impact onthe realization of other quality attributes includingthroughput, response times and availability. For example, adecision to provide end-user configurability of the userinterface requires the user specific page elements to beretrieved and interpreted at run-time and this has an adverse

impact on the page loading time. In I-Mail both page loadtimes and individual-user configurability were deemed to beequally critical so the page caching strategy had to berevisited to handle both the common and the user specificpage elements.

V. CONCLUSIONSIn our experience, one of the best by-products of the

application of supportability framework is that either thestakeholders reduce their desire for highly flexible,configurable and extensible systems or it leads to a betterappreciation of the quality attributes.

The use of the supportability framework leads to thefollowing benefits:

1. It bridges the gap between an ambiguous productivityconcern of a stakeholder and one or more qualityattributes of the system that are required to address theconcern.

2. Since the productivity concerns are realized as featuresand there is clear traceability between a concern and thefeature, the validation of if the productivity concern hasbeen addressed in the system is now transformed tovalidating if the feature has been realized.

145145


10/10

3. The question of how much of a quality attribute such asmodifiability is required in a system is now determinedfrom stakeholders productivity concerns that in turn aredriven by business goals. Instead of an ad-hocquantification, the features now become verifiable usingQA. Secondly, the degree to which the quality attributehas 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 themethod.

5. The degree of realization of the quality attributes, andthe reason for making certain architectural choices areclearly captured using the architecture design techniquessuch 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 scaleof the system and the scale of the organization as asystematic and methodological architecture analysis work.

As presented in the case study, there appears to be astrong relationship between specific quality attributes andarchitecture design choices, for example analyzability almostalways leads to enhancing, augmenting the existinginformation model of a system with new entities.Extensibility requires generalization schemes that transforma specific domain model into a computing model. This is tobe investigated further.

The supportability scenarios presented in this paperdescribe the supportability functionality in terms ofadditions, changes and modifications to the existingfunctional use-cases, architecture styles and patterns,platform services and allocation. This approach is analogousto 4+1 view [9] and the method proposed is similar to

bringing architecture patterns within the MDA framework aspresented by Daniel Perovich et al[10]The supportability framework works well with

stakeholders who have operational jobs. Even though it isuseful in other stakeholder groups like auditors, externalpartners and vendors to some extent it may not producevery precise drill drown of their concerns.

Certain quality attributes such as security cannot becaptured purely using the supportability framework alone.Security mostly translates as constraint on functionality,which includes the supportability related functionality aswell. Similarly, reliability is both a constraint onfunctionality and also can be a productivity concern. Weneed to extend the supportability framework to include

stakeholder concerns that span both functional as well asproductivity 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 inPractice - Second Edition. s.l. : Pearson Education, pp. 75-98.

[3] Buschmann, Meunier, et al., "Non-functional Properties of SoftwareArchitecture."[book auth.]Frank Buschmann, Regine Meunier, HansRohnert, Peter Sornmerlad and Michael Stal. Pattern-OrientedSoftware Architecture - A System of Patterns.: John Wiley and Sons,

pp. 404-410.

[4] Preiss, Otto and Wegmann, Alain., "Stakeholder Discovery andClassification Based on Systems Science Principles." s.l. : IEEEComputer Society, 2001. Second Asia-Pacific Conference on QualitySoftware.

[5] Muller, Gerrit., "The Importance of System Architecting forDevelopment." www.gaudisite.nl. [Online]http://www.gaudisite.nl/ImportanceOfSAforDevelopmentSlides.pdf.

[6] Glinz, Martin., "A Risk-Based, Value-Oriented Approach to QualityRequirements." 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.]FrankBuschmann, Kevlin Henney, Douglas C Schmidt. Pattern-OrientedSoftware Architecture - A Pattern Language for DistributedComputing.: 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. : IEEEComputer Society, Washington, DC, USA, 2009. Proceedings of the2009 ICSE Workshop on Sharing and Reusing ArchitecturalKnowledge. pp. 1-8.

[11] "Recommended Practice for Architectural Description of Software-Intensive Systems." ISO-Architecture.org. [Online] http://www.iso-architecture.org/ieee-1471/docs/ISO-IEC-FCD-42010-v27.pdf.ANSI/IEEE Std 1471 :: ISO/IEC 42010.

146146

A Supportability Framework

Documents

Transcript of A Supportability Framework