Dinkar Gupta is an Associate Director in Cognizant's Banking and Financial Services (BFS) Technology and Architecture Organization. As a Principal Architect, he heads the strategy, architecture and technology teams assisting global BFS clients. He has a post-graduate degree in computer science and applications and has around 15 years of software development experience across multiple industry segments. He is also an IBM-certified solution designer for Rational Software Architect and is actively engaged in enterprise IT architecture, system transformation consulting and solution delivery roles for BFS customers. Dinkar can be reached at Dinkar.Gupta@cognizant.com
Service Point Estimation Model for SOA Based Projects Published: November 27, 2013 • Service Technology Magazine Issue LXXVIII PDF
Estimation in Service-Oriented Architecture (SOA) based projects has been a challenge for IT teams across the globe. As per [REF-1] "Estimating the cost, size and efforts for SOA application is a difficult task due to its diverse nature and loose coupling behavior, which results in an inaccurate estimate to measure the efforts, size and functionality of SOA applications". Service Point Estimation Technique presented in this paper is a newly developed estimation technique to calculate the size of an SOA project and derive efforts and costs for the corresponding service implementation. Based on foundations similar to the UCP & FP estimation techniques, it is a technology agnostic and generic model that can be applied in SOA projects across business solutions or product development initiatives. The basic reason for its design was simple - help IT teams answer the question "How big is this (SOA project) and how much will it cost to implement?"
Given that the notion of service includes many more aspects that just functional logic served by that service, the estimation model considers all 3 aspects of service design – functional complexity, Quality of Service (QoS) expectations and service development environment; while calculating the size of Service at granularity of both service operations and service interface contracts.
In past we have clearly felt the absence of a scientific method to estimate SOA projects in terms of the core unit of these projects – the services. This model is an attempt to fill that gap. The entire portfolio of service development, large scale service migrations and technology transformation programs are expected to get benefitted from the model because SOA is the norm in majority of systems development projects across enterprises.
Background and Context
As is well known, SOA is founded on the notion of Services and each service is the characterized by 3 distinct layers – 1) Policies & Service level agreements (SLAs), 2) Service Interface and 3) Service Implementation, with the first two forming what is generally referred as Service Contract.
Figure 1 - Logical Service Model
Every service supports the business/functional capability assigned to it through a set of well-defined operations that are offered on the interface of the service under the specified SLAs (often called QoS Parameters). These operations consist of a set of messages that are exchanged between the consumers and providers during service invocation.
How the provider implements the service operation at the discretion of the providing system as long as the operation conforms to the service contract published for the consumers. Typically such implementations make use of other fine grained services, internal application data stores, external system interfaces, internal business object/domain model or algorithmic computation to fulfill consumer requests received through the service operation. All of these aspects contribute to the Functional Complexity of the service operation.
Another often ignored but equally important element of any project is the organizational context of the project. This context includes aspects such as team working on project, available business & technology know-how and proper tool support among others. These factors, generally referred as Environmental Factors in estimation parlance must also be closely looked at during SOA project estimations.
Given that there are multiple factors that may impact the complexity of service design and development, it's critical that during estimation of service development efforts a holistic view of service is considered instead of just the implementation or only contract or the technology that's going to be used.
Existing Models and Studies
As the active mainstream development in SOA space started quite late and the enterprise adoption of SOA as at large scale is still in progress, there's been a lack of formal techniques for estimating SOA projects. Estimation techniques such as those based on use case points (UCP), function points (FP), complexity points (CP), COCOMO, Lines of Code (LOC) have been around for some time but most of these were not developed with the contemporary SOA style systems in mind.
During the research on this topic, it was found that only COSMIC FP estimation model offers some concrete guidance in this space (see [REF-2]) but that too is limited to the data exchange related aspects of services. The QoS and environmental aspects (e.g. Governance controls) are not considered in that model. The other attempt is from NICTA (see [REF-3]) but that too is quite abstract (refers to COSMIC FP for most parts) as it more of a guidance on how to approach SOA estimation. Recently, Yuri Marx Pereira Gomes published an article on Using Function Points for SOA estimation (see [REF-4]. The article does an excellent job of explaining how to map elements of SOA projects to FP elements and offers a pragmatic model to estimate SOA projects. However, this approach also falls short on the other aspects such as QoS expectations and environmental aspects of the project.
Despite their limitations these approaches/models provided an excellent starting point to develop a relevant estimation model for SOA projects and therefore these models and the existing work by UCP community has been leveraged to come up with the model presented below.
Service Point Estimation
The approach described in this paper is called Service Point Estimation. To align with well-known concept and terminology, the concept of service point (SP) is borrowed from the existing work done in estimation space.
As defined in [REF-5], a Service is a unit of solution logic to which service-orientation has been applied to a meaningful extent. It is a container for a collection of related functions. These functions are called service capabilities and those exposed via a service contract establish a basic API by which the service can be invoked. In modern day, web service oriented SOA, service capabilities are represented in the form of service operations. Figure 2 provides an example from financial services domain. In this example, capabilities such as creating an order, checking order status and canceling an order are provided as service operations on the service OrderExecution.
Figure 2 - Service & its Operations
The size of the Service Operations and Service in captured in SP units and the efforts are also derived based on the same size. Rest of the paper provides details of how this concept is applied to a service model under estimation.
The model is based on the premise that individual service operation should be the unit of measurement and aggregation of these operations at the service interface level will provide the overall sizing of the service. Once the sizing at such granular level is ascertained it's easier to aggregate the same even up-to the service portfolio being delivered through a project. The efforts though are calculated at individual service interface level because it's generally impractical to have projects delivering only single service operation (although that is just a base case – a service having only one operation).
As mentioned above, the model is based on notion of complexity in the form of function and quality expectations because the core contributors to the operation's complexity are the functional requirements & system quality objectives. Together these contribute (calculation explained later) to the complexity of the service operation. Once the complexity is ascertained for all the concerned operations of the service, the environmental factors are applied (explained later) resulting in the overall complexity involved in development of the service being estimated.
Figure 3 - Service Point as Complexity Measure – Key Components
Complexity of a service operation can be stated in the form of certain key measurable parameters that are generally captured. These parameters can be categorized in 3 primary buckets i.e. invocation data, business logic and downstream integration. Here's a brief description of the parameters considered for complexity calculation in each of the categories
During later part of this paper, it's described how these parameters are evaluated and rated to arrive at functional complexity of the service operation.
As described earlier, complexity of the service operation is also a factor of the non-functional requirements that are specified for the service. These requirements are referred as QOS objectives in this model. Just like the functional complexity parameters, the QoS objectives are categorized into 2 major categories i.e. operational objectives and implementation objectives. Here's a brief description of the parameters considered for complexity calculation in each of the categories
Operational Objectives (Runtime aspects)
Implementation Objectives (Development aspects)
Integration Participants / Integration Actors
An extremely important element of any estimation model is the actors involved in the system scope being estimated. In case of SOA, there are no direct "end users" which can be counted for in this category. Instead the system actors are the ones which participate in service oriented integration as service, data or resource providers for the operations being estimated.
For this model, 3 major actors have been identified. These include a database interface, another service interface and a proprietary API/adapter (in increasing order of complexity)
Project Execution Environment
One final piece of puzzle in complexity identification is the environment (project context) specific aspects that have an impact on how much effort needs to be spent on during the lifecycle of the project. While the aspects described so far apply to the service operation, the environmental aspects impact of the overall project and not just service operation. We have seen following aspects impacting most SOA projects (some are applicable generally to all projects).
Please note that the parameters in each of these categories are by no means exhaustive nor do these represent all possible elements involved. However, in the experience of the author these are most often encountered factors that are analyzed during estimation in the enterprise SOA projects.
In order to arrive at the estimates for a project that is expected to deliver a certain portfolio of services within a given domain/segment, we recommend a 4 step process to be followed - Complexity Identification, Project Sizing, Effort Calculation and Cost Calculation.
Figure 4 - Service Portfolio - Development Effort Calculation Process
As a first step, the complexity for each of the operations being offered on service interface needs to be identified. All complexity parameters for functionality, quality of service and integration participant categories are considered in this stage.
Within each category, the simple complexity scoring model is applied. For each parameter, a complexity valuation scheme is defined. This includes 3 possible options for the complexity range of that parameter, a relative weightage for the parameter and an estimator's rating for that parameter (to be selected during estimation). Based on the weight and the rating selected, a simple weighted complexity value is identified for the parameter. The following figure depicts this for one of the parameters
Figure 5 - Functional complexity scoring (per complexity factor)
In the same manner all functional complexity factors are rated and finally a functional complexity score is computed. Figure 6 provides a sample of computation
Figure 6 - Functional Complexity Calculation for a Service Operation
In the model, the score may range from 15 (functionally simple operation) to 45 (functionally complex operation). The complexity is represented in the form of Functional Complexity Factor (FCF) and that's determined based on the complexity rating range to which the operation belongs (see Figure 7). In the figure, SWF for the operation is identified as 7 based on the complexity rating of 45 (see Figure 6). In order to simplify model, we recommend a weightage scheme of 3, 5 and 7 for simple, average and complex operation.
Figure 7 - Functional Complexity Factor Calculation
Additionally, the integration participants involved in the service operation are identified and complexity for each of these is identified. The result is availability of Integration Complexity Factor (ICF) as depicted in Figure 8.
Figure 8 - Integration Complexity Factor Calculation
Together both FCF & ICF help us get the first measure of the complexity for the service operation under consideration. Following the terminology of existing estimation models, we term this measure as Unadjusted Service Point (USP). The adjustments referred here being the technical complexity factor explained below.
The third contributor the complexity, i.e. the technical complexity parameters are also rated in the manner similar to functional parameters, although in a slightly different manner. The weightages are assigned to each of the parameters and the estimator selects a value (from range 0 – 5 in the order of relevance) for each of these. This result is factor rating for each of the parameters/factors. As sum of the ratings is the Technical Complexity Score (TCS) for the operation.
Figure 9 - Technical Complexity Factor Calculation
The Technical Complexity Factor (TCF) is a function of number of QoS factors/parameters and impact these factors may have on the development effort to be applied in the project. Based on this, we have used the following formula to arrive at the technical complexity factor
TCF = 1.0 + (0.01 * TCS)
Due to lack of historical data at the time of model development we have assumed uniform impact for each of the parameters (0.01).
Environment Complexity Factor
The Environment Complexity Factor (ECF) is also calculated in manner similar to the TCF. All the complexity parameters are scored and the result is a weighted rating of the complexity.
Figure 10 - Environment Complexity Factor Calculation
Similar to the technical complexity factors a weight and value is applied relative the importance of the environmental factor. Based on the calculated Environment Complexity Score (ECS), we have used the following formula to arrive at the technical complexity factor
ECF = 0.7 + (0.01 * ECS)
As in the case of technical complexity factor, we have assumed uniform impact for each of the parameters (0.01) due to lack of historical data at the time of model development.
Once the complexity of the service operations is known, we can calculate size by first calculating the size of the service operation (Service Operation Size or SOS) and then aggregating the same upwards for service interface and service portfolio. All size measurements are defined in terms of Service Points (unit of sizing, like the Use Case Point)
The size of the service operation is simply a product of USP and TCF represented as
SOS = USP * TCF
Given this, the size of the service interface (Service Interface Size or SIS) is represented by
In case a larger portfolio of services is part of project, the Project Size (S) is a simple sum of SIS within the portfolio
To summarize, the sizing calculation is essentially carried out in detail for lowest unit only i.e. the Service operation. All the size calculations are aggregation of the same till the entire portfolio of services is covered. The final size calculated is represented in units of Service Points.
Effort calculation post sizing of the project is a long-known and simple technique and this model also follows the same instead of creating something new. According to this technique, in order to calculate the effort required to implement a project of given size, one needs to know the productivity of the project team. In case of SOA projects, this means we want to find out how many service points can be delivered per man-hour/days by project team proposed for the project.
Given, Productivity is represented as (assuming Person Days or PD as the unit or time measurement)
P = PD per SP
The overall service development effort (E) is calculated as
E = P*S
As an example, if the productivity of the team is 5 PDs of effort per SP and the Size of project (S) is 50 SPs, the effort required to execute the project would be 250 PDs.
An important aspect of effort calculation is the fact that there's more to development in SDLC phases that just development (often referred as CUT or Coding and Unit Testing). Mostly it's been observed that a standard approach to just split the development effort across requirements, design, coding, testing, support phases is not effective (although essential) for SOA projects. Instead a more pragmatic activity based effort split gives a better picture of where and how-must effort we will have to spend during the entire project.
In this model, we propose a similar activity based effort split approach to arrive at overall effort. In this approach, once the service development effort is calculated, project activities are identified in 2 major categories
Given these set of activities, we apply a distribution across these activities, relative to the computed service development effort. The following figure depicts a sample scenario where the service development effort is distributed across both categories mentioned above. Applying this distribution, we get the Net Effort for the project. The Project's overall delivery effort (PDE in figure below) is calculated by adding the necessary efforts for post-production support, contingency and management. The distribution applied for these activities is relative to the Net Effort.
Figure 11 - Delivery Effort Calculation based on project scope and activities
As depicted, the service development effort of 51 PD actually translates to 86 PDs of overall Project Delivery Effort, when all other activities & delivery aspects are taken into consideration for the estimation. This means that the core development activities taken up by developers account for approx. 60% of the Project Delivery Effort (approx. 75% of Net Effort) and therefore in order to avoid project surprises, it's essential to explicitly consider estimates for other activities too.
Once the effort estimates for the project are available, the overall cost (C) calculation is a function of hourly/daily rates (R) that the organization charges for the work. This essentially means
C = E*R
This simple approach to cost calculation is well established and known to almost all teams so it's not explained further here.
A slight pragmatic variation of the scheme is observed while project's work location split is applied to the calculation. The location split essentially represents that ratio of team split across 2 or more locations of project execution. In the enterprise IT service provider organizations, onsite: offshore is a typical location split applied to projects. In such cases, different rates are applicable for different locations.
Let's extend the example in last section for cost calculation. Assume that the project requiring 250 PDs of effort will be executed between two locations - New York (onsite) and Bangalore (offshore) with respective rates for both locations being $1000 and $300 respectively. Assume further that 80% of the team will be located in Bangalore while rest 20% in New York. Given this, the cost of the project is calculated as
Table 1 - Project Cost Calculation (location split scenario)
Another variation that's applied is the graded rates variation. In this case, instead of location, the graded resourcing variation is applied to the team being proposed for the team. Finally, hybrid model including both location and grade split is also employed. Both are known methods in IT space and thus not explained further in this paper.
While there are some elements of the model that are applicable across project estimation scenarios, there are some that will definitely tend to differ across projects and organizations. These variations are expected to be encountered through
The model provides necessary support to implement these variation points while applying this for different scenarios.
Estimating SOA projects has been a challenging topic. There are specific considerations for functional complexity of services, QoS expectations from these services and the environment in which the services are developed. The model presents an approach which is a blend of experience in executing SOA projects and well-known estimation techniques that have stood the test of time in enterprise IT projects. With possibility to adapt the model to specific preferences of the project team, we have a tool that helps us get a handle on the size of SOA project in hand and derive an estimate of the effort required to deliver it.
[REF-1] Integration Efforts Estimation in Service Oriented Architecture (SOA) Applications http://www.iiste.org/Journals/index.php/IKM/article/download/747/648
[REF-2] Guidelines for SOA Projects http://www.cosmicon.com/portal/dl_info.asp?id=124
[REF-3] A Framework for Scope, Cost and Effort Estimation for Service Oriented Architecture (SOA) Projects http://www.nicta.com.au/pub?id=1579
[REF-4] Functional Size, Effort and Cost of the SOA Projects with Function Points http://www.servicetechmag.com/I68/1112-4
[REF-5] SOA Glossary at http://serviceorientation.com/soaglossary/service