Tag Archives: Service Oriented Architecture

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.

 

Promoting Service Reuse and Maximizing SOA Success

API management complements SOA Governance, drives service reuse, and maximizes Service Oriented Architecture success.  Many development teams publish services, yet struggle to create a service architecture that is widely shared, re-used, and adopted across internal development teams. SOA governance programs often fall far short of encouraging consumer adoption, tracking service consumption, and illustrating business value. Too often, there is little or no insight into service reuse and:

  • How to enable business functionality as an API
  • Who is writing re-usable APIs and services
  • Who is consuming APIs and services
  • How APIs and services are being used

Continue reading

ESB Comparison

Can an eight year old product category, which is hotly contested by every middleware vendor, deliver unique and differentiating product offerings?   When performing an ESB comparison, you will notice almost all Enterprise Service Bus products support enterprise integration patterns, deliver all required ESB features (i.e. web services, message transformation, protocol mediation, content routing), and offer a graphical development workbench.   When technical evaluations focus on core performance and quality of service (i.e .reliability, availability, and scalability), proof of concept workloads must closely mirror expected production profiles and the evaluation effort ideally includes vendor participation.

Continue reading

Re-invent Software Delivery and Offer Your Business as a Service

As business leaders focus on growth during 2012, they are identifying business expansion and transformation opportunities.  The resulting IT mandate to rapidly evolve mobile and social interactions is forcing CIOs to re-invent their software delivery.  By following a straightforward four-step plan, CIOs can improve productivity, enhance agility, deliver timely solutions, and help fulfill strategic business growth goals.

Continue reading

Progress Sonic to Exit Middleware Market

In John Rymer’s recent blog post, Progress Software Lowers Its Sights, he breaks the news that Progress is divesting perceived ‘non-core’ middleware products.  On the selling block are Progress Sonic ESB, Savvion BPM, Actional services management, and FuseSource.  Progress’ recent strategy shift places Sonic ESB, Sonic MQ, and FuseSource implementations at risk of obsolescence.  The list of probable acquirers could mean product termination and forced migration.

Continue reading

How to pick an ESB? An Enterprise Service Bus Evaluation Framework

All Enterprise Service Bus (ESB) products may be used to build and deploy services, encapsulate legacy systems, route messages, transform message formats, and perform protocol mediation.  Many WSO2 prospects ask me ‘What differentiates WSO2 Enterprise Service Bus?’  This blog post shares my perspective and scales the conversation.

Continue reading

WSO2 API Management Platform Re-invents Software Delivery

Ten years after the rise of Service Oriented Architecture, many organizations have identified and published services as shared assets, however teams and partners often continue to invest considerable time and resources when building new solutions.  Many teams experience rapid portfolio proliferation and sprawl, but not enhanced portfolio efficiency or business agility.  Achieving business agility requires the growth of development partnerships and interactions, which should span both internal and external teams.

Traditional SOA and integration platforms enable rapid development, but they provide little business partnership support.  Teams commonly operate independently and autonomously.  Hundreds of people write new APIs and services; few people know:

  • who is consuming APIs and services,
  • who is writing re-usable APIs and services, or
  • how APIs and services are being used.

Continue reading