MC Press Online

Saturday, May 27th

Last updateThu, 25 May 2017 10am

You are here: Home ARTICLES Programming Programming - Other Change Management Best Practices: Taking an Incremental Approach to SOA

Programming / Change Management

Best Practices: Taking an Incremental Approach to SOA

Support MC Press - Visit Our Sponsors

NEW BOOK!

Evolve Your RPG Coding: Move from OPM to ILE ... and Beyond


ORDER YOUR COPY

*******************

Click for this Month's

Bookstore Special Deals

With this evolution, the inefficiencies of working with other systems, carriers, and third-parties are being alleviated, and response time to customers is improving. When implemented correctly, SOA helps companies meet their business goals by enabling all facets of business processes to work cohesively. However, as more enterprises continue to move toward SOA, executives with limited SOA experience have found that initial deployments did not meet business objectives and therefore have scaled down and, in some cases, even abandoned their plans for deployment.

Implementation Obstacles

One of the biggest hurdles in implementing an SOA is just getting started, especially in organizations with thousands of legacy systems. In many projects, SOA initiatives stay stuck on the whiteboard because of the time and investment necessary to understand business processes, prototype services for testing, and deploy services for production-level performance and scalability. Typically, SOA implementations begin with the time-consuming task of user interviews to see which transactions users are utilizing most to do their jobs. Then, an IT professional has to manually comb through system and network logs to try to determine transaction usage, a time-consuming and costly process. SOA implementations become more challenging when specific business processes span multiple host systems or applications. The critical preparatory phase of SOA projects can be frustrating, confusing, and filled with delays because developers don't have the right information-gathering tools.

Kaiser Permanente hired a consulting group to implement a major SOA initiative focused on improving the customer experience and cutting development times across the enterprise. After two years and millions of dollars spent on software and fees, the initiative never got off the ground.

It is through these experiences that a set of best practices have emerged from successful enterprise-wide developments, indicating how to derive the most value from an agile infrastructure. These best practices help corporations understand how to get their SOA initiatives off the ground as well as provide them with a clear understanding of the technical and business processes they need to follow in order to complete a successful deployment.

The Incremental SOA Approach

Incremental SOA is a methodology that minimizes unknowns in service-enabling projects involving legacy assets. By taking an incremental SOA approach, organizations can make a smooth transition into SOA deployments while benefiting from the step-by-step implementation process. The methodology reduces the uncertainty and unpredictability associated with SOA projects and allows IT teams to quickly address management needs and satisfy their expectations.

Incremental SOA provides enterprises with precise knowledge about which specific host resources are being used in everyday business transactions within the organization. More importantly, the methodology makes it easy to see how these transactions are being used by end users and correlates their overall resource usage to the underlying business processes for which they are being developed.

From this, businesses can understand which transactions are used the most and then can create them as reusable services to achieve the highest possible return on their SOA investment. They are able to specify the exact host resources needed to create each service. Further, organizations will know the performance characteristics for these services based on actual transaction usage frequencies. After taking an incremental SOA approach, organizations can be sure that the decisions they make are based on collected data, not guesses or assumptions.

The Four Steps of Incremental SOA

The successful deployment of SOA-based solutions depends on successful planning in creating services that are widely adopted by developers. Although incremental SOA consists of four steps, each step is designed to be independent and self-contained. This flexible approach allows businesses to exploit the capabilities of incremental SOA at their own pace, with their own individual requirements. Much of the incremental SOA four-step process is automated so businesses can implement projects quickly with minimum staffing.

Step One: Plan

During the planning stage of incremental SOA, the main focus is discovering how legacy ("green-screen") applications are being used to carry out a business process. The vital information discovered 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. By using the planning stage intelligently, service architects use the proper diagnostic tools to make informed decisions based on the correct data.

This understanding is likened to existing business intelligence (BI) solutions. Decisions about corporate direction and strategy are linked to information gathered by BI tools. If sales are down or revenues are flat, something needs to be changed. The same mentality should exist for the direction and strategy of IT architecture projects. This is where integration intelligence comes into play by focusing on the understanding of an environment before the integration project begins. The planning stage of incremental SOA gives organizations the opportunity to catalog and analyze this information.

It is this knowledge that can, for example, show an insurance company service architect that a claims processing call center uses 57 different transactions in 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 can be instituted, taking those six complex legacy transactions and replacing them with Web-based form buttons. Regardless of the result, the service architect now has, for the first time, tangible evidence on what to service-enable first and why.

Step Two: Build

Now that the business has an understanding of service transaction use from the planning process, the next step is to model the services used most often, those that will provide the company with the most impact. These transactions can now be examined, and the business can decide which candidates they want to encapsulate as reusable services. This non-invasive approach to creating a host-based service enables SOA architects to quickly model and prototype a service without installing software on the mainframe or involving mainframe administrators.

Step Three: Evolve

This is the point when an SOA project gains critical mass. It is when the three crucial elements of an SOA project finally come together: the new SOA application, the SOA services it uses, and the users of the application. It is at this point that theory finally turns into practice. The SOA application is now ready to be tested.

During this step, developers provide feedback to the SOA architects about fine-tuning the service, such as including input and output parameters to meet their development needs. This is a critical step that will minimize the cultural challenges developers face in adopting reusable services. By involving developers early in the service-creation process, SOA architects ensure that those developers are more likely to use the new SOA services when building new applications because the services meet their needs.

This iterative process occurs between developers, SOA architects, line-of-business managers, and beta users. During these iterations, developers may refine and fine-tune SOA services by changing transactions, creating new composite transactions, adding new transactions, or updating the databases/data sources being accessed (all based on feedback from the business stakeholders).

Step three may never really be considered "complete" as these services could require fine-tuning or updating based on ever-changing business requirements. The advantage of the incremental SOA approach is that available development tools make this iterative process quick and easy.

Step Four: Scale

Once the SOA architects, business managers, and developers of the SOA project are satisfied that the new application (which leveraged the newly created reusable services) has achieved the desired outcome and is ready for production, the service can reside on the legacy hardware to achieve maximum performance and scalability. This is likely to be a critical requirement for large enterprises that a have high number of concurrent users and transactions and need high reliability for production-level throughput.

Step by Step

As an increasing number of organizations consider SOA adoption, it is becoming apparent that a step-by-step approach is extremely important. The incremental SOA method bases service creation on actual application usage, which assures the best return on investment and better deployment results. Incremental SOA addresses challenges commonly faced, such as understanding key business processes, prototyping services for testing, involving developers to refine the services, and deploying services for production-level performance and scalability. An incremental methodology takes SOA initiatives off the whiteboard and makes them a reality, with less investment and more results.

BLOG COMMENTS POWERED BY DISQUS