Book Image

SOA Made Simple

Book Image

SOA Made Simple

Overview of this book

SOA is an industry term which is often preached like a religion rather than taught like a technology, and over time, grasping the concept has become unnecessarily difficult. Many companies proclaim that they don't know where to begin with SOA, while others have begun their SOA effort but haven't reaped the benefits they were convinced it would bring. "SOA Made Simple"ù unveils the true meaning of Service Oriented Architecture and how to make it successful so that you can confidently explain SOA to anyone! "SOA Made Simple"ù explains exactly what SOA is in simple terminology and by using real-life examples. Once a simple definition is clear in your mind, you'll be guided through what SOA solves, when and why you should use it, and how to set up, design and categorize your SOA landscape. With this book in hand you'll learn to keep your SOA strategy successful as you expand on it. "SOA Made Simple"ù demystifies SOA, simply. It is not difficult to grasp, but for various reasons SOA is often made unnecessarily complex. Service-orientation is already a very natural way of thinking for business stakeholders that want to realize and sell services to potential clients, and this book helps you to realize that concept both in theory and practice. You'll begin with a clear and simple explanation of what SOA is and why we need it. You'll then be presented with plain facts about the key ingredients of a service, and along the way learn about service design, layering and categorizing, some major SOA platform offerings as well as governance and successful implementation. After reading "SOA Made Simple"ù you will have a clear understanding of what SOA is so you can implement and govern SOA in your own organization.
Table of Contents (17 chapters)
SOA Made Simple
Credits
About the Authors
About the Reviewers
www.PacktPub.com
Preface
Index

The importance of information


When Information Technology (IT) had its entrance in businesses, it was used primarily by specialist people. The data entry professionals and other users were trained to use the systems all day. Other people were busy doing their job without using the computer, but instead using information on paper. Now the computer is everywhere in the business—from the front office to the back office, from the manager to the concierge.

Modern organizations rely on IT for their day-to-day operations. On top of that, information technology is used in management and supporting processes. The dependency on information technology is even bigger in organizations that deliver services, rather than physical products. For example, a bakery depends on information technology to do accounting, order supplies, and so on. But the core process of baking bread is more dependent on the quality of the ingredients, the physical machines in the factory, and the procedure than on information technology.

Example – insurance company

Now think about a services organization like an insurance company. The operational or core processes of an insurance company consist of policy administration, claims processing, underwriting and acquisition, and reinsuring. These processes are illustrated in the following example:

The figure consists of three types of processes:

  • Management processes: These consist of monitor premium, monitor investment, monitor underwriting, and monitor compliance.

  • Operational processes: claim to payment: When a claim is received, it is reviewed against the policy of the insured. If the claim is valid, it is paid. The payment is registered in the file of the customer (the insured).

  • Supporting processes: To support this primary process and the management process, a number of supporting processes are shown in the lower part: Hire people, Manage applications, Accounting, and Market policies.

All these processes are information intensive—the insurance company stores information about the different products they insure, the combinations they offer in a policy, the customers they insure, the claims that are processed, the money that is invested, and so on. This information is used across all the processes, both the operational processes and the management and supporting processes. On top of that, information needs to be accumulated to manage the organization. For example, the profit of an insurance company is determined by the earned premium, the investment income minus the incurred loss and underwriting expenses. So management of the company needs information about the earnings, the operational cost, and return on investment to increase their profit. Compare this to the factory that bakes bread; for them, information technology is obviously also very important for the management and supporting processes, but for insurance companies information is what determines for a large part the quality of the service. Information is the main ingredient for this process.

Mismatch between business and IT

As organizations are so dependent on information, it is very important that the technology that provides this information and is used to support these processes is in line with the needs of the organization. This is what we call business and IT alignment. Henderson and Venkatraman can be seen as the founding fathers of business/IT alignment and published an article called Strategic Alignment: Leveraging Information Technology for Transforming Organizations, IBM Systems Journal, vol32, No1. In their model, the objective of business and IT alignment is to manage three separate risks associated with IT projects:

  • Technical risk: will the system function, as it should?

  • Organizational risk: will individuals within the organization use the system as they should?

  • Business risk: will the implementation and adoption of the system translate into business value?

