Home / CA Gen Solutions / Service Oriented Architecture (SOA)
Service Oriented Architecture (SOA)2017-06-29T13:39:05+00:00

Service Oriented Structure (SOA)

EXPLORE OUR SCOPE

Making Software Components Freely Interchangeable, Reusable, and Loosely Coupled

SOA for CA GenService Oriented Architectures (SOA) provide clear business benefits by making software components freely interchangeable, reusable, and loosely coupled. Because SOA isn’t something you buy off the shelf, the implementation of a SOA can be daunting.

This does not have to be the case. There is a clear, step-by-step path for any company to move to an SOA. In designing and implementing Service Oriented Architectures for more than 10 years, QAT Global Consultants have developed the skills and experience to put you on the right path. If you’re considering the advantages of SOA, but aren’t sure what steps to take, consider a QAT Global Architecture Review.

In a general sense, the movement from a traditional application environment to an SOA involves five fundamental levels of SOA maturity. The first level of maturity in SOA implementation is Service Enablement. In this phase, you need to break your application infrastructure into modular components, which will form the building blocks of your SOA. Many of your components may already be modular, so this may simply be a matter of formalizing the interface definitions. Other applications may require several method calls or CICS transactions be assembled to form a single Service module. Other application services will require complete building. In addition to being modular, Services in an SOA should be “accept and return” self-defining data structures (i.e. SOAP) and use standards-based protocols (i.e. HTTP) wherever practical. This may mean adding wrappers around existing application components to give them standards-based interfaces or building new standard based services.

Perhaps the most difficult aspect of the first level of SOA is determining exactly which protocols and data structures are “Standard.” If you allow too few standards, then you will need to write wrappers for virtually every application, slowing your SOA development and reducing its flexibility. On the other hand, if you allow too many standards, you can create a maintenance nightmare since each protocol requires administrative maintenance and there is little or no coherence in your data structures. Thus, it is quite important to define a clear set of enterprise protocol and data structure standards as well as the governance procedures to add standards to and remove standards from this set.

As your organization develops and defines more services, the threshold is usually 40-50 services, disparate requirements for data structures and protocols of the services make it difficult to have the services all communicating directly with each other, and the effort to wrap every service with matching protocols and some form of generic superset data structure becomes unmanageable. To decouple the data structure and protocol for the service interfaces, it is normal practice to develop an Enterprise Service Bus (ESB) consisting of a set of Mediation Services that perform translation between different data structures (data transformation) and protocols (protocol conversion), keeping specific interface dependency on other services out of your core business services.

Completion of an ESB provides your organization with an extremely flexible set of services that can be used freely by any client. Since an ESB intentionally does not supply any form of control over which services are called by which other services and in which order, most organizations go on to add a set of Orchestration Services to control this flow. This allows business analysts to develop abstract process models with languages like Business Process Execution Language (BPEL). Such Process Modeling is typically the first step in implementing this third level of an SOA. The underlying ESB allows the actual processing details of the target service to be isolated from the Orchestration Services. The technical implementation of the Orchestration Service then consists of providing an Orchestration runtime that can interpret the process model and then binding individual activities in the process to the Services that will execute them.

The real business benefit of an SOA comes not from the potential to reuse services and perform internal service updates without affecting others, but from actually doing these things with your SOA. In order to do this, you need to gather objective information about the performance and availability of your actual services to identify bottlenecks, select targets for improvement, and judge the business effects of changes to underlying services. Such Service Management is critical to getting a clear return on your SOA investment. Further, to encourage reuse, you must document dependencies both of and between services and store such dependency metadata along with the Service Level metadata discussed earlier into a commonly accessible and searchable repository and define procedures to update that data. It is this formal SOA Governance that marks the fourth level of SOA maturity.

Finally, the development of an SOA is not a one-way journey, but the establishment of a sustainable lifecycle that leads to continuous business process improvement. To get the most out of an SOA, you must put governance procedures into place not only to measure the performance and availability of your services, but you must have defined and clear procedures for making business decisions based on the information that is gathered. Thus, process modeling allows process measurement, which allows process improvement planning directly in the modeling tool allowing the cycle to repeat.

