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.
When crafting an API strategy and proposing API benefits, consider whether your organization is pursuing an API-Access Mindset or and API-centric Enterprise Mindset. These API approaches are similar to recognized Big SOA / Small SOA or Top-down SOA / Bottoms-up SOA approaches.
How would you define your team’s Service Oriented Architecture (SOA) mindset and the value you derive from Big SOA or Small SOA approaches?
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.
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
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.
As the technology discussion pivots to focus on APIs, teams are wondering how API and SOA converge. Are services simply being re-branded? Are APIs only good for mobile or external use cases? If we publish APIs, do we need SOA? Many architects believe that APIs do not apply to their projects or business use cases.
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.
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”
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.
- 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).
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).