Business value is jeopardized unless all three risks are managed successfully.

When you talk to people in different organizations, they often complain about IT performance. This technical misalignment of business and IT manifests in two ways:

  • IT is not able to change fast enough along with the business

  • IT is not able to deliver the functionality the business needs correctly

The first item, IT not being able to change fast enough, is becoming more and more important in today's market. It is one of the problems that SOA can help you solve, if applied correctly. In general, organizations that are in one of the following situations need to be able to change fast:

  • Organizations that have to deal with changing rules and regulations, like health insurance companies, financial institutions, and the public sector.

  • Organizations that are in fast changing markets, like the telecommunication industry.

  • Organizations that are merging, splitting up, or outsourcing part of the operational processes. These organizations need to be able to change their IT according to the changes in the organization and processes. Examples are the financial services industry, product oriented companies with multiple suppliers, and utility companies.

Duplication of functionality and data

Apart from the misalignment of business and IT, there is another problem that becomes more and more important because of the dependency on information— duplication of data and functionality. Traditionally, companies are organized functionally. This means that there are different departments for different functions in a company; a customer service department to service the customers, a claims department that assesses the claims, the human resources department for the workforce. All these departments use their own IT systems that keep track of the data that is needed. Because all the departments use their own IT systems, and these systems are not connected to each other, information is duplicated within an organization. This can lead to differences between departments, because the information is not only stored, but also changed in these systems. This leads to inconsistencies across the organization, unless the information is synchronized between all the systems.

Example – insurance company

Let's investigate the impact of duplication of functionality and data with an example from an insurance company again. The marketing department stores information about the products they want to sell to prospects in the Content Management System (CMS).

Note

A CMS is a system that allows publishing, editing, and modifying content of a website. Often these systems offer procedures to manage workflow. There are two types of content management systems: enterprise content management systems and web content management systems. The first is used to organize the content of your organization. The latter is used to organize the content for web pages (intranet or internet). Content can be defined as documents, movies, text, pictures, phone numbers, and so on.

An example of such a product is health insurance for students. The Customer Service department also needs this product information, because they need to answer questions they receive from prospects and customers about the product. They often use a Customer Contact System (CSS) to support interaction with customers. The product information that is stored in the Customer Contact System (CCS) needs to be the same as the product information that is stored in the CMS, to be able to answer questions that customers have about the product. A student might call for example, to ask if he or she is eligible for the student health insurance. Apart from product information, the Customer Service employees need access to policies, the customer data, and claims for a particular customer that is calling. If the marketing department changes something in the product description, this should also be changed in the CSS. The same applies to the Insurance Administration system and the Enterprise Resource Planning system, information should be consistent and both departments—the claims department and the finance department—need the claim, policy, and customer data in their process. The claims department handles claims and the finance department pays claims and collect premiums. If one department changes something, the other department needs to change the data the same way. Often this does not happen, because the departments are not always aware what data is stored redundantly or what changes impact other departments. The next figure shows an example of duplication of data in an insurance company. As you can see, there are several systems storing and maintaining the same type of data and functionality:

  • Product information is stored and maintained in the CMS by the Marketing department and in the CCS by the Customer Service department;

  • Customer information is stored and maintained in the CCS by the Customer Service department and in the IAS by the Claims department, and in the ERP by the Accounting department;

  • Call information is stored and maintained in the CCS and in the IAS

  • Policy information is stored and maintained in the CCS, in the IAS, and in the ERP system

  • Claim information is stored and maintained in the CSS, the IAS, and the ERP system

Apart from inconsistencies because of the data duplication, functionality is also duplicated. Take for example adding a product to the portfolio; rules are associated with adding products. These rules are implemented in the IT systems where products are added. When the rules associated with adding a product are changed, this needs to be changed in all the systems where products can be added. This is costly and error prone.

Process silos