The QAT Global SOA Solutions include:

SOA Architecture Review

Service Oriented Architectures provide clear business benefits by making software components loosely coupled (changing one does not affect all of the others), reusable, and freely interchangeable. Because an SOA isn’t something you buy off the shelf, the implementation of an SOA can be intimidating to many organizations.

QAT Global can provide a clear, step by step path for any enterprise to move to an SOA. In working with our customers on Service Oriented Architectures for more than 5 years, QAT Global Consultants have developed the skills and experience to put you on the path. If you aren’t sure about what steps to take to get to your SOA goal, please consider a QAT Global Architecture Review.

SOA Architecture Review deliverables:

  • A document describing your organization’s current readiness for a Service Oriented Architecture including an assessment of the modularity, self-definition, and standards compliance of your core business applications.
  • A proposed SOA Reference Architecture with supporting documentation.
  • Identification of one or more business processes suitable for a SOA Pilot project.
  • Implementation plans for integrating existing core business applications into a SOA including time estimates, levels of effort, and formal project plans for the initial phase.
  • Listings of recommended hardware and software for SOA implementations.
  • Knowledge transfer to architects on SOA design and implementation principles.

SOA Architecture Review prerequisites:

  • You intend to implement a SOA.
  • Architects, current application owners, and managers are available for discussion and knowledge transfer.

Duration: 2 weeks and up depending upon the scope of the architecture review.

SOA Service Enablement

The first level of maturity in SOA implementation is Service Enablement. In this phase, you break your application infrastructure into modular components to form the building blocks of your SOA. Many of your components may already be modular, so this may simply be a matter of formalizing the interface definitions. Other applications may require several method calls or CICS transactions be assembled to form a single Service module. Other application services will require complete building.

In addition to being modular, Services in an SOA should be “accept and return” self-defining data structures and use standards-based protocols wherever it is practical. This may mean adding wrappers around some existing application components to give them such standards based interfaces. Note: if you find you are doing too much of this, you may be ready for SOA level 2 — Building an Enterprise Service Bus.

Service Enablement deliverables:

  • A document describing policies and procedures for service definition including Web Services Description Language (WSDL) documents as well as metadata for services beyond the scope of WSDL.
  • Formalization of service definitions for existing Services as WSDL files where practical or according to internal metadata standards where out of scope for WSDL.
  • Development of Composite Service Assemblies exposing sets of non-modular calls (e.g. CICS transactions or method invocations) as modular Services.
  • Code and interface definitions for new Services where applicable.
  • Code new standard based Services where applicable.
  • Training plans for developers and architects dealing with SOA.
  • The QAT Global Consultant will provide knowledge transfer related to Service Development to your architects, project managers, and developers.

Service Enablement prerequisites:

  • A defined scope for service enablement and descriptions of existing and proposed business applications being integrated into the SOA within this engagement.
  • Architects and project managers are available for project planning and knowledge transfer.

Duration: Highly variable according to project scope.

SOA Standards Evaluation

Perhaps the most difficult aspect of the first level of SOA is determining which protocols and data structures are “Standard.” If you allow too few standards, you will need to write wrappers for virtually every application, slowing your SOA development and reducing its flexibility. On the other hand, if you allow too many standards, you can create a maintenance nightmare since each protocol requires administrative maintenance and there is little or no coherence in your data structures. Thus, it is important to define a clear set of enterprise protocol and data structure standards as well as the governance procedures to add standards to and remove standards from this set.

Architecture Review deliverables:

  • Inventory documentation of protocols and data structures currently in use in your organization.
  • Recommendations document describing proposed protocol and data structure standards for integration appropriate to your organization.
  • Document describing procedures for addition, deprecation, and retirement of particular protocol and data structure standards.

Architecture Review prerequisites:

  • Information on existing applications within the scope of the inventory is available for the project.
  • Appropriate personnel including application owners, developers, and architects must be available for meetings and discussion.

