Paul Kalin

Subscribe to Paul Kalin: eMailAlertsEmail Alerts
Get Paul Kalin: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: SOA & WOA Magazine

SOA & WOA: Article

SOA Adoption Models

Ad hoc versus program-based

Enterprises today face increasing IT complexity and cost due to the natural evolution of the application infrastructure. Business is demanding more flexible and sophisticated solutions for discrete business functions that can adapt with evolving market demands and business processes. The need for integration infrastructure has resulted in a legacy of patchwork enterprise application integration (EAI) approaches that have hardwired enterprises for particular business functions and increased IT complexity. However, there is promise that this detrimental trend will reverse through the adoption of Service Oriented Architectures.

The Service Oriented Architecture (SOA) community promotes agility, interoperability, asset reuse and re-factoring and greater information insight. But why are some organizations claiming huge successes and demonstrable ROI while others cite failed SOA projects and question the value of the technology itself? SOA has been around long enough now that we know success is not a question of whether SOA is adopted, but rather, how it is adopted. Adoption approaches vary and will determine the resulting value of SOA to the enterprise.

SOA can provide real dollar savings and increased business opportunity or unplanned (ad hoc) adoption can result into more complexity, increased cost to maintain the levels of SLA, and reduced transparency across applications.

This article discusses the reality of why SOA is already upon us regardless of desire, need, or plan. The value that SOA can yield depends on the maturity of adoption from multiple perspectives: the level of maturity across people, processes, and technology dimensions is directly related to the realized benefits. SOA maturity, however, cannot be achieved accidentally.

Three typical adoption models are observed in the industry today: ad hoc, organic, and strategic. For those enterprises interested in the high value of SOA, this article shows how the ad hoc model cannot be successful. To achieve high value, recommendations are made on how to establish a SOA program through either organic or strategic adoption models.

Business Challenges
SOA is a business-driven technology paradigm that paints a broad brush across several business drivers (see Table 1). SOA is a set of principles, best practices, standards, and tools that finally provide realization of the business mantra - "do more with less - better, faster, cheaper." The competitive and shifting marketplace is putting heavy demands on technology. SOA is evolving out of need, not desire. It is evolving out of the need, not the desire, to address drivers such as those listed in Table 1.

Lower cost to create new product offering and solutions

Improve flexibility of applications to quickly adapt to changing market demands

Improve time-to-market to gain a "first to market" competitive advantage

Improve operational efficiency - more automation - more process support

Greater business insight - the ability to track business and IT measures

Align business and IT - satisfy stakeholders

Improve the quality of information and services

Get better return on existing IT assets

Table 1: Example Business Drivers for SOA

Typical IT departments struggle to address these business drivers with traditional technology approaches. Table 2 lists some common IT barriers that we have encountered in our client engagements. Without an appropriate level of intervention, it will continue to compound and become exponentially worse over time. This will further isolate business and its IT counterpart.

Inconsistent standards and architecture increases maintenance and development costs.

Redundant data across the enterprise causing multiple inconsistent views of information and costly maintenance for structural changes.

Redundant business logic resulting from little functional reuse results in redundant and costly work efforts for addressing business needs.

Low level of functionality reuse resulting in proliferation of redundant code.

Hard-coded business rules throughout diverse code bases.

Point-to-point nature of integrations limits scalability and tightly couples applications resulting in an inflexible "hardwired" solution.

"Workflow" logic untraceable and spread across many disconnected code modules resulting in costly change.

Latency introduced throughout processing causes data mismatch and untimely delivery of information. Complexity is further increased due to reconciliation requirements increasing the cost of maintenance and development and reducing the flexibility of the solution.

Table 2: Typical IT Barriers to Business

SOA will form the underpinnings of the next generation of architectures that will address business drivers and remove many of the IT barriers through reusable, distributed, loosely coupled services that are accessed through stable, well-defined interfaces. The characteristics of SOA are:
• Information is made available through independent and atomic components called services
• Service reuse and consumption is facilitated through a registry where services are described through standard message formats and protocols
• Self-describing messages travel from component to component independent of platform
• Systems and components are loosely coupled - they don't know much about each other, thus provide an opportunity for interchangeability
• Services and composite applications use standard mechanisms for communication wherever possible
• Business applications own as few resources as possible, leveraging shared assets such as schemas, common components, and service libraries fostering common understanding at an enterprise level

SOA is not a single technology stack or a magic bullet. It can be implemented in many ways (e.g., EAI, ESB, Web Application Server, etc.).

While many businesses are struggling with the question of whether or not to adopt SOA, the reality is that adoption is inevitable and probably already happening. SOA has been endorsed by every major software vendor. The once-proprietary black boxes of domain-specific applications are being exposed through open and standard interfaces/services. Middleware vendors, once selling EAI products or application containers, are now marketing SOA platforms or service containers. Even the major database vendors are facilitating service-based data access. Natural upgrade paths of existing IT infrastructure and systems will introduce new service-oriented technologies into the enterprise. While the openness of SOA is a generally positive architecture trait, introduction and integration without proper coordination will yield negative effects.


More Stories By Alkesh Shah

Alkesh Shah is a director at Keane Architecture Services.

More Stories By Paul Kalin

Paul Kalin is senior principal enterprise architect at Keane Architecture Services.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.