X
Business

Taking an incremental approach to SOA

Commentary--Many organizations, with limited SOA experience, found that their initial SOA deployments have underperformed or not met business unit objectives. But now there are new best practices that can find the path to success says NetManage's Archie Roboostoff.
Written by Archie Roboostoff, Contributor
Commentary--The Service Oriented Architecture (SOA) approach is top of mind for many technology and business professionals these days as many view this technology as an opportunity to lower IT integration costs while improving the time it takes to deliver changes to individual business units. Many stakeholders, however, with limited SOA experience, found that their initial SOA deployments have underperformed or not met business unit objectives. This has resulted in a number of organizations either scaling down their deployment plans or simply abandoning them for a future date.

The good news is that a set of best practices is starting to emerge based solely on successful enterprise-wide deployments. These best practices provide organizations of all sizes with a blueprint of how to get their SOA initiatives off the ground while making it easier for all stakeholders to understand necessary technical and business processes they need to follow to make their efforts successful.

Current implementation issues
One of the biggest hurdles to implementing a realistic SOA is understanding what the business units and end users are doing today. This understanding is critical to the success of any SOA project since the new services must match exactly what each business unit is doing today. Neglecting these business processes and replacing them with individual services will most likely lead to hundreds of non-used services and frustrated business units. Just getting started with this understanding phase, especially in organizations with multiple legacy-based applications, is one of the most difficult tasks facing service architects today. This is why so many organizations have taken the "top down" approach to service creation.

Rendering services from legacy systems as they exist, one for one with the "top down" approach only creates another layer of complexity since the business units will eventually have to repackage those services with an ESB or BPM solution. This “break down and put back together” mentality is why many business units choose to leave well enough alone and not implement a SOA solution that can cut costs, streamline processes and create new revenue streams.

Organizations that have successfully taken an SOA approach start at the department level and then plan a measured, incremental roll-out based on a series of milestones. In fact, Peter Kastner, a vice president and research director at Aberdeen Research recently said that "organizations that take a slow, incremental approach to legacy modernizations will increase the likelihood that their SOA project will meet objectives and diminish the cultural challenges developers have to using existing Web services to create new applications."

The incremental SOA approach: Pathway to success
The main goal of the Incremental SOA approach is to give organizations the flexibility to change and the ability to learn from failures. By implementing services that can be rapidly changed, IT analysts and software developers are able to work hand in hand with the operating business units to create services that make the most sense and deliver the greatest ROI. Incremental SOA not only gives tools to integrate, but it gives organizations the knowledge needed to create the most practical services. As a methodology, the approach minimizes risk in service-enabling projects involving IBM mainframe or System i (AS/400) software assets while reducing the uncertainty and unpredictability. This inevitably satisfies management expectations since the solution not only brings new technical flexibility, but also enhanced business flexibility. Beyond this, Incremental SOA helps in the planning and prototyping of processes while eliminating application behaviors that could alienate developers and end users and thus undermine SOA project success.

The incremental approach also addresses the fact that most SOA implementations that come in over budget and fail to meet expectations do so because they are poorly planned. The reason this has happened is not that the service architects didn’t plan accordingly; the failure comes from not understanding the needs of any particular business unit.

Most SOA projects force different business units to now act the same and use the same methodologies. Different business units are more agile than others so each service project must take that into consideration while fitting within the global scope of the SOA project.

<="" b="">
Incremental SOA is an iterative, four-step process with clearly defined software recommendations for each step. As defined below, successful implementations are planned and use company usage data within the four-step process: plan, build, evolve and scale:

First step: Plan
The plan stage of Incremental SOA is the discovery of how mainframe and System i applications are being used to carry out business processes. The vital information provided during this stage eliminates reliance on end-user interviews, server and application inventories, and system/network analysis to determine the blueprint and starting point for legacy-based SOA initiatives. For the first time, service architects are no longer looking at data, they are looking at knowledge. It is this knowledge that can, for example, show the service architect that a credit reporting call center uses 57 different transactions in very unique ways. These 57 transactions have six transactions in common with the offshore call center applications. The service architect can now start to map out a strategy for shared services by starting with those six shared transactions. Perhaps a new Web-based application could take those six complex legacy transactions and replace them with Web-based form buttons. Regardless of the end result, the service architect now has, for the first time, tangible evidence as to what to service enable first, and why.

Second and third steps: Build and evolve
Incremental SOA build and evolve steps include rapid service prototyping, modeling and updating capabilities. This enables business analysts to quickly model services that developers can reuse for creating new applications. Since changes are made easily through a drag-and-drop, point and click interface, developers and users work together to determine the best reusable service to deploy and scale.

This unique collaborative prototyping overcomes the cultural challenges that plague the success of many SOA projects. The main problem is that the services created are not being used by the developers and this eliminated the intended SOA cost savings. With Incremental SOA, developers are involved early on in service creation, ensuring adoption of the reusable services in creating new applications. By deploying these modeled services quickly, the business units have a say in the direction of the created services and final projects. This defines the future of the global SOA strategy while getting immediate ROI on a per business unit basis. Matching this collaborative step with the knowledge gained from the planning phase of Incremental SOA only increases the likelihood the SOA project will be a success.

Fourth step: Scale
The scale step consists of putting the validated services and applications--created during the first three steps of Incremental SOA--onto the legacy systems directly. While organizations are free to deploy these services to any middle tier application server environment, on some occasions, customers require the type of speed and power that only an enterprise class mainframe can offer. The point here is that the customer has the option of deploying services on ANY platform to meet the required business need.

Real-world example
Using Incremental SOA in a call center environment, a company can isolate all host transactions and business processes that employees make. These could be credit rating checks, shipment status verifications, mailing address changes or customer dispute resolutions.

Upon doing this, the most used transactions are identified and the company can create these transactions as reusable services to achieve the highest return possible on their SOA investment. They can now specify the exact host resources needed to create each service and know the performance characteristics for these services based on actual transaction usage frequencies. The company is now assured that the decisions made are based on collected knowledge, not guesses or assumptions.

Recognized ROI
The nature of SOA lends itself to incremental adoption. Most informed users are going one business process at a time, service-enabling just those critical legacy assets needed for each project. This allows those investments to begin to pay off more quickly, often recovering their cost in three to six months. By delivering services and new applications to individual business units first, ROI is recognized quickly but more important, the organization can now guide the development and realistic path of the global SOA project.

Bottom line
Incremental SOA takes a phased approach to successful SOA planning, development, and deployment. It addresses the challenges commonly faced by enterprises, such as understanding of business processes, prototyping services for testing, involving developers to refine the services, and deploying services for production-level performance and scalability. This incremental approach not only builds services quickly but the services are based on actual application usage, ensuring the best return on investment. This methodology takes SOA initiatives off of the whiteboard and makes them a reality, with less risk and more results.

biography
Archie Roboostoff has more than 10 years of experience in the high tech industry. He is currently responsible for Product Management at NetManage, Inc. Roboostoff is also the founder of e1525, Inc., a data management/ETL company.

Editorial standards