Evaluating the Benefits of Service Oriented Architecture: SEER in support of SOA Implementation Decisions
Galorath’s Dr. Denton Tarbet has been studying the estimation and analysis of service oriented architectures for some time. He provided this post regarding SOA. For further information, please email us.
SOA is often considered to be a means to provide IT services at lower cost. However, consideration should be given to what is meant by “cost” in the migration to an SOA for any organization.
For proper consideration of cost tradeoffs we consider the value to the customer, i.e. does the migration to SOA really provide a benefit to the stakeholders for the system? To consider that, first consider that SOA is not a process but it is an architecture. Relying on common understandings of architecture related to buildings, it is not sufficient to say the architecture is the blueprints, the drawings, the physical structure. What made many of Frank Lloyd Wright’s buildings so great was that he considered the architecture to include the total of the building within its specific environment. As an example, Wright’s Fallingwater: http://www.greatbuildings.com/buildings/Fallingwater.html
With that concept in mind, an SOA approach must consider its environment, i.e. the customers and how the resulting services will be used.
Within SOA the concept of service should be based on customer value. So the “service” in SOA isn’t really about technology, objects, interfaces, granularity, messaging, reuse, product stacks, standards, platforms, openness or almost anything else. It’s about mapping business processes to a software implementation that facilitates stakeholder outcomes and value. To effect that end, we rely on a solid estimation from SEER-SEM and SEER for IT to develop the effort, schedule and risk to provide the basis for tradeoffs to provide the best Return on Investment (ROI). See additional:
Common Misconceptions About Service-Oriented Architecture – Crosstalk, Nov 2007
SEER Support for Estimation of Effort and Schedule in a Service Orientated Architecture (SOA)
SEER effort/schedule estimation suite is being applied to systems being developed within a Service Oriented Architecture (SOA) methodology. Service Oriented Architecture as a methodology for integrated systems is often advertised as a method to significantly reduce costs and risk of development, implementation, and maintenance of IT systems. However, there are significant challenges in developing a valid estimate which provides both effort (and cost) and schedule confidence levels. In order to understand how SEER is being applied, we will first define SOA as used in this discussion.
SOA is a way of designing systems composed of services that are invoked in a standard way. As an architectural style, SOA is neither a system architecture nor a complete system. An SOA-based system is composed of the following:
- Services that are reusable components that represent business or mission tasks, such as customer lookup, weather, sensor placement, account lookup, or credit card validation.
- Service consumers that are clients for the functionality provided by the services, such as end-user applications, systems, or even other services.
- SOA infrastructure that connects service consumers to services.
Typically SOA is considered for improving or reducing IT development costs. However, the method has application to a wide range of situations. Our applications have been the redeployment of existing complex ground systems from a traditional “mainframe” type application to an SOA infrastructure. The goal of incorporating an SOA methodology is to expand the potential community of users for the system. In developing estimates, we have encountered many of the typical problems referenced by the literature. For example, in “How to Cost an SOA Project” and “How Service-Oriented Architecture (SOA) Impacts Your Infrastructure,” David Linthicum notes:
- The design and testing of SOA components must be more robust than a typical “single application” software component, and
- The infrastructure must be evaluated with the ability to accept a level of user that normally cannot be defined with the initial requirements for the application.
Design and testing of an SOA component must consider that the full range of application is not understood since the component may be utilized for a modification of the expected utilization in the future. That potential for a wide range of users requires a more robust design and testing to ensure that the component will support the full range of users.
That range of users is precisely why the infrastructure is difficult to estimate at project conception. Since an SOA project is designed to accept future users that are not defined at the start of the project, it is not possible to design the system with sufficient throughput and network capacity to accept all future users — therefore the design must plan for growth in the user community. Typically SOA projects are being implemented in systems such as blade servers where the applications can be dynamically allocated to available blade capacity. In a blade system additional processing capability can be easily added with additional blades operating under the dynamic allocation of the blade operating system within the blade center.
Estimation of the components is being accomplished within SEER for Software with considerations for the more robust design and testing required. However, for the infrastructure we have incorporated the use of SEER for Information Technology (SEER for IT) which includes a comprehensive modeling capability to define and estimate the infrastructure. SEER for IT infrastructure allows the modeling of the system elements such as the systems analysis, design trade-offs, selection and implementation of the computing servers, the networks required, database schema design, and database implementation.
In our applications we have developed both an infrastructure model and the software model for the application components. In the case of the infrastructure model we have incorporated vendor data and user experience in defining costs of components, lead times to acquire, acquisition planning and costing, installation including cabling of networks, network installation, operations, and maintenance of vendor supplied systems. The SEER for Software model for the applications components should account for the additional design and testing effort required for SOA projects. In our applications, we incorporated the parameters for “Reusability Level Required” and the “Software Impacted by Reuse.” We considered the SOA applications components in our specific applications to support a limited solution space so we set the Reusability Level to:
- Least set to Hi-
- Likely set to Hi
- Most set to Hi+
Which is a setting for software to be reused within a single application area. That definition applied to our application and resulted in a 12 to 13% increase in cost over a typical application development. If the SOA component were expected to be more widely applied, we would set that parameter correspondingly higher. For most applications, we would expect to set the amount of the software to be reused within that SOA component to 100%.
The application of this method has provided our client with useful estimation information from which to develop budget requirements for both cost and schedule based on a confidence level analysis rather than a single point estimate. An interesting side benefit to the infrastructure modeling has been the requirement for a detailed understanding of the infrastructure as designed in order to define the inputs to the infrastructure model.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.