SOA Made Simple

Chapter 1. Understanding the Problem

This chapter investigates what problems people who apply Service Oriented Architecture (SOA) are trying to solve. The problems can be categorized into two major areas:

The mismatch between the business and IT
Duplication of functionality and process silos

One discipline that can help solve these issues is the application of architecture in an organization and in projects. As the term Service Oriented Architecture indicates, SOA is about architecture. In this chapter you will learn about different types of architecture, like reference architectures and solution architectures, and common layering concepts that can be applied on different levels within the organization to make sure that the strategy of the company is in line with the developments and projects that are executed. But first, let's dive into the problems that modern companies face and look at the increasing importance of (electronic) information in companies.

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.

Architecture as a tool

You learned in the previous paragraphs that organizations become more and more dependent on information and information technology, and that organizations have different strategies to compete in their markets. This puts demands on IT planning. This is how Service Oriented Architecture emerged, to cater for these needs. Before we dive into Service Oriented Architecture, it is important to define architecture.

Architecture is a discipline that helps organizations to align the IT with the business and the strategy of the organization. In the construction world, architecture is a well-defined discipline. The profession is protected; not everybody can call him or herself an architect. But in IT, we lack clear definitions of roles and capabilities. In different countries, industries, and communities we use different definitions. Although we will define architecture in this paragraph, and adhere to de-facto definitions and standards, there is no consensus in the world of IT. So if in your company, you employ different names and titles for the activities described as follows, that is fine. It is important that activities are executed, not what you call them or who executes them.