Duration: Highly variable according to project scope.

SOA Mediation Development

As your organization develops and defines more services, the threshold is usually 40-50 services, the disparate requirements for the data structures and protocols of the services make it difficult to have the services all communicating directly with each other. The effort required to wrap every service with matching protocols and some form of generic superset data structure becomes unmanageable.

To decouple the data structure and protocol for the service interfaces, it is normal practice to develop an Enterprise Service Bus consisting of a set of Mediation Services that perform translation between different data structures (data transformation) and protocols (protocol conversion), keeping specific interface dependency on other services out of your core business services.

Mediation Development deliverables:

  • Well-written and documented mediation services.
  • Deployment and testing of the developed mediation services in the specified Enterprise Service Bus.

Mediation Development Prerequisites:

  • Operational Enterprise Service Bus (ESB).
  • Documentation of data structures and protocols of endpoint services to be mediated exists and is available. Such documentation may be WSDL files or any agreed metadata format including, but not limited to COBOL copybooks, XML Schema/DTD, C Header files, industry standards (SWIFT, EDI, XML, SOAP…) for data structures and JMS, TIBCO, and/or MQ Queue/Topic definitions or HTTP URLs for protocols. If you do not have such definitions, consider a QAT Global Service Enablement engagement.

Duration: Highly variable according to project scope.

SOA Processing Model

Completion of an ESB provides your organization with an extremely flexible set of services to be used freely by any client. Since an ESB intentionally does not supply any form of control over which services are called by which other services and in which order, most organizations go on to add a set of Orchestration Services to control this flow. This allows business analysts to develop abstract process models with languages like Business Process Execution Language (BPEL).

The underlying ESB allows the actual processing details of the target service to be isolated from the Orchestration Services. The biggest challenge in such actions is not the technical implementation of the Orchestration Service itself, but the actual Process Modeling that determines the steps to be taken by the Orchestration runtime.

Process Modeling deliverables:

  • Well-documented BPEL based models for the specified business processes according to your requirements.
  • Knowledge transfer on technical Process Modeling to selected business analysts.

Process Modeling prerequisites:

  • An existing BPEL-based process modeling tool or plan to acquire one before the completion of the project.
  • Owners of the business processes and/or business analysts with knowledge of your internal processes are available for discussion with the consultant.

Duration: Highly variable according to project scope.

SOA Orchestration Implementation

Completion of an ESB provides your organization with an extremely flexible set of services to be used freely by any client. Since an ESB intentionally does not supply any form of control over which services are called by which other services and in which order, most organizations go on to add a set of Orchestration Services to control this flow. This allows business analysts to develop abstract process models with languages like Business Process Execution Language (BPEL).

Such Process Modeling is typically the first step in implementing this third level of an SOA. The underlying ESB allows the actual processing details of the target service to be isolated from the Orchestration Services. The technical implementation of the Orchestration Service then consists of providing an Orchestration runtime that can interpret the process model and then binding individual activities in the process to the Services that will execute them.

Orchestration Implementation deliverables:

  • Process implementations deploy and tested on based upon supplied BPEL models
  • Knowledge transfer on Orchestration Implementation and Service Binding.

Orchestration Implementation prerequisites:

  • You have BPEL-based models accurately describing the processes to be implemented. If you do not already have such models, see QAT’s Process Modeling engagement.
  • You have an existing operational SOA Orchestration Server environment and fundamental knowledge of its operation. If you do not have such an environment, QAT Global will help you decide and implement an operational Orchestration Server.
  • System administrators and Orchestration Server administrators for the target Orchestration Server system are available to the consultant to provide logins and necessary system resources.

Duration: Highly variable according to project scope.

SOA Management

The real business benefit of an SOA comes not from the potential to reuse services and perform internal service updates without affecting others, but from actually doing these things with your SOA. In order to do this, you need to gather objective information about the performance and availability of your actual services to identify bottlenecks, select targets for improvement, and judge the business effects of changes to underlying services.

