IBM Press Executing SOA A Practical Guide For The Service Oriented Architect May 2008 ISBN 0132353741
Chapter 4 , "A Methodology for Service Modeling and Design." We thank Marc Fiammante, IBM Distinguished Engineer, who, no matter how busy, somehowmade time for those of us who needed his insight and ® leadership. We thank Rosalind Radcliffe, STSM from IBM Tivoli , for providing key insights into some of the SOA infrastructureproducts, and we thank Sankar Singha, IBM Senior Architect, who helped bring all the pieces together when we were writing
Chapter 6 , "Realization of Services." Last but not least, we are
The overall view got lost as optimizing the business most efficientlymeant concentrating on the inner operations of the business units. The overall view got lost as optimizing the business most efficientlymeant concentrating on the inner operations of the business units.
1.2. New Items to Consider
The pressure to become flexible came from growing backlogs andbusiness demands for agility because businesses faced an increasingly dynamic market and global competition. A.1.3 In this book, we deal with technical aspects and their impact, but we do not cover business transformation and changemanagement necessary to reach the most suitable organization for SOA-based enterprises.
1.3. What Makes This Book Different?
You might ask why you should read a book that promises to describe how to execute SOA when we just said that SOA hasbeen used in many places already (and was so even before the acronym came into use). We and an increasing number of our colleagues and partners around the world have been involved in various projects inwhich customers of many industries have engaged in projects with the goal to realize solutions based on SOA principles.
1.4. Who Is This Book For?
Several books already provide the fundamentals to build a service-orientedeconomy and discuss how to start the business transformation associated with the journey toward it. A.1.5 As with our earlier book, SOA Compass, which gained acceptance at hundreds of libraries at universities and researchinstitutions, we attempt to address an academic audience and give input to research projects.
1.5. What Is Covered in This Book?
A.1.7 From the many projects that have been realized, one aspect has become crucial: namely how to approach SOA governance to organize the project and the enterprise for SOA. As we have already hinted, it is important to manage the services within the enterprise, and even more important to gain issues that arise from introducing a repository; semantic issues; and how, when, and why to use a repository to achieve themost efficient solutions.
1.6. Links to developerWorks Articles
www.oasis- open.org/committees/tc_cat.php?cat=soa . www.w3.org/2002/ws/ .
Many business executives and professionals, although highly focused on defining their strategy, managing their operations,and conducting their businesses, do not focus on "architecture."Whether service oriented or not, architecture is something that IT professionals are concerned with but business professionals are not (according to popular myth). There is gathering momentum behind the idea that many of the same principles that are  applied by IT architects to information systems can, and should, also be applied by "business architects" to businesssystems.
2.3. Focus on Business Architecture
It is almost impossible to be in business today without explicitlydeciding the role that information systems must play as a weapon in the corporate armory. Architecture has been defined in many ways, but if we accept  the IEEE 1471-2000 standard definition, business architecture should be "the fundamental organization of a[business] system, embodied in its components, their relationships to each other and the environment, and theprinciples governing its design and evolution." Defining such an architecture is not intended to guide others to build businesssystems, but to help others understand the nature of the business systems.
2.4. Business Process
 This standard Business Process Modeling Notation (BPMN) provides businesses with the capability of understanding theirinternal business procedures in a graphical notation and gives organizations the capability to communicate these proceduresin a standard manner. An  Language (BPEL) was developed by a consortium of software vendors and is now supported by many IT platforms.
