34,79 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
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.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 404
Veröffentlichungsjahr: 2012
Ähnliche
Table of Contents
SOA Made Simple
SOA Made Simple
Copyright © 2012 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: December 2012
Production Reference: 1131212
Published by Packt Publishing Ltd.
Livery Place
35 Livery Street
Birmingham B3 2PB, UK.
ISBN 978-1-849684-16-3
www.packtpub.com
Cover Image by David Gimenez (<[email protected]>)
Credits
Authors
Lonneke Dikmans
Ronald van Luttikhuizen
Reviewers
Howard S. Edidin, MCTS
Anant Kadiyala
Derkjan Zweers
Acquisition Editor
Robin De Jongh
Stephanie Moss
Lead Technical Editor
Arun Nadar
Technical Editors
Brandt D’Mello
Worrell Lewis
Project Coordinator
Shraddha Vora
Proofreader
Mario Cecere
Indexer
Monica Ajmera
Graphics
Sheetal Aute
Valentina D’silva
Aditi Gajjar
Production Coordinator
Conidon Miranda
Cover Work
Conidon Miranda
About the Authors
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.
I would like to thank the people that I have worked with over the years that helped shape my thoughts about Service Oriented Architecture. It would take too much space to list them all. Everyone contributed in different ways and were from different fields: technical people, enterprise architects, project managers, departmental managers, product managers, and so on. I would like to thank the reviewers Derkjan Zweers, Anant Kadiyala, and Howard Edidin for their valuable input. Their perspective, remarks, questions, and suggestions were very valuable. Last but not least I would like to thank my husband Hans and our children Mathijs and Anne for their support, encouragement and patience. My final thoughts are for our neighbor Dafnis, who died earlier this year at the age of 13. His courage and determination have become an example for me. We miss him!
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.
I would like to thank everyone that helped me in my professional career and my personal life. Without them I wouldn’t be able to do the job I do today! A big thanks to my friends and family for supporting me and putting up with all the time I spent on the book and not with them; especially Susanne.
Last but certainly not least I would like to thank the reviewers Derkjan Zweers, Anant Kadiyala, and Howard Edidin and the people at Packt for their valuable input, suggestions, improvements, help, and patience! Without them this book wouldn’t exist.
About the Reviewers
Derkjan Zweers is an Information Architect in the province of Overijssel, a regional government in the Netherlands. His primary responsibility is to advise the management on IT-related solutions. His roots in education—he holds a Bachelor of Education degree—have equipped him to communicate about his field of work in common, understandable language.
Previously, Derkjan worked several years for a governance agency as an IT Architect and for a multinational as a Desktop Manager responsible for the branches in the Netherlands.
Derkjan strongly believes in the necessity of one IT agency for the entire Dutch government. He is one of the initiators of the government platform of architects (PPA-Provinciaal Platform Architecten). The platform strives for standardization across the regional governments as a stepping stone to standardization across all government agencies. Service Oriented Architecture is one of the fundamental principles.
During the years 2009 – 2011 Derkjan participated, with the authors, in a major SOA implementation and experienced at firsthand how the theory worked out in practice. His experiences have reinforced his belief that SOA is not primarily a technical issue but rather an organizational one. It is concerned with questions such as the following: what are the objectives of the business and is SOA the means to deliver them? What has to change in the IT-governance? Do vendors deliver solutions that fit an SOA? These are just some of the important questions that are addressed in this book.
Apart from information architecture, Derkjan likes gardening and watching sci-fi movies, and he has an interest in everything that is out of the ordinary and does not fit our established patterns.
Howard S. Edidin is an independent BizTalk architect/consultant specializing in providing guidance and training for companies implementing BizTalk. He was first exposed to BizTalk about the time when “Soap on a Rope” was introduced by Microsoft. He didn’t get a chance to use it, until BizTalk 2002 came along. Most of Howard’s BizTalk career has been in contract work, which has allowed him to utilize almost all of BizTalk’s capabilities. Last year Howard established his own consulting company, the Edidin Group Inc., in order to expand the services he provides. Howard has been very active in the BizTalk community. He has contributed several articles to the TechNet Wiki, provided answers to questions on the LinkedIn BizTalk Groups, contributes to several BizTalk Administration blogs, and maintains his own blog http://biztalkin-howard.blogspot.com/.
Howard is certified MCTS in BizTalk 2010 and has been an MCP for over fourteen years.
Howard is also the co-author of Microsoft BizTalk 2010 Administration Essentials, Packt Publishing.
www.PacktPub.com
Support files, eBooks, discount offers and more
You might want to visit www.PacktPub.com for support files and downloads related to your book.
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at <[email protected]> for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks.
http://PacktLib.PacktPub.com
Do you need instant solutions to your IT questions? PacktLib is Packt’s online digital book library. Here, you can access, read and search across Packt’s entire library of books.
Why Subscribe?
Free Access for Packt account holders
If you have an account with Packt at www.PacktPub.com, you can use this to access PacktLib today and view nine entirely free books. Simply use your login credentials for immediate access.
Instant Updates on New Packt Books
Get notified! Find out when new books are published by following @PacktEnterprise on Twitter, or the Packt Enterprise Facebook page.
Preface
A lot of organizations are implementing, or want to implement, Service Oriented Architecture to support their goals. Service Oriented Architecture is a natural step in the evolution of Information Technology; we started out with big systems in universities and banks, and moved to desktop computers in the workplace and at home. We are now moving to solutions in the cloud, offering services to consumers and businesses alike, adding mobile computing to the mix. So what is a service? A service is something that has value. Service orientation is not a difficult concept to grasp, everyone knows services and uses them daily; think of a hotel that offers a shuttle service to the nearest airport. Or the hairdresser that cuts your hair. This book describes how you can accomplish service orientation successfully in your organization and in IT, using a practical and simple approach. It is done without overly complex abstractions, but with examples from different industries and hands-on experience of the authors. The approach is independent of the specific technology or programming language you apply in your organization.
What this book covers
Chapter 1, Understanding the problem?, discusses the challenges that organizations face with respect to information technology and is illustrated with examples. Architecture is explained as a means to solve these problems structurally and in compliance with your organization's goals.
Chapter 2, The Solution, explains how applying SOA can help your organization to solve the problems that were discussed in the previous chapter. In this chapter, the concept of services is explained as well as Service Oriented Architecture.
Chapter 3, Service Identification and Design, describes how services are the base of a Service Oriented Architecture. The process of identifying services and designing their interface, contract, and implementation are important activities when realizing a Service Oriented Architecture.
Chapter 4, Classification of Services, covers the different types of services. You learn in this chapter how classification can help you in your SOA effort. The chapter explains different ways of classifying your services and the reason to choose a particular classification. Classification based on service composition is discussed in detail.
Chapter 5, The SOA Platform, identifies the different components of an SOA platform and explains the use of these components, keeping in mind that to realize an SOA in your organization, you need a platform to build it with
Chapter 6, Solution Architectures, tells us about how you can go for a best-of-breed solution to realize your SOA, or use a product suite. The solution of the big software vendors Oracle, IBM, and Microsoft are discussed in terms of the components you need for an SOA platform.
Chapter 7, Creating a Roadmap, How to Spend Your Money and When?, explains how to plan your endeavor. In this chapter, creating a roadmap for the realization of your SOA is discussed.
Chapter 8, Life Cycle Management, explains how to maintain services. Requirements may change, services may become outdated, and new services may be needed. This chapter discusses life cycle management of services, and tooling that supports registries and repositories.
Chapter 9, Pick your Battles, talks about how during the realization and operation of an SOA you will run into issues with stakeholders. A common pitfall for architects is to be too strict and unrealistic about what can be achieved. This chapter discusses some common issues you will run into and discusses how to handle them.
Chapter 10, Methodologies and SOA, talks about how there are existing methodologies in IT that you are probably using right now in your organization for project management, demand management, and so on. This chapter discusses the impact of using SOA on these existing methodologies.
What you need for this book
To create the code samples given in this book, you need tooling that can display XML. You can view the samples with any XML viewer, text editor, or integrated development environment (IDE) or browser.
Who this book is for
This book is for anyone (architect, designer, developer, administrator, team lead) who is implementing or is about to implement an SOA in an IT-related environment. This guide tells you everything you need to know about an SOA in a clear and easy way. Knowledge or experience with software architecture and information architecture is helpful but not a strict requirement.
Conventions
In this book, you will find a number of styles of text that distinguish between different kinds of information. Here are some examples of these styles, and an explanation of their meaning.
Code words in text are shown as follows: " Both offer showMenuItems as an interface to BreakfastService."
A block of code is set as follows:
When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:
New terms and important words are shown in bold.
Note
Warnings or important notes appear in a box like this.
Tip
Tips and tricks appear like this.
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.
To send us general feedback, simply send an e-mail to <[email protected]>, and mention the book title via the subject of your message.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide on www.packtpub.com/authors.
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Downloading the example code
You can download the example code files for all Packt books you have purchased from your account at http://www.PacktPub.com. If you purchased this book elsewhere, you can visit http://www.PacktPub.com/support and register to have the files e-mailed directly to you.
Errata
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you would report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/support, selecting your book, clicking on the erratasubmissionform link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded on our website, or added to any list of existing errata, under the Errata section of that title. Any existing errata can be viewed by selecting your title from http://www.packtpub.com/support.
Piracy
Piracy of copyright material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works, in any form, on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at <[email protected]> with a link to the suspected pirated material.
We appreciate your help in protecting our authors, and our ability to bring you valuable content.
Questions
You can contact us at <[email protected]> if you are having a problem with any aspect of the book, and we will do our best to address it.
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:
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:
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:
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:
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:
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:
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.
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:
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
