Defining a Service Oriented Architecture (SOA) Mindset: Big SOA or Small SOA
Join the DZone community and get the full member experience.Join For Free
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.
big soa mindset
big soa requires organizations to scale adoption across multiple consumers by establishing a shared understanding of business and technical domains. each service is part of a bigger picture, and a well-designed service plugs into existing business processes and supports defined business requirements. effective service adoption within an enterprise require significant planning, coordination, and governance. organizations must be cautious not to let a big soa initiative fail due to analysis paralysis or inter-enterprise feudal fiefdoms.
big soa initiatives focus on enterprise governance processes, enterprise-wide re-use, and portfolio consolidation. achieving these big goals requires structurally changing design-time processes and overcoming significant cultural bias that lead to inhibiting design, accounting, control, and operational ramifications. traditional big soa initiatives can succeed, but only if top-level organizational support (e.g. c-level) overcomes organizational inertia and project teams bridge silos and operate as one team.
when tackling big soa, teams need to find an effective entry point. some teams start with an it-driven initiative or slipstream on important business-driven transformation initiatives.
an it-driven big soa approach can be very effective when focusing on building shared infrastructure services, such as security, identity, auditing, monitoring, and cloud management. these efforts can deliver rapid returns on investment, and they don’t require extensive collaboration with the business units for success. on the other hand, this approach delays engaging the business and may provide minimal return on investment (roi) recognition unless incorporated into more visible risk management, cyber-security, or customer experience initiatives.
a business-driven big soa approach is often triggered by a top-down imperative to redesign business processes and/or the customer experience. by design, these business transformation efforts must be highly coordinated across it and the various business units. when considering pursuing big soa, slipstream service portfolio investment behind funded business projects.
a big soa initiative is not a short quarterly project but a multi-year program containing several roadmap steps. to maximize and accelerate success, team embarking on big soa should incorporate a structured transformation program into their journey:
- set up a cross-functional soa working group
- develop a soa adoption plan
- define target service portfolio
- develop a business case
- plan and fund development of soa infrastructure
- establish new roles
- plan training and mentoring for staff
- develop corporate policies, guidelines, and best practices
- institute soa governance processes
- establish new incentives that reward good behavior
- identify candidate projects
- establish priorities
- reassess your software development lifecycle (sdlc)
many teams embarking on soa do not have the authority, span of control, or influence to implement required big soa activities. with big soa success unobtainable in many organizations, team members who want to ‘do soa’ and demonstrate business value often focus on small soa.
small soa mindset
a small soa approach implements soa principles on a project-by-project basis. this approach incurs less risk, but produces a smaller return. typically there’s limited coordination across projects, and small soa doesn’t require as much cultural and political unrest. using this process, the organization can slowly build a portfolio of services, but with limited coordination, the services are less likely to be reusable.
small soa initiatives often focus on run-time environment concerns instead of design-time concerns. popular run-time environment concerns include enabling flexible communication styles, interaction patterns, and mediation mechanisms that facilitate integration and promote loose coupling. example communication styles include synchronous, asynchronous, one-way, and request response messaging. commonly supported interaction patterns include peer-to-peer, brokered delivery, hub-and-spoke, publish/subscribe, and orchestrated workflow, which are used to bridge the gap between consumer-provider availability, reliability, and topology.
mediation mechanisms reduce the need to provide symmetric messaging platforms where both consumer and provider communicate using the same protocol, message format, and communication style. mediation mechanisms also encapsulate implementation details related to location, versioning, and identity domain.
adopting an it-driven small soa approach requires a cautious approach to not let the effort focus exclusively on technology rather than design, culture, and it goals. successful it-driven small soa teams promote consumer adoption stories, track service subscribers, and publicize usage growth.
a business-driven small soa approach can result in compelling singular success stories, which will encourage soa adoption. however, business asset re-use is doubtful without cross-team collaboration and promotion. uncoordinated and ungoverned project-by-project efforts can generate a chaotic situation resulting in little or no reuse. how many of your services are shared, and how many services simply facilitate point-to-point integration?
Published at DZone with permission of Chris Haddad, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.