Time for a definition, ISO/IEC 42010:2007 (http://www.iso-architecture.org/42010/cm/ ) defines architecture as:

The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.

The Standard takes no position on the question, What is a system? In the Standard, the term system is used as a placeholder. For example, it could refer to an enterprise, a system of systems, a product line, a service, a subsystem, or software. Systems can be man-made or natural.

What is important in this definition is the scope of a system. In the following paragraphs, we describe different types of architecture, defined by the scope of the project or the system. For example, if we are describing the architecture of a municipality, the system is everything within the municipality. If we are describing or designing the IT landscape for the front office, the scope of the system is the front office IT. But if a project is about implementing a new regulation, then the scope of the system we are describing is everything that is impacted by the new regulation.

It is important to note that architecture does NOT equal standardization. It depends on your company's strategy or operational model, how much integration and standardization you need and in what processes and systems and organizational parts you need it. The goal of architecture is to translate the business strategy into appropriate guidelines for standardization and integration. Architecture is a means to an end; making sure that IT can fulfill the business requirements is the goal, not standardization, or documentation.

To make sure that the architecture meets the demands of the business, Zachman (http://www.zachman.com/about-the-zachman-framework) defined a number of questions that need to be answered when creating the architecture of the system. They are: Why, how, what, who, where, when, and what-if? Consider a company that sells printers, faxes, and other peripherals and wants to redesign their outdated front office architecture. To make sure the front office architecture is aligned with the goals of the company, the following questions need to be answered:

Why: What are the goals of the organization with regards to the front office? Do we want to encourage customers to use the phone or the website? Do we cross-sell or up-sell on the phone? Do we want to minimize the time spent per customer or maximize customer satisfaction?
How: What type of functionality should the IT systems support in the front office? Do the users need to look up payment history? Do we need to see previous purchases from this customer? Do we need to change data directly or just put in requests to be handled in the back office?
What: What types of data do we use and store in the front office? Do we have all customer related data in the front office? Do we store the same data the customer can see, or more, including everything that is known in the back office?
Who: Who is using the systems in the front office? What is the education level and experience of the target users? How many users are working in the front office, are they working with the systems all day?
Where: Where are the systems of the front office, what does the network look like? Are the systems located on-site, or does a remote provider host them? Are the users on-site, or using the systems remotely from home?
When: What type of availability do we expect of the front office systems, 24/7 or office hours? The systems that support the call centers and website probably need more availability than the systems that are used by the employees at the office.
What-if: Is there an alternative way to deliver the solution? What if we outsource the front-office activities?

The answers to these questions depend very much on the perspective or stakeholder. If we are talking about the IT landscape of the front office from a security perspective, we have different interpretations and focus for the why, what, how, who, where, and when questions compared to the perspective of the controller, who is paying for the new system. For example, from a security perspective it is important to differentiate roles that have different permissions and responsibilities. The who question will focus around that. From a financial perspective, it is more important how many users there are, not what they do exactly. The answer to the who question from a financial perspective will be focused more on actual number of users, and less on the roles and types of users.

Because of these different perspectives, there are several ways of breaking up the organization of a system or architecture. Systems can be divided into logical layers, tiers, or viewpoints/views:

When we divide everything in a municipality in business, information, and technical topics, we are talking about layering of the architecture
When we divide software in the front office in presentation, business logic, and data parts, we are talking about logical tiers in the software
When we describe the system differently depending on the perspective of the stakeholder, we say we are describing a view of the architecture from a specified viewpoint

While viewpoints, layers, and views refer to logical concepts, tiers often refer to physical division.

Layering of architecture

There are different layering schemes used by different architecture frameworks. A common layering in architecture is dividing it in three main layers: the business layer, information systems layer, and technology layer. This is the layering applied by The Open Group Architecture Framework (TOGAF). In this framework, the information systems layer is divided in services or applications and data. Other layers can be divided into several layers too. Whether a layer is a first-class citizen or part of another layer can be cause for great debate within organizations. To keep things manageable we use the three layers (Business, Information, and Technology) of architecture throughout the book, with different parts within the layers as shown in the next figure. Security and Administration cut across the three layers, so they are positioned next to these layers.

Layers and aspects within these layers can be described from different perspectives: strategic, tactical, or operational. The security view is written from the viewpoint of the security officer. The administration view is described from the viewpoint of the system administrator. The other layers are not written from a specific perspective, but are divided according to the type of information that is captured from the system. For example in the business architecture, one typically finds information about the business processes. This can be described from different perspectives, for example from the perspective of the operation, or from the perspective of a controller. The same is true for information in the other layers.

Models

Architecture is often expressed using diagrams and models, apart from text. There are different (formal) modeling languages available to model. All models target different stakeholders and have a different scope. The following table shows modeling languages that can be used in the different layers together with their target architecture. Apart from these formal modeling techniques, diagrams can be created that are free format. Depending on your target audience and your own modeling skills you can pick any of these languages to communicate the architecture of your system.

Modeling language	Scope	Standard/ Proprietary	Target audience
Archimate	Business, information, and technology layer	Standard (The open group)	Architects, developers
UML(Unified Modeling Language)	Business, information and technology layer	Standard (Object management group)	Developers, architects
BPMN (Business Process Modeling Notation)	Process models	Standard (Object management group)	Process analysts, business consultants
EPC (Event driven Process Chain)	Process models	Proprietary	Process analysts, business consultants
ERM (Entity Relationship Model)	Information (Data) layer	De-facto standard (There is no official standardization body that maintains ERM)	Developers, architects
Not applicable (Free format)	Business, information, and technology layer	Proprietary	Entire organization

Note that in this book, we will use mainly UML diagrams, BPMN diagrams, and free format to describe the various concepts and architecture examples.

Requirements

Architecture is not a means to an end, but a way to assure that organizations can change and meet market demands, and that they operate efficiently. To accomplish this, the following architectural requirements are imposed on the architecture by the organization:

It is understandable to the stakeholders involved.
It is well known and visible in the organization.
It is useable. When a project is started or the organization has to take decisions, the architecture will help make this decision or scope the number of possible solutions for a problem. This means that it should have clear principles and guidelines, and use terms and layering that are valuable for the organization.
It can be changed. Because organizations change, the architecture needs to change as well. It is not a cookie cutter that keeps its shape; it is a plan that will have multiple versions as time passes.

This list applies to any architectural style or reference architecture you choose for your organization. When you notice that architecture is described in your organization, but not used in projects or within the decision making process, one of these requirements is not met. Instead of continuing to describe the architecture, it is important to investigate which of these requirements is not met. Common pitfalls are that the architecture is too detailed, out-dated or too complex.

Architecture ontology

In this paragraph you will learn about the different types of architecture that you can apply or use for your organization to ensure business and IT alignment. This will put Service Oriented Architecture in perspective and helps you chose the right scope for your efforts. There are two different axes on which you plot architecture; one is scope of the system, the other one is generalization. Scope can be really big, or specific and small. As you recall from the definition of architecture, the scope of the system it describes can be anything. In this paragraph we discuss enterprise architecture, project architecture, and software architecture, as examples for scope of the system. Apart from scope, there are also grades of generalization that you can put in architecture. You will also learn about reference architecture and solution architecture. Last but not least you will learn about a specific type of solution architecture—Service Oriented Architecture—as an introduction to the rest of this book.

The figure shows the relationship between the different architecture types. As you can see, Service Oriented Architecture is a reference architecture that guides and constraints solution architectures. The reference architecture can have different scopes such as Enterprise architecture, Project architecture, Software architecture, and so on.

Enterprise architecture

If the scope of the architecture consists of the entire company or organization (enterprise), or the architecture scope spans multiple organizations, we practice enterprise architecture. Enterprise architecture as defined in Enterprise Architecture As Strategy: Creating a Foundation for Business Execution, Ross, Weill, and Robertson, Harvard Business Review Press:

Enterprise Architecture is the organizing logic for business processes and IT infrastructure, reflecting the integration and standardization requirements of the company's operating model. The enterprise architecture provides a long term view of a company's processes, systems, and technologies so that individual projects can build capabilities, not just fulfill immediate needs.

There are several frameworks and methodologies available for enterprise architecture. One of the first frameworks that became a basis for other frameworks is the Zachman framework. It is a framework for structuring the enterprise architecture and consists of a matrix of 6 x 6. The columns consist of questions we mentioned earlier. The rows are organized from high level to more detailed as can be seen in the following screenshot from Wikipedia (http://en.wikipedia.org/wiki/Zachman_Framework):

An architect describing the enterprise architecture using this framework needs to decide what columns and rows need to be described for the organization/enterprise. Not every cell needs to be filled. For example, if the focus is on introducing Business Process Management into an organization in order to get rid of functional silos, the How column needs to be filled with process models, diagrams, and execution details. If the different locations of a company are critical the Where column needs to be described. The same applies to the rows, depending on the needs of the organization more or less rows can be described.

Open Group offers another comprehensive framework—TOGAF. It consists of several parts:

Architecture Development Method (ADM): It describes the methodology.
Content framework: It contains deliverables, artifacts, and building blocks.
Enterprise continuum and tools: This is a view of all the different types of solutions and architectures, ranging from detailed to abstract, for different types of stakeholders.
Reference models: TOGAF offers generic reference models that can be used as a starting point for organizations to structure their own enterprise architecture.
Architecture Capability Framework: This framework explains the capabilities an organization needs, or the roles and responsibilities, to maintain the architecture.

There are several other frameworks that can be used. When you choose a framework, pick one that fits your purpose best. Some frameworks are more elaborate than others; some frameworks focus on both the organization of the system and on the process of designing it. Others focus only on the process, or the system. After choosing a framework, you will have to adapt it to the needs of your organization.

Reference architecture

There are a lot of similarities between different organizations in the same industry. For this reason, reference architectures are developed. Wikipedia (http://en.wikipedia.org/wiki/Reference_architecture) defines it as:

A reference architecture in the field of software architecture or enterprise architecture provides a template solution for an architecture for a particular domain. It also provides a common vocabulary with which to discuss implementations, often with the aim to stress commonality.

Using reference architecture has several advantages:

Standardization of terminology, taxonomy, and services eases working with suppliers and partners
It reduces the cost of developing enterprise architecture; the organization can focus on what sets it apart from the reference architecture and other organizations in the industry instead of reinventing the wheel
It makes it easier to implement commercial off-the-shelf (COTS) software, because common terminology and processes are used

Obviously, it also has some disadvantages:

It takes some time to learn industry reference architecture; they are often (over) complete
The reference architecture is typically written by a group of people from different organizations and so is the result of a compromise

As we saw in the previous image, and in the definition of reference architecture, the scope of the reference architecture can differ.

Examples of (enterprise) reference architectures are the Dutch Government reference architecture—NORA (http://e-overheid.nl/images/stories/architectuur/nora_maart%202010-eng.pdf), TM Forum Frameworx and eTOM for telecommunications (http://www.tmforum.org/), and the US reference architecture for federal government, Federal Enterprise architecture—FEA( http://www.whitehouse.gov/omb/e-gov/fea).

Solution architecture

Solution architecture is a detailed (technology) specification of building blocks to realize a business need.

Open Group recognizes different types of solutions in the solution continuum:

Foundation solutions: This can be a programming language, a process or other highly generic concepts, tools, products, and services; an example of a process is Business Information Services Library (BISL).
Common systems solutions: For example CRM systems, ERP systems as we have seen in the previous examples, and also security solutions.
Industry solutions: These are solutions for a specific industry. They are built from foundation solutions and common systems solutions, and are augmented with industry-specific components.
Organization-specific solutions: An example of this is the solution for the health insurance companies that want to offer self-service to prospective clients. The solution architecture describes the multi-channel solution for the organization, the tools and products that are used to implement it, and the relationship between the different layers.

The difference between reference architecture and solution architecture is that reference architecture is a generic reference where common problems are described together with principles and constraints on how to solve these. Solution architectures describe a specific solution to solve a specific problem or problems. For example, the Dutch reference architecture NORA is used as a reference for the solution architecture in a municipality.

Project architecture

Project architecture defines what part of a solution architecture will be realized by the project, or is in scope. This can overlap with a solution architecture if there is only one project needed to realize the solution architecture. If the solution is too big for one project, or there are different parts that are assigned to different projects, the project architecture describes what part of the solution architecture will be realized in the project.

Project architecture serves two purposes:

Guarding the enterprise or solution architecture: A project is typically focused on short-term goals. The project architecture explicitly describes what part of the project is supposed to satisfy long-term strategic goals, what deviations from the target architecture are going to occur and how these will be resolved in the future.
Provide input for, or change the enterprise or solution architecture: Enterprise architecture and solution architectures need to be adjusted based on experiences from projects and the current situation. Valuable feedback about the usability and understandability of the architecture is gathered from projects.

Reference architecture can also have the scope of a project. The project architecture is then less specific than solution architecture and contains guidelines, principles, and constraints for projects in the organization in general.

Software architecture

Software architecture is focused on the structure of the software. It can be viewed as a special type of solution architecture, project architecture, or part of the technology architecture. The target audience of these types of architectures are developers. Often these are not referred to as architecture, but rather as software design.

Service Oriented Architecture

We saw earlier on in the chapter that for companies that apply product leadership or customer intimacy as a strategy, flexibility is key. One of the possible solutions to make sure that IT is flexible and can be easily changed is by applying a solution architecture based on Service Oriented Architecture (SOA). Service Oriented Architecture is a reference architecture that can be applied in organizations that are part of a (supply-) chain or network, and organizations that have to deal with a lot of regulatory changes, or fast-changing markets. It makes it possible to change parts of the IT landscape, and processes, without affecting other parts. Reusing existing functionality (services) makes sure that it can be changed quickly because you don't have to start from scratch every time, and also makes it cheaper. Reuse is also important for companies that aim for operational excellence. Finally, the quality of the data is easier to control, because we can appoint specific services with the responsibility of maintaining the data and enforcing the business rules.

Filter reviews by

All

Amazon verified reviews

Rich Burke Mar 28, 2013

I purchased this book for the sole purpose to get myself familiarized with SOA concepts and principles. I was not looking for anything too detailed but rather a way to educate myself on what SOA is, how it is implemented, terminology and use cases. I found this book to be exactly what I was looking for. The concepts and principles were laid out in easy to understand language with just the right amount of detail.I did find some of the charts and figures somewhat abstract, but the text was very clear, the use cases relevant, and it was all very easy to understand.I would highly recommend this book to anybody as a first step to understanding SOA.

Amazon Verified review

Sottam May 22, 2014

I have read this book in a week. Gave me some edge knowledge on SOA infrastructure, and goes directly to the point. The title of the book is self-explanatory of what this reading is about.

Eric R. Feb 25, 2013

There is good, practical coverage of topics such as building the SOA business case and roadmap, service identification, service versioning and governance.The section on operationalizing SOA was particularly well written. This is often a gap or an afterthought in deployments. It has always been my strong believe that the entire SOA lifecycle needs to mature over time.It's obvious this book was written by SOA practitioners and not theorist like many of the early SOA books. I enjoyed the pragmatic approach and recommend the book to new SOA practitioners.The entire review is on my blog at -[...]

Frank Nimphius Feb 20, 2013

Just finished reading "SOA Made Simple" by Lonneke Dikmans and Ronald van Luttikhuizen, published in 12/2012 by Packt Publishing and use this summary to share my thoughts."SOA Made Simple" is a very good book that - beside of helping readers to do SOA right - will have an impact to how you look at going out for breakfast. The "breakfast example" is one of the great samples that the authors consistently use throughout the book.In addition, this book is well written and covers really no fluff but just stuff. Reading this book you learn what SOA is, the benefit it brings to IT, as well as how you design and model your SOA and services. Whenever Packt asks me to review and write about a new book, I ask for a printed copy so I can annotate the page with comments and questions. My copy of this 257 page book has a lot of annotations, mostly about information I want to share in my review.Too many annotations, which clearly indicates I liked the book, though I am not directly involved in SOA (which probably makes me the perfect candidate for reading this book). According to the Preface, yes I read this too, the book is "for anyone (architect, designer, developer, administrator, team lead) who is implementing or is about to implement SOA in anIT-related environmenet". Well, I would call this mission accomplished and recommend you to buy this book for your learning and career.So lets have a look what this book covers and what I liked so much:Chapter 1: Understanding the ProblemThis chapter is a well structured introduction to the current state of IT that leads to a problem statement that demands for SOA to come for the rescue. However, though A SOA book, the authors don't make it too obvious that SOA is the answer. The chapter also gives you some questions by hand you should ask before starting a SOA project so you ensure your decision is right before starting a SOA project. This chapter also introduces the examples (I already mentioned the diner for breakfast, but there also is an insurance business and others).Chapter 2: The SolutionThis chapter introduces services and the SOA term. It does so not from a pure technical perspective and without calling WS* services too soon. Or would you have considered the waiter service in a diner to be a service? In fact it is and therefore services don't need to be SOAP or REST to be called a service. SOAP and REST come into play later, when the talk is about standards and SOA.Chapter 3: Service Identification and DesignThis chapter introduces various concepts around the design of services like top-down, bottom-up and meet-in-the-middle. Walking towards WS services, this chapter summarizes and explains service characteristics. Unless you are a WS expert already, this is one of the chapters that really help you to understand what a service should be, how isolated and de-coupled it must/can be and how complex IT architectures can be mapped to a sensible service oriented architecture.Here you get a good analogy of services to lasagna (really good examples that stick as pictures)Ps.: As a note to the publisher, I think the images on page 73 and 74 are in the wrong order. Too late though, the ink has dried.Chapter 4: Classification of ServicesThis chapter allows you to organize services into elementary services, composite services and process services. It also covers the difference between service composition (BPM/BPEL) and aggregation (ESB, client). Other concepts for organizing services in this book are: granularity, actor (who works with a service), channel of access, security requirements and many more.Chapter 5: The SOA PlatformThis chapter switches gear for a moment and uses SOA terminology that hasn't been introduced until here but is getting explained in the following. The chapter also talks about REST and SOAP services as first class citizen technologies in a SOA. This chapter thus is where you learn about ESB, BPM, Case Management, Events, Business rules and user interfaces to SOA (which is also where Oracle ADF gets its mentioning). A lot of pages are dedicated to service security, design and develpment tools.Chapter 6: Solution ArchitecturesChapter 6 is one of my favorites and compares SOA offerings and suites provided by Oracle, IBM and Microsoft, allowing readers to understand what each of these vendors has to offer and how products could integrate. The chapter doesn't announce a winner, which I think would be a bad move for a generic SOA book, but really saves you from investigating this yourself. As the authors stress it, it is important to understand what is best in breed for a project and where you shop this best looking at the full package.Chapter 7: Creating a Roadmap, How to Spend Your Money and WhenThis chapter discusses what it takes to implement SOA in a company: stake holders, requirements, wrong and right expectations, benefits and money gains. Personally I think the graph on page 1999 is a great idea for showing what you can expect on each of the stages involved when implementing SOA. Its really well done.Chapter 8: Life Cycle ManagementWhat you build today is what you maintain tomorrow and throw away the day after tomorrow. This basically is what the authors call the the lifecycle of SOA solutions. and in fact its all about change management and the conflict that exists between developer and administration personnel that both have a different agenda. Governance plays into this as well. Basically you learn that you need to keep the "eye on the bal" during the realization of SOA architectures.Chapter 9: Pick your BattlesThis chapter is all about how to get people to buy in to a SOA architecture and how to ensure that the implementation - especially when implemented in distributed teams and by different departments - follows defined rules and definitions without being prohibitive to change.Chapter 10: Methodologies and SOAThis chapter discusses the impact SOA has to different aspects of software development and provides methodologies to use.In case you did not order the book while reading my review, here's a dense list for why you should:- Clear story line- Chapters that make sense and float- No fluff just stuff- Explaining complex concepts simple in real life examples- Back / Forward references- External document references- Good SOA coverage from a project perspective looking at SOA as a whole and not just services The one thing I wanted to have immediately when reading this book was a second book that closely follows this book's chapters and that - by example - shows how to implement various SOA components for people to have example code and instructions. This could be using the Oracle stack (preferred) but also would be valuable for any of the other introduced vendors. However, code and implementation samples was not in focus for this book and this is good the way it is. Frank

Jason G Buck Mar 06, 2013

This book was written to a specific audience and covers the real-world SOA concepts, methodologies, and tools very effectively. I was happy to discover that it wasn't written at such a high level that concepts appeared inapplicable in the real world. I also appreciated the fact that it didn't dwelve into the details or focus on SOA from a specific vendor's point of view. There are other books for that! Overall, this book was very informative and an excellent read.

SOA Made Simple:

What do you get with eBook?

Key benefits

Description

Who is this book for?

What you will learn

Product Details

What do you get with eBook?

Product Details

Packt Subscriptions

Frequently bought together

Table of Contents

Recommendations for you

Customer reviews

Filter reviews by

People who bought this also bought

FAQs