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?
The reference architectures of the past (i.e. client-server, web application, SOA services) are not adequately addressing current business demand, use cases, and expectations. IT must update reference architecture models to remain relevant and effective.
Often outdated processes, tools, and skills inhibit IT’s ability to be a strategic enabler and gain an IT business edge. By adopting a new, Responsive IT delivery model based on an updated reference architecture, teams can foster effective business collaboration, responsive iterations, streamlined processes, and no wait states; enabling business to operate at the speed of now.
What reference architecture goal-state is required to meet business demands and expectations?
A reference architecture should enable internal and external business service consumers, address future IT strategies, and transition current IT infrastructure and team skill sets. Do you have a seven step plan describing how to reshape your reference architecture?
A three part slideshare series outlines why reshape reference architecture, what reference architecture models make sense today, and how to reshape reference architecture.
Service Oriented Architecture initiative success requires creating loosely coupled consumer-provider connections, enforcing a separation of concerns between consumer and provider, exposing a set of re-usable, shared services, and gaining service consumer adoption. Many teams find a SOA or REST focus may not improve IT agility, but result in simply swapping out IT toolsets, message formats, and protocols.
SOA Governance mitigates risk in failing to deliver the [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.
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.
To accelerate agility and increase time to market, a Connected Business relies on accessible and integrated business capabilities. A leading edge integration platform can reshape your enterprise integration architecture and create an integration environment where project teams can easily and rapidly connect, re-use, and compose data, APIs, and services into effective business solutions.