Lecture 8 - SOA and The Organization

1. Book Author: Nicolai M. Josuttis
Chapter Eight: SOA and The Organization
IT-Slideshares http://it-slideshares.blogspot.com/

2. Contents
8.0 Purposes of this chapter
8.1 Roles and Organizations
8.2 Funding Models
8.3 Summary

3. 8.0 Purposes of this chapter
 This chapter will discuss how SOA’s distributed processing affects the
organization and structure of companies and enterprises.
 We’ll focus on key success factors of SOA that impact organizations as
a whole.
 You will come to understand why SOA is fundamentally a business
strategy rather than an IT strategy.

4. 8.1 Roles and Organization
 Chapter 7 discussed different ways of designing
business processes and services.
 One question not discusses was who (or which role ,
from an organizational point of view) is responsible for
such designs.
This leads to the general question of responsibility for
distributed processes.

5. 8.1.1 From Monolithic Systems to Distribution
 SOA is a concept for distributed systems.
 Systems and companies are often formally structured in a way that does not really
support distribution, the dominating structures of companies are departments.
 When this companies need some few functionality :
• New department being created.
• The department usually have their own client applications, so the average internal or
external customer or call center agent has to deal with many different clients (Figure 8.1)

6. 8.1.1 From Monolithic Systems to Distribution
 Integration and distribution are becoming increasingly important.
 Although companies still have monolithic department-oriented structures ,the
departments and systems are starting to work together.
 Distributed business process change this old department-oriented model.
 Having distributed processes means that you need :
 Distributed planning
 Distributed design
 Distributed realization
 Distributed operation
 Spanyi03 put it follows :
 While each functional group often does a great job of managing the work process contained
inside its turf, they are less adept in the coordination of work across department
boundaries—the essence of overall enterprise performance from the customer’ perspective.
In other words, “enterprise business processes” are those that touch more than one
department, group, or internal fiefdom in the company and largely determine a company’s
overall effectiveness.
 Some organizational structures are required to supplement departments
 For the development of new distributed functionality , you need a project-oriented
organization structure.
 For the maintenance of cross-department functionality (such as process services), you
need some cross-domain departments.

7. 8.1.2 Solution Management
 Developing any new functionality can be a project with an impact on several
different departments (or business units, companies , or teams)
 Need introduce the role of a project manager to manage and accompany the project
throughout its lifetime , name of this role “Solution Manager”.
 Project or solution manager begins by creating a high-level design to determine the impact
on existing systems :
 This process identifies which domains (companies , departments , teams, …) to get into contact with to
discuss the details.
 Provide and maintain the core of all business process, data, and basic business rules.
 Has to bring data and capabilities together to serve business needs.
 Only with their help can you compute the business case, and you can sum up all the effort
