SOA and business architecture


Written on Thursday, June 15, 2006 by Gemini

One area where SOA has been gaining ground is in its power as a mechanism for defining business services and operating models and thus provide a structure for IT to deliver against the actual business requirements and adapt in a similar way to the business. The purpose of using SOA as a business mapping tool is to ensure that the services created properly represent the business view and are not just what technologists think the business services should be. Within this area, the first SOA method was announced in 2004 Service-oriented Modeling and Architecture (SOMA).

Since then the work has moved towards greater standardisation, paticularly within the OASIS standards group paticularly the SOA Adoption Blueprints group, recently this has included the contribution of an open methodology for Service Architecture which focuses on the business service part of the process. All of these approaches take a fundamentally structured approach to SOA, focusing on the Services and Architecture elements and leaving implementation to the more technically focused standards.

SOA design and development
The modeling and design methodology for SOA applications has become known by the terms service-oriented analysis and design and SODA. The SOA functions as much as a software development framework as it does as a delivery framework. In order for a SOA environment to operate successfully, software developers need to orient themselves to its mindset of creating common services which clients or middleware then orchestrate to implement processes.

Development of systems using the SOA requires a commitment to this model in terms of planning, tools, and infrastructure. When most people speak of a service-oriented architecture, they speak of a set of services residing on the Internet or an intranet using "Web services." A set of standards exists which generally feature in all discussions of Web services. These standards include the following:

  • XML
  • HTTP (or HTTPS)
  • SOAP
  • WSDL
  • UDDI
Note, however, that a SOA does not necessarily need to use any or all of these standards to become "service-oriented. "In general, SOA is behind the scenes, not visible to the users. SOA is fronted by a client UI, and end users only see the Client UI. In other words, there is no SOA without clients using it. As such, SOA is an enabling technology, behind the scenes, waiting to be used.

Why SOA?
Enterprise architects believe that SOAs help businesses respond more quickly and cost-effectively to the changing market conditions they may face by promoting reuse of existing IT assets rather than more time consuming and costly reinvention.

In some respects, SOA can be considered an evolution in architecture, not a revolution. It captures many of best practices or actual use of the architectures that came before it. To talk in terms of a service-oriented architecture provides a good framework from which to build the dynamic solutions required today. In communications systems, for example, there has been little deployment in recent years of solutions that use truly static bindings to talk to other equipment in the network, but by formally embracing a SOA approach, solutions are better positioned to stress the importance of well-defined, highly interoperable interfaces. This should greatly decrease integration costs and allow for much more dynamic solutions to be deployed.

Source: Wikipedia

If you enjoyed this post Subscribe to our feed