Departments that are self sufficient and isolated from the other departments are called organizational silos. These silos not only lead to duplication of functionality and data, but also to suboptimal process execution. The processes are divided based on organizational structure, not based on the most efficient end-to-end process. These processes are often referred to as process silos. Within a department, there is often not a clear picture what the impact of the output is on a different department. This leads to rework and bottlenecks in other business processes, and eventually to unhappy customers because of delay and mistakes. Take for example the situation in the following figure, where an organization tells the employees in the front office to minimize the time they spend on each phone call, so they can handle as many customers as possible. They minimize the time to complete a phone call, but unfortunately they forget to ask questions and register information that is important for the department that needs to fulfill the order. So even though the front office optimized its processing time, the total end-to-end client process has become slower because of the organizational silos.

Now that we have seen the general problems that modern companies face with regards to information technology, let's look at some concrete examples from different industries and see what types of problems arise because of this duplication of information and functionality and because of the misalignment between business and IT.

Example – utility companies

To keep energy costs low for consumers and to guarantee the energy delivery, a law in the Netherlands requires utility companies to split into two different entities—the network operator that is responsible for the infrastructure of the gas and electricity grid(s) and the supplier that deals with the consumers (both business and private consumers).

All the utility companies had both activities in their portfolio before this law came into place. Some also generate energy, and offer services to end users regarding the equipment on location (meters, central heating system).The utility companies all started as government agencies, owned by municipalities. Customers did not choose what energy company to get the service from; it was determined by their location. A lot of these companies built big IT systems to keep track of the energy connections, the consumers, the usage, and so on. The IT systems or applications span multiple domains and multiple roles. These systems were built using relational databases; all the data is interconnected. A change in one part of the system will have an impact on another part of the system. Splitting the company is extremely difficult as the entire IT is intertwined, and only all or nothing scenarios can be applied as a solution.

An example of such an IT landscape is shown in the following figure.

Application X spans multiple domains—CRM, Energy management, asset management, and accounting. It spans two roles—the role of the utility company as a supplier and the role of the utility company as a grid operator. It contains information about the customers from an energy supplier perspective, and information about the energy that is needed in the organization to service all customers, about the assets that the company owns and uses to service the customers and last but not least, the application is used to send invoices to customers. Application Y is an off-the-shelf Customer Contact System (CCS) that serves a specific purpose that supports the supplier role of the utility company. The same is true for applications A, B, and C; they service well-defined functionality in a specific domain. When the company has to split into a grid operator and a supplier A, B, and C will go with the grid operator and Y will stay with the supplier. For application X and Y there is a problem as they are used by both and because of their architecture, it is difficult to split the application into a supplier and a grid operator part. They have run into this problem before, when the company bought an off-the-shelf ERP system. They wanted to use the invoice module of this ERP system but couldn't because they could not take out the invoice part of application X without breaking other functionality that they wanted to keep. Other smaller changes also cause problems for the IT department; they are not able to implement them fast enough in application X to satisfy the business.

This is a typical example of the misalignment between business and IT. The organization needs to change before the date that is set by law, but the IT is built in such a way that it takes years to realize the changes. Sometimes this type of problem is referred to as a legacy problem, because difficulty to change tends to arise in systems that have been around for a while. The architecture and technology are out-dated and it is becoming harder and harder to change the system. In this example, the problem is not the age of the technology, but the fact that everything is connected with everything in this huge system.

Note

Organizations can't be changed fast enough because there is one big IT system with a lot of relationships between different entities.

Example – international software company

An international software company wants to change the way the order-to-cash process is executed. The company has started to sell their products online, and the customer can download the product after paying for it online. This means that the process order-to-cash needs to be adjusted—in this case the customer has to pay upfront, instead of after receiving the product.

The process logic (the order of the steps) is coded into the custom application that the organization uses for this process. Therefore, changing the process impacts the entire application. This is expensive and very disruptive for day-to-day operations because it is one of the core processes of the company.

Rather than changing the existing process for online purchases, the company decides to create a whole new application, thus creating a problem with data synchronization, customer service, and management information. This is shown in the following figure: there are two applications that handle orders. Depending on the origin of the order, different systems handle it. There is no clear separation in the application between process logic, and the components cannot easily be taken out or replaced. Both functionality and data are duplicated.

This example covers both misalignment of business and IT, and duplication of functionality and data.

