This section covers the Q&A for SOA and the integration domain. SOA is a set of design principles for building a suite of interoperable, flexible and reusable services based architecture. This section include Q&A for SOA key capabilities, SOA ROI, SOA modernization approaches, SOA entry points, ESB, BPEL, BPM, SOA and security, SOA KPIs, OSIMM, top-down and bottom-up approaches, and SOA patterns.
Service-oriented architecture (SOA) is an architecture principle for creating flexible and interoperable service-based solutions. The key principle consists of discoverable contracts, service abstraction, loose coupling, service autonomy, service reusability, statelessness, and composability.
Rolling out successful SOA capabilities reduces IT costs by facilitating reusability in the IT landscape. SOA's ability to provide flexibility and agility to service applications reduces the time to market. SOA enables leveraging of existing IT investments by wrapping legacy solutions in reusable services.
SOA is an architectural style that enables service orientation. Service orientation is a way of thinking in terms of services and service-based outcomes.
Figure 1: SOA capabilities
The following are the benefits:
- SOA creates business and IT alignment, while lending flexibility to the IT landscape
- Market competition requires the flexibility that SOA provides as business trends change fast
- SOA facilitates the reuse of existing IT assets and new services in the IT landscape
- SOA ensures efficient integration by leveraging standardized interfaces between various services
- It defines a model for integrating business partners, vendors and suppliers into the ecosystem, thus reducing IT costs and improving the customer's journey
Probability indicator: 
SOA covers IT infrastructure, tools, and processes that enable creation of interoperable services that can be combined into meaningful processes, enabling various business scenarios. SOA provides a comprehensive suite of components for developing, securing, and monitoring applications. The following list gives the key components of the SOA stack:
|
Components |
Description |
|
Function |
A function is a business capability. Services are functions and have functions, but functions may not necessarily be services. |
|
Business service |
A business service is what a business does that has an interface and contract with consumers. A business service is supported by process, technology, and people. |
|
Information system service |
IT systems are supported by applications and are interlinked with SOA interfaces. |
|
Application component |
An application component is an independently governed entity providing IT services. They can be physical applications or logical applications grouping applications of a similar type. |
|
Technology component |
A technology component is a software or hardware entity that can be purchased, configured, combined, and deployed to produce larger solution components. |
Table 1: SOA key components
You can get more insights by looking into the diagram:
Figure 2: SOA components
Probability indicator: 
There are Excel tools for calculating ROI and these come in handy. The most common approach is to roll up your sleeves, open a spreadsheet template, and create the cost/benefit justification. Despite the extensive amount of time it will take, this may very well be the ideal approach.
The following steps describes calculating ROI for a SOA initiative:
- The process of ROI calculation for an initiative starts with defining the objectives for the SOA initiatives. These objectives are mapped to the overall SOA roadmap.
- The next step is to identify the challenges and issues in the existing IT landscape.
- Add the costs of all the initiatives in the existing IT environment, and this would be the cost that an organization is bearing without going to the SOA route. This cost also reveals returns in the future, as in our example-consolidated cost of building address update function (assume the SOA route). Or, in other words, having the same address update functionality is each application in future (assume a non-SOA route).
- Add all the costs for future initiatives. This would give a consolidated number of dollars saved because of the current initiative.
- Add these costs in a worksheet format and categorize them.
- Finally, add up the cost involved in building the initiative/project:
- ROI = Cost saving in the current systems + Cost saving in the future endeavors
- Profitability index = Return On Investment - ROI / (Total Cost of the SOA Initiatives)
Probability indicator:
There are different strategies to enable the modernization of legacy applications using SOA. Enterprises need to select one strategy and evaluate it against these strategies. The key strategies include service enablement, language conversion, re-architecting and re-hosting. The following table provides further details:
|
Strategy |
Description |
|
Service enablement |
Through services hosted by integration platforms or containers, this strategy enables access to legacy applications. |
|
Language conversion |
This approach converts applications written in legacy languages into a new language that facilitates service orientation. This works if the conversion is successful, but re-architecting may be necessary if the software is complex and interlinked. |
|
Re-architect |
This approach involves re-architecting and restructuring the business logic of legacy applications. |
|
Re-hosting of applications |
To reduce the cost of the mainframe and legacy, the majority of business-critical parts are distributed on a cloud model. |
|
Wrappers |
Legacy applications are key to any IT landscape. We need to identify discrete entities and wrap them in service interfaces to leverage in a SOA environment. |
Table 2: SOA Modernization Strategies
Probability indicator: 
SOA entry points mean the five entry points into SOA, and any of these five entry points provides an effective starting point for SOA initiatives. SOA entry points enable organizations to pursue SOA by leveraging a project-based methodology and demanding that each project must deliver business value. Each entry point provides a key SOA-related solution:
|
Entry point |
Description |
|
People |
Collaboration is improving productivity by giving employees and partners the ability to create a personalized, consolidated way to interact with others |
|
Process |
Optimizing processes and monitoring the efficiency and effectiveness of the amended processes |
|
Information |
Enhancing business insights and reducing risk by leveraging trusted information services |
|
Reuse |
Reusable services are the building blocks of SOA, which give flexibility and reduce time to market to eliminate duplicates |
|
Connectivity |
SOA connectivity has value and provides flexibility to the landscape and future SOA initiatives |
Table 3: SOA Entry Points
SOA design principles
The success of software engagements on any paradigm is not typically assured. Software developed leveraging SOA paradigm carries higher risks. This is because a service-oriented architecture usually spans multiple Business Units (BUs) and Lines of Business (LOBs) and requires elaborate and substantial groundwork initially. Hence, SOA without concrete guidelines and principles is likely to fail. To ensure that the SOA initiative delivers as per the promise, it is critical to adopt a set of principles and guidelines. Please find the list of SOA principles for designing SOA applications:
- Standardized service contract: services adhere to a service description
- Services minimize dependencies due to loose coupling
- Service abstraction hides the logic from the outside world
- Service logic is designed with the intent of maximizing reuse
- Service autonomy, that is, services control the logic they encapsulate
- Service statelessness, that is, ideally, services should be stateless
- Service discoverability, that is, services that can be discovered via a service register
- Service composability is breaking large problems into smaller problems
- Service interoperability is leveraging standards that facilitates various subscribers to use services
Probability indicator: 
Enterprise Service Bus (ESB) is a critical and core component of the SOA landscape. ESB facilitates end-to-end connectivity between services and with partners, vendors, and suppliers. This component provides routing, mediation, and transformation in the SOA environment. Depending on the goals, ESB facilitates integrating services within the SOA landscape such as business process management services or information services. ESB is leveraged to integrate different applications and IT systems in the landscape. ESB provides business connectors that facilitate different applications to interact using different technologies and protocols. The SOA reference architecture is a reusable asset that helps building SOA capabilities that meets organization's needs. ESB is a core component of this reference architecture and provides one of the key capabilities in the SOA landscape.
The following are the advantages of SOA:
- Faster and cheaper integration of landscape applications and systems
- Increased flexibility in the landscape as it is easier to modify as business requirements change
- ESB is based on industry standards and best practices
- Scalable and can be deployed as a point solutions or distributed bus enterprise-wide deployment
- Out-of-the-box components and rules that are ready for use, hence more configurable than coding
- No central broker and no central rules-engine model
- Enterprise becomes refactorable with incremental patching and zero downtime
The following are the disavantages of SOA:
- Requires a message model, resulting in additional overhead. Potential difficulties are in integrating disparate applications to collaborate through message models and standards.
- Requires continuous management of message standards' versions to ensure the benefits of loose coupling. Incorrect or incomplete management may result in tight coupling.
- An ESB requires more hardware than simple point-to-point messaging.
- Middleware competency skills are needed to manage and configure an ESB.
- Extra overhead and latency are caused due the additional ESB layer, compared to a point-to-point mechanism, and increased latency is a result of additional XML transformations.
- ESB may become a single point of failure.
- While ESB requires significant time and effort, it won't produce value without subsequent development of SOA capabilities in the landscape.
Probability indicator:
ESB is a critical and core component of any SOA. ESB provides many-to-many connectivity between applications and systems within the landscape, and also with suppliers, partners and vendors. But SOA is not just creating and managing an ESB. Depending on the business objective and goals, ESB can be leveraged to integrate systems such as BPM services, information services, interaction services, Information Technology Infrastructure Library (ITIL) services, or development services. SOA reference architecture is a key asset that will help outline an SOA capability that meets the priorities and needs of the businesses. ESB capabilities is a key component of this reference architecture and provides the backbone for SOA.
Alternatives to an ESB
- Distributed services can often be provided by application servers exposing services via point-to-point protocol web services over HTTP.
- To leverage a specific protocols, one can build a client that responds to those protocols. If the requirement is constrained to one or two protocols, it may not be worth investing in an ESB.
Probability indicator:
Business Process Management (BPM) is management of the business processes. BPM is a simple yet powerful capability that increases the effectiveness and efficiency of business processes. BPM is a combination of technology and processes that facilitates the execution and monitoring of business processes. The term workflow is synonymous with BPM but is intended for human-to-human interaction scenarios. The term "business process" represents more scenarios where IT applications and human entities inter-connect to achieve business objectives and goals.
Business Process Execution Language (BPEL) is a standard and defines interactions between applications in the landscape using XML standards. This standard is adopted by many organizations to enable application interaction but lacks human interaction. This is related to integrating applications that are exposed via web services.
Probability indicator:
Enterprises need to build business services that are inherently secure, meaning that security is intrinsic to their business processes, development, and day-to-day operations. Security has to be factored into the initial design, not bolted on later. This enables enterprises to securely adopt new forms of technology, such as cloud computing and mobile device management; and business models and IT outsourcing can be safely leveraged for cost benefit, innovation, and shortening time to market. An SOA environment needs to emphasize the following key security areas:
- Users and services identities and propagation of these across LOBs
- Seamless connectivity to enterprises on a real-time, transactional basis
- Ensuring that proper security controls are enabled for services and applications
- Managing identity and security across the IT landscape, implemented in a heterogeneous mix of technologies
- Protection of data at rest and in transit
- Compliance with a growing set of regulatory and legal frameworks.
Probability indicator:
Metrics are the key to continuous improvement and justification of any SOA initiatives. Initially, it starts with a baseline measurement and then it is measured at appropriate intervals.
KPIs provide a yardstick for measuring the business value of SOA initiatives. KPIs are leveraged to know the critical area in the landscape and on delivering business value so as to align IT investments with business goals and priorities. KPIs target the critical areas to help focus activities; fine-tune performance; and model processes up, down, and across to achieve the goals.
KPIs help transform an IT role into a proactive business advocate as one can work consultatively with colleagues to analyze IT spending to improve the organization's performance. Here are the metrics for SOA:
|
SOA KPIs |
Description |
|
Application usage |
SOA provides services that are leveraged by many consumers. The usage of the application before and after SOA. |
|
Cost reduction |
The IT budget ratio between the projects driving business growth initiatives and the projects for legacy maintenance. Define different cost heads, for example, operations, development, license, and facility. |
|
Functional reuse |
Define and measure functional reuse before and after SOA enablement. The metrics are measured and reported across LOBs. |
|
Quality of service (QoS) |
QoS include availability, performance, scalability,capacity |
|
Revenue |
SOA will lead to added revenue by exposing processes/functionality to the outside world. |
|
Time to market |
Leveraging SOA enables reusable and standardized services deployed to access legacy systems, this reduces the time to market of these capabilities in the landscape. |
|
Security KPIs |
Ensure that services have security controls enabled, which helps monitor frequency and severity of security incidents after SOA-fictions. |
Table 4: SOA key components
Probability indicator:
A key technique of the SOA identification journey is to employ a meet-in-the-middle approach and is a combination of bottom-up, top-down, and middle-out techniques. In many scenarios, only the bottom-up approach is leveraged. However, this approach typically leads to poor service identifications driven by the architecture of legacy applications and does not consider the business perspective. The following list explains various approaches:
- Domain decomposition is a top-down approach where business domains are decomposed into functional areas across the value chain. After the initial decomposition, each area can be further decomposed into processes and sub-processes. As best practices, the use cases are good candidates for service exposures.
- Existing asset analysis represents a bottom-up approach where we analyze models, transactions, and APIs from legacy applications as potential candidate services.
- Goal service modeling facilitates a middle-out methodology that relates services to metrics, goals, sub-goals, and KPIs of the organization. This mechanism provides validation and may reveal candidate services that were not identified through the earlier approaches.
Probability indicator:
A key approach in SOA development is to leverage a development methodology or framework to identify, design, and build SOA entities. The service-oriented modeling and architecture (SOMA) defines a set of product- and technology-agnostic modeling frameworks for analysis and design activities for defining SOA. The SOMA process consists of three major steps: identification, specification, and realization.
The SOMA service identification approach leverages the approach combining top-down, bottom-up, and middle-out techniques. In a few occasions, a bottom-up approach is taken, but this approach typically leads to poor service definitions that are mainly driven by legacy architecture and not the business perspective.
Figure 3: SOMA
Probability indicator:
There are two main approaches to scaling:
- Scaling up involves upgrading the existing hardware, replacing existing components, such as CPU or memory, or adding new hardware components. The critical components that affect performance and scalability are CPU, memory, disk, and network cards.
- Scaling out involves adding more servers to the landscape to increase application load processing. This increases the overall processing capacity of the solution.
Probability indicator:
The Open Group Service Integration Maturity Model (OSIMM) framework guides enterprises in their SOA transformation journey. OSIMM model enables enterprises to benchmark their current SOA deployment and develop roadmaps for transformation to the target state. This is also leveraged by Independent Software Vendor (ISVs) to position their products and software against such benchmarks. OSIMM serves as a framework for the SOA transformation process that can be customized to suit the needs of different enterprises.
OSIMM helps create an incremental transformation IT roadmap for more mature target levels in order to achieve benefits for the higher maturity levels. OSIMM establishes SOA characteristics desirable to achieve a new maturity level. This enables determining whether issues at the current level of integration maturity can be solved by next levels.
This process consists of the following steps:
- Prepare OSIMM assessment assets, frameworks, and models
- Define the current level of services integration maturity
- Define the target level of services integration maturity
- Identify the transformation path to achieve the target level of maturity
Figure 4: OSIMM
Probability indicator:
Simple Object Access Protocol (SOAP) is a communication protocol. This protocol establishes a set of rules for communication, leveraging XML standards. Microsoft developed SOAP as a mechanism for interaction on the Internet, succeeding its predecessors Common Object Request Broker Architecture (CORBA) and Distributed Component Object Model (DCOM). The reason for SOAP's success was that it leveraged XML communication, unlike binary systems such as DCOM and CORBA. The following lists the capabilities of SOAP
- SOAP is a heavyweight protocol but a distinct advantage is its language and platform
- Importantly, it is independent of transport protocols
- It is extremely extendable and supports a set of web services extensions
- SOAP is reliable and standardized
- Another benefit is that it is designed for distributed models
- SOAP is widely used for asynchronous processing of data for web applications
- SOAP is secure and compatible, and this ensures that services are not firewalled
- Different languages enable automation of SOAP services
Representational State Transfer (REST) is not based on communication protocols but has a standard architecture principle leveraged to transfer data over HTTP protocols. REST is a web service that is the result of an alternative to distributed SOAP services. The following is a list of the capabilities of REST
- REST is based on a light-weight architecture
- It needs no tools for creation and is very easy to implement
- It is leveraged in the device service implementation in mobiles and PDAs, where they need less overheads
- REST supports only standard methods (GET, PUT, POST, or DELETE)
- It is a stateless communication protocol
- REST is quick and efficient but with a disadvantage in web caching
Advantages of RESTful web services over SOAP Web Services:
- Lightweight and easy to consume from smart devices.
- Easy to expose with no restrictions on communication protocol and output format.
- RESTful services leverage HTTP. The entire Web is based on HTTP and is built for efficiency. HTTP caching capabilities enable REST to be efficient and effective.
- High performance, as low XML and SOAP overhead and caching enable REST to be highly performant.
Probability indicator:
The five key constraints while creating RESTful services are:
- The client-server model; there has to be a service producer and a service consumer.
- The interface URL is uniform and exposes resources.
- The service is stateless. If the service is called many times, the result will be the same.
- The service result should be HTTP cacheable.
- Layered architecture. The client does not have a direct connection to the server-it will be getting info from a middle layer cache.
Probability indicator: 
Transforming a business to SOA includes standardized contract, reusability, abstraction, loose coupling, composability, and so on. SOA is a technology-agnostic architectural paradigm, and enterprises can pursue service-oriented strategic goals by leveraging different technologies. The current trend is that web services are technology platforms that enable SOA principles and are mostly leveraged to build this architecture. A strategy for achieving loose coupling is the WSDL service interface, hiding the implementation from stakeholders. Loose coupling is addressed by encapsulating the implementation that limits the impact of changes to the implementation on the service interface.
Best practices is that SOA services are stateless. The state data must be retained only during the request/response mechanism. This is because the state management consumes a lot of resources, affecting scalability and availability of the service.
Probability indicator:
Composition is a technique of combining different services to create a composite application. A composite application is an aggregation of various services for producing an enterprise process. A composite service consists of aggregation of different services to produce another reusable service.
Probability indicator:
A common pitfall is to consider SOA as a target state rather than a journey. Architects, rather than solving business problems via SOA, are likely to create large and complex interconnections between IT assets. Another pitfall is trying to solve multiple issues at one go rather than solving smaller problems. A top-down approach starting with enterprise-wide infrastructure investments often fails to highlight results in a given timeframe or compelling ROIs. SOA needs a different thought process for building SOA solutions. Instead of thinking of technology first, SMEs must think in terms of business solutions. The adoption of SOA will result in business departments, creating service-oriented IT organizations instead of technology-oriented IT organizations.
Probability indicator:
SOA delivers business benefits and IT cost efficiencies, but needs a disciplined approach to governance to be effective and successful. In a few cases, the cost of enforcing principles may be higher than the benefits, and therefore may not be a sound initiative. The SOA model is leveraged for building business applications using loosely coupled services that are orchestrated to specific business goals by inter-linking.
Probability indicator:
Enterprise integration is focused on transferring data from one database to another database, but the current trends have challenged this methodology. There are five levels of enterprise integration, and each level represents efficiency improvement:
|
Level |
Description |
|
Business process integration |
This is integration at the process level and is typically accomplished with ERP API or workflow tools. |
|
Web content integration |
This is enabled through mashups or portals and facilitates process across multiple information areas leveraging web frameworks and tools. |
|
Automation integration |
Integration at a sub-process level. |
|
Service integration |
Services that provide CRUD data and provide process automation, and this is accomplished through SOA principles. |
|
Database integration |
This consists of transferring data from one database to another. This approach is overused and is more efficient to integrate at a higher level. |
Table 5: Integration Levels
Probability indicator:
A web service is a service offered over the web through the HTTP protocol. When browsing the Internet, we leverage different web services. Even loading google.com involves web services. When we type in google.com in the browser, the following steps happen in the background:
- The browser invokes the get request on google.com.
- google.com returns an HTTP response with HTML contents.
- The browser renders the HTML contents for the end user.
Web services are classified based on data exchange protocol. There are two popular web services:
- SOAP: All web services using SOAP protocol are called SOAP web services
- RESTful: All web services satisfying the REST architectural constraints are called RESTful web services
Probability indicator:
SOA is an architectural paradigm, and a web service is the technical approach to implementing it. Web services are preferred standards of achieving SOA. Web services communicate using loosely coupled SOAP. SOA services are catalogued in a directory. UDDI is a SOA registry and describes the mechanism to get to these web services.
Probability indicator:
SOA patterns are reusable components which can be applied to commonly occurring design problems. Key SOA patterns include:
- ESB facilitates data transformations, message queuing, message transformation, service brokers, and reliable messaging.
- A File gateway is introduced between a service and legacy file, and acts as a mediator for data transformations.
- Event-driven messaging notifies its consumers of events through messages.
- Service callback provides a callback, mechanism for the service to respond and is an asynchronous communication model.
- Service grid stores the service state which facilitates redundancy and replication.
Probability indicator: