Tag Archives: Service Oriented Architecture

API commons

Service Portfolio is [A] in SOA

A key SOA end-goal is a service portfolio exhibiting a clean architecture. Technical and industry vertical business domain models are useful starting points for development of an organization’s unique service portfolio. Service design and interface design are small pieces in a larger set of programs that must be managed in order to establish highly effective IT service delivery, collaboration, and trust.

Continue reading

SOA Perspective and API Echo

The SOA perspective is reverberating into an API echo. During past SOA craze days  (2003-2008), proponents pitched SOA’s lofty benefits from both business and technical perspectives.   The benefits are real, yet sometimes very difficult to obtain. Surprisingly, today’s API proponents target similar benefits, but with an execution twist.

Continue reading

Defining a Service Oriented Architecture (SOA) Mindset: Big SOA or Small SOA

How would you define your team’s Service Oriented Architecture (SOA) mindset and the value you derive from Big SOA or Small SOA approaches?

Defining SOA

Service oriented architecture (SOA) represents a significant paradigm shift in application development techniques. SOA is a software design discipline in which application and infrastructure functionality are implemented as shared, reusable services. Each service implements a discrete task, and any application that needs to perform the task uses the shared service to do so. Teams create applications by assembling the appropriate services. After teams implement business functionality as services, an organization, their partners, and their customers should be able to mix and match these services and rapidly create new applications to support changing business requirements.

Because SOA presents an architectural goal state at odds with a long-lived legacy IT portfolio, SOA is a long-term architectural journey, and not a short-term implementation initiative.  Because APIs interconnect business capabilities inside and outside the organization, APIs can provide a platform for business stakeholders sponsoring enterprise IT renewal and pragmatic business execution.

 

The last ten years of SOA promotion, implementation, and evaluation have cultivated two distinct ways to approach SOA; Big SOA Mindset and Small SOA Mindset.

Continue reading

Change your IT Value Proposition: Build the Plan, Work the Plan

Looking to reshape your IT value proposition, and feel legacy application platform, service infrastructure, or integration infrastructure is holding you back? Let’s talk about how the WSO2 advantage can transform your projects’ experience.    What our your goals, challenges, and constraints?

When building a plan for 2014, consider:

  • Re-shape Enterprise Architecture
  • Re-invent the Integration Platform

 

Continue reading

Application Services Governance requires more than a SOA Registry

All SOA infrastructure products should participate in managing, storing, deciding, or enforcing policy.  More than a SOA Governance registry is required.  Application Services Governance Platforms provides advanced policy management capabilities across design-time, run-time, security, and lifecycle management focus areas.

Continue reading

Open Source SOA or Open Source ESB

Many teams are actively refreshing their integration platform and evaluating open source ESB (Enterprise Service Bus) capabilities and benefits.  Fewer are evaluating their SOA strategy and establishing open source SOA (Service Oriented Architecture) platform infrastructure, metrics, and measurements required to guide teams towards agility and responsiveness.

Continue reading

Sonic, Savvion, and Actional sold

Progress Software recently unloaded Sonic, Savvion, and Actional to a niche enterprise software development company, Trilogy Software.     Recognizing the poor brand fit between enterprise software development and enterprise application middleware,  Trilogy will form a new entity, Aurea Software, to re-introduce the acquired portfolio into the market.

According to the press release, Scott Brighton, Aurea’s new CEO, will focus the company on a goal

“to take these market leading, enterprise-class products and place a renewed focus on creating the next generation iBPMS – with a specific emphasis on enabling critical, high-value business processes in key vertical markets.”

According to Jim Snur at Gartner, an iBPMS:

“allows organizations to have more intelligent processes that can be aimed at better operations minimally and innovative processes easily. The iBPMS does this by enhancing a businesses situational awareness by seeking patterns of interest, enabling quicker / more effective decisions through poly-analytics and rapid adaptation for appropriate actions through flexible processes”

Source: Gartner Blog Network

 

An iBPMS focus is significantly different from the legacy standalone product lines focus on

  • Develop high-quality, service-based applications
  • Minimize downtime
  • Service-oriented architecture (SOA) and enterprise messaging
  • Rapidly and flexibly integrate services and applications across the enterprise

We will see if Progress’ decision to divest their on-premise integration portfolio was “the right thing for our customers and our partners that rely on them.” as stated by Progress VP Colleen Smith.  How Aurea’s corporate focus will serve current customers using Sonic ESB or Sonic MQ as the cornerstone for their integration platform or SOA strategy remains to be seen.  Whether development teams will embrace multiple best-of-breed vendors for iBPMS, aPaaS, iPaaS functionality also remains an open question.

As mentioned in the April Forrester and Gartner notes, the time is now to:

  • Develop an exit strategy and limit new investments in Sonic and Actional products
  • Implement exit strategies and reduce integration project investment on Sonic and Actional products

WSO2 stands ready to assist you in migrate away from legacy products and embrace open source innovation.   WSO2 is the only open source company that has been industry recognized for delivering enterprise-ready middleware platforms spanning integration, service oriented architecture, application, and business process platform.  Enterprise development teams use WSO2 enterprise middleware platforms to build traditional on-premise solutions or incorporate Cloud service characteristics (i.e. on-demand self-service, elastic scalability, resource pooling, consumption based pricing) and Cloud service capabilities (i.e. DevOps tooling, automated governance, service level management, metering and billing).

 

 

 

ESB use cases driving a successful ESB PoC

An Enterprise Service Bus (ESB) may serve as the cornerstone of your Service Oriented Architecture infrastructure, or you may feel an ESB is unnecessary and cumbersome. Many integration projects contain simple requirements and use cases that warrant including an ESB, integration framework, or alternative platform components in the integration solution. Selecting the appropriate solution mix requires integration reference architecture guidelines that include a comprehensive decision matrix. Team members strive to avoid complexity and inefficiency by specifying an optimal platform component mix, defining ‘the right tool for the job’, and developing scalable, agile integration solutions.

Do you have clear architecture, solution, and ESB PoC guidelines describing how your organization can wisely select integration infrastructure components and products?  Successful enterprise architects and solution architects create an integration reference architecture decision framework, ESB use cases, and product selection guidelines containing:

  • ESB use cases driving integration platform component and integration framework selection.
  • Common Request for Proposal (RFP) categories and line items.
  • Tools describing when to include an ESB, integration framework, or alternative integration platform components (i.e. Data Services Server, API Manager, Governance Registry).
Join me for a WSO2 webinar describing ESB use cases, an ESB reference architecture framework, ESB adoption patterns, and ESB PoC success stories.