Other Cover Stories

An SOA project mandates a best practices approach

Kalyan Kolachala provided some insights on successful SOA projects and cautioned that it should not be pitted against the measurable returns of ERP or CRM projects

While Service Oriented Architecture or SOA may not have 'arrived' in India yet, it has certainly gained a lot of CIO mindshare in recent times. From what it seems, Indian enterprises, albeit a few, are currently looking at adopting SOA and reaping the benefits that are often attributed to it. However, implementing SOA isn't like implementing an ERP or a CRM package. It is not something you 'buy' but rather something that you 'do' and that's where it gets tricky. It is therefore extremely important to follow a standards-based, best practices approach when embarking on a SOA adventure.

The recommendations given below are based on my own experiences working with various customers on diverse SOA projects for the past several years at BEA, Fiorano and SOAMatrix. The ideas have been refined based on interactions with industry experts and thought leaders.

Focus on business, not IT or technology: One of the key drivers for SOA adoption is that it raises the level of abstraction making it easy for the Line of Business (LOB) user or a business analyst to model and define the system being built and the associated workflows. This makes it a lot easier to minimize the traditional disconnect that has existed between business and IT. Despite these benefits, there is a risk of the SOA project losing the business focus and becoming IT or technology focused. This can be avoided by ensuring that the business and domain experts are closely involved in the project from start to finish ensuring that the business needs are properly understood and implemented.

Ensure reusability: A major benefit of SOA adoption is increased reusability. However, reusability is not guaranteed simply by using SOA but only by ensuring that the right discipline, policies and processes are in place. For services to be reusable it is important to ensure that they are generic and not fine-grained. It is also important to ensure that services are well publicized and preferably published to a registry or repository. It is also important to ensure that the services that are published have gone through reviews and testing and have the required approvals. All these can be ensured by using design-time governance tools. It is even better if there is a measure of eusability and the team developing the services gets appropriate credit.

Business rules and enterprise repository improve agility: One of the major benefits that comes with the use of SOA is that the implementation cycles are shorter and it is easier to modify the business process definition to match the evolving business requirements. One way to ensure greater agility is by ensuring that the elements of the business process that are prone to frequent change (tax rates, interest rates, telecom tariffs) be externalized as business rules so that any changes to these elements do not impact the business process.

Another approach that we have seen significantly helping with agility is the use of an enterprise repository. The enterprise repository helps store the metadata (data about data) related to various enterprise assets and artifacts, organization hierarchy, user and role information and associations and dependencies between all of these. Use of all this information makes the business process far more agile, flexible, powerful and robust.

Implementing incrementally up the stack is a recipe for failure: It is often recommended that SOA adoption be incremental. While an incremental approach is low risk compared to a big bang approach, this incremental approach can be disastrous if it involves incrementally moving up the stack. Enterprises that start with Web service enabling their applications and resources, then use the ESB and Process Orchestration, add QoS (quality of service) and then adopt management and governance are likely to meet with failure. This is because it takes a lot of time before the real benefits of SOA are realized and could also lead to pitfalls and problems with several key components such as management, governance and QoS coming in late. While an incremental approach is preferable, it is better if it is a vertically sliced one. Thus, it is much better if the enterprise uses the complete stack in a department, starting with a pilot project, as opposed to enterprise-wide adoption of an ESB. The latter approach is likely to fail or unlikely to deliver the desired ROI.

SOA management and governance are essential to success: In the early years of SOA hype, there was huge adoption but also a large number of failures. Most of these failures could be attributed to lack of management and governance.

Once composite applications have been built using SOA, the challenges are to ensure that the performance is consistent and up to the required level. While SOA makes it easier to assemble and wire the services together and build composite applications, operation control, visibility and maintenance of enterprise, SOA applications become even more challenging for the following reasons:

• Multiple applications and technologies: SOA applications commonly involve multiple applications built on a wide range of languages, protocols and technologies (such as Java/J2EE, .NET, CORBA, COM/DCOM, HTTP, Files, RDBMS, XML, ERPs, CRM and so on) and diverse operating systems. This makes it extremely challenging and time-taking to troubleshoot, localize and isolate problems manually. For example, in a composite application exhibiting slow response or throughput is even more challenging to identify where the problem originates.
• SLAs, performance, and availability: Applications and services are often committed to Service Level Agreements (SLAs) with respect to response time, throughput and availability. Violation often leads to severe penalties and thus it is desirable that there are alarms when SLA violation is close or about to occur and better if the SLA violations can be prevented automatically.
• Distribution: SOA deployments are often distributedsometimes across departments, domains and geographies, caused primarily by the widespread adoption of Web services across platforms and vendors and the ease of invoking them over the intranet and Internet using HTTP(s). This creates the challenge of reliability, network latency and failures and the need to alert on failures and redress the problem wherever possible after the root cause has been identified.
• Security: In SOA applications, it is most important to ensure that the access to services and processes are allowed only to authorize users, roles and user groups. It is desirable to insulate the business developers and users from the complex security details and let the underlying infrastructure handle it. Identity propagation and single sign-on is another challenge that often needs to be handled in composite applications.
• Compliance with organizational and governmental regulations: It is mandatory for enterprises to comply with government regulations (such as SOX, Clause 49 from SEBI, depending on the geography and jurisdiction) and any others mandated by the organization. Enforcing these policies and providing the audit trail needs to be automated.
• Scale of deployment: In SOA projects, management and governance issues rarely come up in the piloting and prototyping stages as the number of services, processes and the number of service/process invocations is low and can be managed manually. The problem comes up when the application moves into production when the scale increases tremendously and it is often too late to fix and could delay or even derail the project. Dealing with such issues, problems related to SLAs, security and compliance when there are potentially millions of service/process requests is time consuming, labor intensive, error prone and often nearly impossible.

Similarly, it is important to have design-time governance to ensure that there is control over various SOA artifacts being used across teams, departments and geographies. This ensures that services are tested and approved, versions of services are maintained, dependencies are tracked are changes are notified and access control is enforced. Absence of design-time governance, particularly in a medium to large projects, could lead to a chaotic environment and likely delays and failure.

About the Author: Kalyan Kolachala is the CEO and Managing Director, SOAMatrix, a fast-growing privately held company focused on Service Oriented Architecture (SOA) product development and associated solutions.
He can be reached at kalyan@soa-matrix.com.