SOA Made Simple

By Lonneke Dikmans , Ronald van Luttikhuizen
  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Understanding the Problem

About 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.

Publication date:
December 2012
Publisher
Packt
Pages
292
ISBN
9781849684163

 

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.

 

Summary


In this chapter, we addressed the problem that a lot of companies face today, their organization and their IT are organized in silos. This leads to duplication of functionality and information and makes it hard and expensive to change and to adapt to changing markets, rules, and regulations. The IT department is not able to deliver solutions and changes fast enough and the business people are not able to communicate their needs well enough. This results in IT that is lagging behind and frustrated people in the organization on both sides.

To solve this problem, we need to design our organization in a way that fits the long-term business goals of an organization. The IT solutions need to be aligned with our organization and with these same goals. To make this possible, architecture should be applied whenever a change is implemented in the organization that involves information (systems). There are different types of architecture that can be applied such as enterprise architecture, solution architecture, and project architecture.

Service Oriented Architecture is a specific reference architecture that helps solve the data and functionality duplication, thus making the companies that apply this more flexible, and operate more efficiently.

In the next chapter, we explain in detail exactly what services and Service Oriented Architecture mean, and how this type of architecture is a solution to the misalignment of business and IT, and for functional and data duplications in the situations that we've mentioned in this chapter.

About the Authors

  • Lonneke Dikmans

    Lonneke Dikmans lives in the Netherlands with her husband and two children. She graduated with a degree in cognitive science from the University of Nijmegen in the Netherlands. She started her career as a usability specialist but went back to school when she lived in California to pursue a more technical career. She started as a JEE developer on different platforms such as Oracle and IBM, and specialized in integration. She now works as an architect, both on projects and as an enterprise architect. She has experience in different industries such as financial services, government, and utilities. She advises companies that want to set up Service Oriented Architecture and Business Process Management. Lonneke was one of the first five technical experts to be recognized as an Oracle Fusion Middleware Regional Director in 2005. In 2007, the program was renamed and is now known as the Oracle ACE program. Lonneke is a BPMN certified professional and was awarded the title of Oracle Fusion Middleware developer of the year by Oracle Magazine in 2007. Lonneke is the managing partner of Vennster with Ronald van Luttikhuizen. Vennster is a knowledge-driven organization. Vennster’s single most important ambition is to help her customers improve their products and services by improving the quality of the information flow. This is accomplished by offering services in the areas of User Experience, Business Process Management, and Service Oriented Architecture. Lonneke has contributed to the Oracle SOA Suite 11g Handbook, Oracle Press by Lucas Jellema that was published in 2011. She publishes on a regular basis in magazines and on the internet, participates in podcasts, and speaks at international conferences about Service Oriented Architecture and Business Process Management.

    Browse publications by this author
  • Ronald van Luttikhuizen

    Ronald van Luttikhuizen lives in Nijmegen, the Netherlands with his partner Susanne. He has over 10 years of experience in IT. Ronald studied Computer Science at the University of Utrecht and University of Wisconsin – Madison and received his MSc degree in 2003. Ronald creates valuable solutions for the business using a structured approach to Service Oriented Architecture. He takes into account both technical and functional aspects of a process to come up with a feasible solution. Ronald worked in projects for government, financials, energy, logistics, and services. Ronald has experience in various roles such as architect, project lead, information analyst, software developer/designer, coach, trainer, team lead, and consultant in a wide variety of enterprise applications. He started his career as a specialist in analysis and design, application development, and application and process integration. The main technology focus in these projects were UML, Java, and XML. In later years, Ronald focused on architecture within service-oriented environments and other types of EAI environments, describing the to-be architecture, defining roadmaps, guiding implementation, and building parts of the solution. Ronald is a speaker at (international) conferences and regularly publishes articles on Oracle Technology Network, his blog, Java Magazine, Optimize, and participates in OTN ArchBeat Podcasts. In 2008, Ronald was named Oracle ACE for SOA and middleware. Ronald was promoted to Oracle ACE Director in 2010. Ronald wrote several chapters for the Oracle SOA Suite 11g Handbook, Oracle Press by Lucas Jellema and served as a technical reviewer for the book. The book was published in 2011.

    Browse publications by this author
Book Title
Access this book, plus 7,500 other titles for FREE
Start FREE trial