2.5. Business Components
The sum total of business processes and subprocesses implemented or included by collaboration with partners within aparticular domain of accountability might be categorized into activities that relate to specific business functions. Figure 2-1 illustrates a methodology developed by IBM for identifying and reasoning about business components.
2.6. Lifting the Veil
When business processes and subprocesses are identified and assigned to specific business components, each with itsstrategic value and impact to the enterprise identified, it becomes possible to narrow focus to particular functions andtheir sequence of activities for enhancement. By identifying services that are critical to the business, it becomes possible to reason about those that exist but needenhancement or replacement and those that don't yet exist but must be introduced to achieve strategic goals.
Chapter 1 , "Introducing SOA," we opened up the discussionwith a realization that SOA is an emerging but nevertheless real influence in business systems around the world. The marketinghype may be waning, but leading adopters of SOA are
2.7. Link to developerWorks Article
The usual solution for application integration has been point-to- point interface solutions, as depicted in Figure 3-6 . The usual solution for application integration has been point-to- point interface solutions, as depicted in Figure 3-6 .
3.2. Organizing for SOAAlthough it is true that SOA may grow "organically" for a time, such an approach will inevitably sputter out without a groupdedicated to its vision and vitality.
If a group already exists within the enterprise that is responsible for strategic and tactical vision, has good interfaceand alignment between the business and IT, performs business case and financial analysis, and has a portfolio oversight role,this group should also take on the responsibility of governing the SOA. Note It might be the case that in the beginning of theSOA journey certain service capabilities do not yet exist in IT (for example, services designer skills,service implementation skills, SOA technology skills, and even enterprise architecture skills).
3.2.2. Roles and Responsibilities
Most of these positions will be in the line organizations, but some ofthem may be housed in the SOA CoE, especially during the first year of SOA implementation or for roles that would benefit froma more enterprise level of control. The following SOA roles and responsibilities have been found to be a worthwhile startingpoint for consideration: The service developer is a software engineer who builds services based on a service specification as given by theservice designer.
3.3. SOA Governance Considerations
Policy— A definite course or method of action selected from among alternatives and in light of given conditions to  guide and determine present and future decisions. The governance entity-relationship diagram in Figure 3-8 uses the definitions we just discussed and has been successfully used in various governance consulting assignments.
18.104.22.168. Services Development Life Cycle (SvDLC)
This area is concerned with reviewing and enforcing the rigor of the agreed-to enterprise policies and procedures upon systemdevelopment, which may or may not involve services for a particular system or project. Unfortunately, it is quite commonfor projects and their corresponding development teams to take shortcuts to meet project deadlines.
1. Solution review— The solution architect will have created
a solution architecture document that has identified the solution approach and high-level design to be taken,including identifying the services to be created or reused on this project. This is a vital time to optimize the services planand the project development plan, as follows: a.
e. Validate that the business requirements are
f. The Service Registrar should be alerted to new services or changes
being met. The test team responsible for integration testing should review the SolutionArchitecture Document and request clarification and change as needed.
2. Service design review— The service design document
must be validated before commitment of development resources is allowed: a. The service specification must adhere to all policies and standards in effect.
b. The service design document must be validated
c. All service producer and consumer concerns
as adhering to the solution architecture document, including any business, information,or technical agility requirements, as well as security and compatibility requirements. The test team responsible for integration testing should review and validate that they understandthe service design and are able to perform the necessary testing of the service.
e. The security design should be assessed as towhether it follows the minimum security baseline standards.
3. Development to test review— Handoff from development
to integration test occurs: a. The developers will review the scope of the development, including interfaces andmessaging, and present the service and component unit testing performed.
b. The test team responsible for integration testing
will review their service's integration test plan and ask for feedback. c.
4. Test to acceptance review— Handoff from integrationtesting to user acceptance testing occurs:
a. The testers review the results of their testing
with the users, including solution, integration, and performance testing. b.
5. Certification signoff— Users have validated that
Standard SvDLC Controls Handbook, business agility service plan, technical agility service plan, information agility plan, IT SOA design standards, IT information design standard, IT testplan design standard. Metric Number of services reused and created in analysis, number of changes made during design perproject, number of test cases changed per project, number and severity ofdefects in integration test, number and severity of defects in the useracceptance test.
22.214.171.124. Service Life Cycle
The approved business agility plan is thestandard to be used for giving priority to IT portfolio priority. Procedure The technical agility task force will meet quarterly and include global and visionary All POs will undergo review by procurement as meeting the requirements of theapproved technical agility plan.
Procedure Development will assess and create their plans for buy versus build using the sourcing policy. Metric Number of services reused, bought, and built.
126.96.36.199. Business Value
Business Value Table Responsible Party PMO with the CoE. Procedure For each project that is funded, the PMO will identify the business value parameters that were part of the business case andcommunicate these to the project team for inclusion in the modeling and monitoring.
188.8.131.52. Regulatory Compliance
Mechanism Summary of the regulatory checklist and service design review results available for auditor review. Metric Number of services supporting regulatory requirements.
Procedure During design review, the service will be assessed for following the minimum security baseline. Metric Number of security violations detected or found to be monitored in balanced scorecard.
184.108.40.206. Service Ownership
Mechanism Service registry management reports Metric Number of different development groups that own services reflected in balanced scorecard. Procedure Find a business services member who "gets it," and hold more in-depth follow-ups to help him or her become a "champion."Implement a communication plan per up, Mechanism Corporate intranet, company newsletter.
220.127.116.11. Education and Mentoring
Procedure Review staff profiles and work with staff managers, identify and fund training courses, and identify staff that will take thetraining."Train the trainer"—Take the best staff and train, and then leverage across theorganization. Metric The training and mentoring progress will become part of the enterprise's balanced scorecard.
3.5. Links to developerWorks Articles A3.1 Portfolio Management, an Introduction
www.enterprise- architecture.info/Images/Services%20Oriented%20Enterprise/EA_Services- Oriented-Enterprise1.htm . www.enterprise- architecture.info/Images/Services%20Oriented%20Enterprise/EA_Services- Oriented-Enterprise1.htm .
Chapter 4. A Methodology for Service Modeling and Design When the programming model shifted from the traditional
The seminal work in this field was done by the Gang of Four authorsin the book called Design Patterns: Elements of Reusable Object-Oriented Software. Rational Software, now a part of IBM, has providedan extension to Rational Unified Process (RUP) called RUP- SOMA (see the " References " section), which is built on a service-oriented analysis and design technique developed by IBM called Service Oriented Modeling and Architecture (SOMA).
4.1. An SOA Reference Architecture
The access constraints, however, are dictated by the architecturalstyle, guidelines, and principles that apply to a given SOA solution. The channels can be in the form of different user types (forexample, external and internal consumers who access application functionality through access mechanisms likeB2B systems, portals, rich clients, and other forms).