Service Management is critical to getting a clear return on your SOA investment. To encourage reuse, you must document dependencies both of and between services and store such dependency metadata along with the Service Level metadata discussed earlier into a commonly accessible and searchable repository and define procedures to update the data.

SOA Management Review deliverables:

  • Document detailing existing management environment including current alerting and notification procedures, environment visibility and operations procedures, performance analysis and reporting procedures.
  • Document detailing recommended alert conditions for problem management.
  • Document detailing recommended dashboard configurations for each critical job role.
  • Document detailing recommended historical data collection for reporting and performance management
  • If you have existing business process documentation, a document detailing touch points for transaction management. If you have no such documentation, consider a QAT Global Process Modeling engagement.
  • Knowledge transfer on SOA Management principles to architects, project managers, and operations staff.

SOA Management prerequisites:

  • An existing Service Oriented Architecture with well-defined services. If you are not comfortable with the clarity of your existing definitions, a QAT Global Service Enablement engagement can help you.
  • If you wish to perform transaction level management, you should have process models (may be diagrams or formal technical models such as BPEL). If you have no such documentation, consider a QAT Global Process Modeling engagement.
  • Appropriate architects, business process owners, and operations staff should be available to the consultant for discussion.

Duration: Highly variable according to project scope.

SOA Governance

The development of an SOA is not a one-way journey, but the establishment of a sustainable lifecycle, which leads to continuous business process improvement. To get the most from your SOA, you must put governance procedures in place to measure the performance and availability of your services, and you should have defined and clear procedures for making business decisions based on the information gathered. Process modeling allows process measurement, which allows process improvement planning directly in the modeling tool, allowing the cycle to repeat profitably.

SOA Governance Review deliverables:

  • Findings document detailing existing:
    • Service lifecycle
    • Source control, and promotion standards
    • Service interface definition standards
    • Data structure and protocol standards for SOA
    • Service Level Agreement, or Objective development, documentation, and enforcement procedures and policies
    • Security policy development and enforcement procedures
    • Technical risk management policies and procedures
  • Recommendations document describing to-be state for all items above including, but not necessarily limited to:
    • Definition of proposed Service Lifecycle
    • Transition procedures and criteria for all lifecycle transitions
    • Implementation plan for source control system if not existing
    • Policy for service interface documentation
    • Enterprise data structure and protocol standards documentation
    • Procedures for adoption, deprecation, and retirement of data structure and protocol standards
    • Policy for Service Level Agreement (SLA) documentation.
    • Policy for SLA compliance measurement
    • Procedures for SLA compliance and performance improvement
    • SOA security policies for authentication, data encryption, and access control
    • Technical risk assessment policies and analysis procedures

SOA Governance prerequisites:

  • Appropriate architects, business process owners, and managers should be available to the consultant for discussion.

Duration: Highly variable according to project scope.

Build Your Own SOA Engagement

It’s clear that Service Oriented Architectures (SOA) provide clear business benefits by making software components freely interchangeable, reusable, and loosely coupled. But since SOA isn’t something you buy off the shelf, having the right partner to assist you with the implementation of an SOA can turn a daunting task into a relatively painless one. The breadth of QAT’s knowledge of SOA in general and our vendor neutral approach, in particular, gives us the flexibility to solve your problems the way YOU want them solved.

Remember, the development of an SOA is not a one-way journey, but the establishment of a sustainable lifecycle that leads to continuous business process improvement. Get started by following the clear, step-by-step path we have set forth to assist any company to move to an SOA.

Email or call us describing the project you have in mind, and we’ll work with you.

For QAT Global Consulting Services call 402-391-9200 or email: sales@qat.com

Why QAT Global?

Our approach to SOA is founded on our practical experience in building working products and solutions for enterprises across the globe. We help enterprises make the right technology decisions at various levels in the IT decision-making process. QAT Global can execute these decisions to manage and implement working solutions against our recommendations.

QAT Global Can Help – Start the Conversation Today with a Discovery Session >>

Let’s Talk
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Accept