SOA: Where to Begin

Think big, Start small, Scale fast.

SOA is evolutionary, not revolutionary. While it may be tempting to begin with a vision of business processes effortlessly orchestrated through a point-and-click interface, the reality is that most IT environments have valuable IT assets already in place, and have complex processes that cannot be disrupted. The transition to the point-and-click vision relies on a solid foundation of services technology that is standards-based and adaptable to the realities of existing IT environments and operations.

The principles are simple:

Take an incremental approach

Take an incremental approach to service-oriented architecture (SOA), both technically and financially. When architects consider the functionality needed to support a SOA including transportation, transformation, security and management, they see that most of what they need to create a SOA is already in place. Avoid large upfront investments and work with what is paid for and deployed:

  • Step #1 - Use existing infrastructure components - do not rip and replace existing systems which can lead to major disruption of operations and introduce errors; keep existing transport, security, and management systems in place and incorporate them into the SOA
  • Step #2 - Service-enable back-end systems on demand - start with a project that has a measurable return but poses no great business risk and service-enable everything from back-end mainframes to mobile devices and gradually create a network of services
  • Step #3 - Add QoS on demand - support for new technology and integration services such as security, enterprise management and high availability should be added incrementally as need dictates, alleviating the pressure to implement all features up front

Create smart, dynamic and adaptable endpoints

Examine the extensibility of all new infrastructure investments. Artix, for example, facilitates change by extending service capability using a dynamic plug-in architecture. Each service endpoint can evolve independent of one another rather than forcing changes in a centralized server or hub. Transformations, security, transport protocols and services management can be incrementally and dynamically added as required.

Artix distributed architecture enables agility

Artix distributed architecture enables agility

Development teams can use plug-ins to address:

  • New QoS and enterprise policies - new policies, including security and management measures, are handled by plug-ins at the endpoint. This eliminates the need to create yet another server or technology stack.
  • New systems - as additional systems come online, they often introduce new interfaces and unique requirements that stress inflexible infrastructure. Plug-ins provide compatibility locally so as not to disturb other development teams.
  • New standards and technology - there will always be new data models, protocols, and infrastructure products that force changes to middleware. Rather than add a new layer of adaptors, plug-ins allow the infrastructure to efficiently support to new requirements.

Stay technology-neutral

A SOA is never built from a single technology, so be sure that any service can be made compatible with any existing or future platform, protocol, data model, or transport. IT architects should not have to force development teams to standardize on a single set of technologies or to deploy common middleware at every service endpoint. By relying on plug-ins at the endpoint instead of a centralized server, IT can support:

  • Any transport system - most enterprises have a transport system currently deployed, and unilateral replacement destabilizes operations. Plug-ins support any transport system - from TIBCO to HTTP to MQ to JMS among others - so organizations can apply the value-add of Artix to existing infrastructure, and project teams are free to deploy the transport system of their choice for new projects.
  • Any transaction - most SOA transactions are "fire and forget" in nature, but many enterprise transactions require the ACID reliability of 2-phase commit and still others require the performance of a point-to-point connection. Transaction management plug-ins support any type of transaction so corporations do not have to choose between good architecture and application requirements.
  • Any payload format - XML has many useful attributes, but forcing applications to convert data into XML slows performance and can introduce errors. Plug-ins allow data to be sent in any format, including binary, simply by adding a plug-in to any endpoint that receives the payload.
  • Any security, management, or platform tool - to further preserve the autonomy of back-end systems, make sure any security standard, system management suite, or development platform is supported at individual endpoints rather than forcing all applications to adhere to the same configuration.
  • Any platform - any platform, including mainframes, Java platforms and containers should all be able to participate in any process as equals.

These principles will lead to a successful SOA, and the creation of a variety of solutions.

IN SOA Overview...

Build Your SOA

Need More Info?

Feel free to reach us by phone or email anytime of the day.

> View Phone Numbers
> Contact Us Form

Contact Sales

For pricing and license information please contact a sales representative in your region:
AMER, EMEA or APAC