During the SOA craze days in the past, 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.
While everyone acknowledges API and Service Oriented Architecture (SOA) are best practice approaches to solution and platform development, the learning curve and adoption curve can be steep. To gain significant business benefits, teams must understand their IT business goals, define an appropriate SOA & API mindset, describe how to implement shared services and popular APIs, and tune governance practices.
Cloud API popularity is fueling interest in creating service ecosystems across organizations, teams, and applications. By externalizing software platform functions from containers, operating systems, and on-premise data center environments, new business opportunities emerge, and development teams gain faster time to market when building scalable business solutions. Is the time right for you to build a cloud ecosystem architecture based on APIs and supporting rapid application development?
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.
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.