Note

IT can't keep up with process changes because of the way the applications are structured and solves this with data duplication and functional duplication, thus creating more problems for the future.

Example – insurance company

In the Netherlands, people can choose new health insurance every year in December. For insurance companies this means a lot of work; they need to market their new policies, determine prices, and entice people to either switch to their company or stay there if they are already a customer. The competition is fierce, everybody is switching at the same time, there are sites comparing different brands, and whoever publishes a price first sets a trend or loses to the competition. Most insurance companies carry more than one brand and different policy types for different target groups. On top of that, health insurance has a lot of political visibility, both from the perspective of care and from an income perspective. This means that laws and regulation change frequently. Insurance companies often have different systems in the back office and the front office, as you have seen in the previous insurance company example. This means that adding a product needs to be handled both in the back office application and in the content management system of the company. It is difficult to keep track of both systems and every year errors are made with the processing of the new customers and products.

This example shows the problems that occur because of functional duplication and data duplication. This leads to misalignment between business and IT as IT can't deliver fast enough.

Note

Companies lose out in the competition because IT can't deliver solutions fast enough.

Strategies to stay ahead

The previous sections showed that companies struggle to change fast enough. Companies need to be able to change fast, to be able to compete with each other. Markets are changing fast, so it is very important to be able to change quickly. Depending on the strategy of the company, it might even be necessary to be ahead of everybody else and change to set trends and be proactive in the market. Other companies don't compete by being the first, but by being the cheapest. The strategy that a company uses is important when creating your architecture. If cutting cost is important, reuse of existing assets is important. If changing fast is more important, replacing parts of your IT fast is more important.

You learned in this chapter that it is important for IT to be aligned to the business goals of an organization. There are different strategies that an organization can use such as operational excellence, customer intimacy, and product leadership. These strategies lead to different requirements for the IT systems in your organization.

  • Operational excellence: Companies that apply operational excellence, focus on operations and execution. This means that efficiency is a very important goal; volume and low cost are important factors. Data and functional duplication are a problem for these companies, because it increases cost in the operation. Companies that focus on operational excellence have a keen eye for waste and redundancy. These kinds of companies strive to optimize their business processes by automation, tracking, and benchmarking the KPIs.

  • Product leadership: When a company strives for product leadership, innovation and marketing are important. These companies usually operate in dynamic markets. Focus is on innovation, time to market, and design. Business and IT alignment are very important for companies like this.

  • Customer intimacy: The third strategy means that a company strives to excel in customer service. Products and services are not standardized, but tailored to the needs of the specific customer. There is a focus on CRM, delivery on time, and reliability. The IT systems and processes of companies like this should be highly customizable and flexible; there is less need for standardization than in companies that use operational excellence as a strategy.

Example – a software company

Let's compare the three strategies and the impact on software and processes with an example. Consider an independent software vendor who offers software for customers to support their purchase-to-pay process. They have a number of competitors in the market, with whom they can compete in three ways:

  • Operational Excellence: If the company wants to compete based on price, it can use operational excellence as a strategy. This means that the software realization process is very much automated and executed like a factory. Every customer gets the same software. If a change is requested, it will be built into the standard software that is delivered to everyone. Customers will have to change their process a little to fit the software. The company will target customers that don't want to spend a lot of money on this process, because supplier management is not an important strategic process for them. The software development process is standardized, but also the supporting processes, like customer service and HR processes like training.

  • Product leadership: If the company competes based on product leadership, it will invest money in becoming the best. This means spending time and money in a research and development center, training employees, evaluate the user experience of the software and last but not least, keep track of the latest developments in the field of purchase-to-pay. The company will be the first to support functionality like self-billing or other trends in the market. Standardization and reuse are important, but only as far as it does not hinder product development and improvement.

  • Customer intimacy: If customer intimacy is the strategy of the company, it will invest a great deal in making sure the software can be customized exactly to the wishes of the customer. The customer can determine the exact requirements and design of the application. Every customer gets his or her custom application, and service level. Reuse and standardization are important, but only as long as it does not hinder the customization options in the software and the possibilities to treat every customer differently, according to their needs.