and resources required for the realization of the new functionality.
 The high-level or solution design is importance to identify which departments (business ,
units, teams,…
 The Solution manager’s support is also needed during the realization of a solution
 Project or Solution managers might even have a role to play when a project is finished.
 Starting a new project to fix a problem.

8. 8.1.2 Solution Management (Cont)
 Example
 Introduce a bonus system into a company , you might add a new system to
manage bonus, extend existing services to deal with bonuses, and provide new
services to pay the bonuses or rank customer for bonuses

9. 8.1.3 Collaboration
 One key requirements for SOA : collaboration
 From the formulation of an idea to the maintenance of its realization, distributed systems
require collaboration.
 Collaboration is difficult in organizations consisting of isolated departments
behaving as fiefdoms.
 In these cases changing the culture of the company will be a key, if difficult , factor is
ensuring the success of SOA.
 When departments are used to being in control, giving up that control to a solution
manager and making their own functionality dependent on other departments in a huge
move.
 Because things will not always work smoothly, you might run into the “not invented here”
syndrome.
 Departments that are organized as profit centers can be also be a problem
 You can easily run into trouble if your organizational structure is not prepared for it.
 SOA might serve as a problem detector.
 SOA will make it clear how well a culture of collaboration has been established.
 If collaboration is not established , however , SOA can be blamed for it.

10. 8.1.3 Collaboration (Cont)
 SOLUTION MANAGEMENT BY EXAMPLE
 One phone company I know of maintains most of its software in such a way that new releases get
rolled out three or four times a year. Of course, this software has to match with existing
marketing.
 The process usually starts with marketing thinking about a new product or raising the need for a
process optimization . A solution manager gets the task of making a high-level design and
finding out how much the new feature or optimization will cost. Then, before the real
development of a new release starts, the solution manager and the affected departments come
together to make a release plan. The goal is to maximize the benefits for the company as a whole,
at the lowest cost. The departments usually have budgets for each release, and the release plan
should ideally use exactly 100 percent of each department’s available resources. That is, the goal
of the release planning is to give each team tasks that will occupy 100 percent of their
development time, and to plan the tasks such that they will create the best possible benefit.
Together, these multiple tasks will lead to the realization of complete solutions for the benefit of
the company as a whole.
 Of course, in practice things are a bit more complicated. For example, developers never have 100
percent of their time free for development (i.e., in agility terms, you need to know the “velocity”
of the teams). In addition, you need time to verify that existing functionality is not broken. In
fact, only the first half of the allotted development time is typically reserved for the development
of new functionality. The second half is for integration and bug fixing. Last but not least, you
must be aware that all your planning can become worthless if a competitor suddenly introduces a
new feature. You’ll have to match this feature as soon as possible, which changes all existing
plans.
 However, experience shows that having the right project-oriented structure for such a case will
help you to react fast. Distributed development also means distributed resources that help to
develop solutions. If an organization has the appropriate structure, this can become a big market
advantage.

11. 8.1.4 Management Support
 Another key success factor for SOA is management support.
 SOA is a strategy that has a lot to do with the culture and structure of a
company.
 Collaboration is key, and CEOs as well as CIOs must understand the
impact SOA will have on their organizations.
 Conclusion :
 They must allow enough time for the corresponding processes to be
set up, and not expect that all the promised benefit will be realized
in a year.
 SOA is a strategy that must be established over the course of several
years.

12. 8.2 Funding Models
 You will need funding for your SOA strategy as a whole.
 You will have to define some general aspects (infrastructure, policies, patterns, and so on).
 Provide general solutions.
 One question related to this topic is which model should be used to pay for SOA
and new services.
 The main problem is that the business case of SOA depends on some concepts that will
only pay off when they scale.
 Example : Having an integrated , reusable service doesn’t pay off for the first
communication between a provider and a consumer, but it does when there are multiple
provides and consumers.
 Who should pay for the implementation of a new service? In principle , there are a
lot of possible funding models for services.
 The first consumer of or solution needing a service has to pay for its development.
 All consumers of a new service has to pay for its development.
 Providing a new service is an investment of the provider and there is a pricing model so
that each call of service has an associated cost.
 There is a pool of resource to fund the creation of new services.

13. 8.2 Funding Models (Cont)
 Note that again these models lead to collaboration instead of the idea of profit centers.
 You can also introduce and realize distributed processes among profit centers.
 But then you have to make a judgment about the worth of each solution and service so that
consumers can pay for the effort appropriately.
 Collaboration has its limits. E.g :
 That a solution turns out to be inappropriate , but an appropriate solution would require that
one department (or business unit or company) be given a lot of additional resources , while
another department would save resources.
 Ideally , for the realization of the solution the resources save could be transferred to the
department where the additional effort is required.
 However, in practice this almost never works officially , due to organizational and functional
constraints.
 Similarly , improvements in processes often require investments of effort now that will pay off
later in terms of maintenance.
 But when it comes to the question of whether to invest for better maintenance or provide new
business features based on pure designs , new business features usually win.
 Otherwise , you might find yourself out of the market.
 Finding the right balance ,which, by the way , also requires collaboration is still an issue

14. 8.3 Summary
 SOA is a strategy that impacts a company or organization as a whole.
 Distributed processing requires collaboration, because you need distributed
planning, distributed design, distributed realization, distributed operation, and
distributed incident management.
 SOA leads to a combination of department-oriented structures responsible for data
and core business rules and project-oriented structures responsible for designing
and realizing solutions for business requirements.
 The role of project or solution manager is required to coordinate among
departments.
 This person is responsible for creating a high-level design.
 Providing support during the realization of the solution.
 Assisting in maintenance efforts.
 There are different funding models possible for realizing new processes and
services.
 Most common are funding pools and models where the first consumer or solution to
require the service pays the development costs.
 Collaboration and top management support are key success factors for SOA.