SOA
Practitioners’ Guide
Part 3
Introduction to Services Lifecycle
Painting by: Surekha Durvasula
Contributing SOA Practitioners
Surekha Durvasula,
Martin Guttmann, Principal Architect, Customer
Solutions Group, Intel Corp
Ashok Kumar, Manager, SOA Architecture, Avis/Budget
Jeffery Lamb,
Tom Mitchell, Lead Technical
Architect, Wells
Burc Oral, Individual Contributor
Tom Sedlack,
Enterprise Architecture & Engineering, SunTrust Banks, Inc.
Dr Harsh Sharma, Senior Information Architect, MetLife
Sankar Ram Sundaresan, Chief Architect e-Business, HP-IT
Reviewers
Prasanna
Deshmukh, Director of Architecture, WebEx Communications
Noam
Fraenkel, CTO IT, Mercury Interactive
Steve Jones, CTO Application Development Transformation, Capgemini Group
Brenda Michelson, Principal Consultant and Analyst, Elemental
Links, Inc.
Ashok Nair, Management
Systems Analyst, EAI, Information Technology Services,
City of
George
Paolini, Consultant, Georgepaolini.com
Jeff
Pendelton, Executive Director, SOA
Annie Shum,
VP SOA Strategy, BEA
The authors would like to acknowledge the many organizations and individuals that contributed portions of this document, performed substantial editing, or who provided reviews and feedback. In addition, the authors would also like to thank BEA Systems, Inc. for providing the infrastructure and the platform for developing and presenting this guide.
1.3 Benefits
of the SOA Practitioners’ Guide
1.4 SOA
Practitioners’ Guide: Chapters
2 Introduction
to Services Lifecycle
2.3 Service
Lifecycle Governance
2.3.1 Requirements
and Analysis
3.1.3 Artifacts
(Deliverables)
3.1.4 Service
Lifecycle stage key considerations
3.1.4.2 Differentiation from
Application Lifecycle
3.1.5 Service
Lifecycle Stage Recommended Process
3.1.5.1 Project Initiation
Request
3.1.5.2 Architecture Statement of
Work
3.1.6 Best
Practices and Requirements
3.1.6.3 User Experience
Simulation
3.1.6.4 Business Process Modeling
3.2 Composite
Application Design
3.2.3 Artifacts
(Deliverables)
3.2.4 Service
Lifecycle Stage Key Considerations
3.2.4.1 Enterprise Architecture
Framework
3.2.4.2 Services Classification
Framework
3.2.5 Service
Lifecycle Stage Recommended Process
3.2.6 Best
Practices and Requirements
3.2.6.1 Service Orchestration
(Modeling)
3.3.3 Artifacts
(Deliverables)
3.3.4 Service
Lifecycle Stage Key Considerations
3.3.5 Service
Lifecycle stage recommended process
3.3.6 Best
Practices and Requirements
3.4.3 Artifacts
(Deliverables)
3.4.4 Service
Lifecycle Stage Key Considerations
3.4.4.2 Service Management and
Monitoring
3.4.5 Service
Lifecycle Stage Recommended Process
3.4.6 Best
Practices and Requirements
3.4.6.1 Release Management Tools
3.4.6.3 Enterprise Management
Systems
3.5.3 Artifacts
(Deliverables)
3.5.4 Service
Lifecycle stage key considerations
3.5.5 Service
Lifecycle stage recommended process
3.5.6 Best
Practices and Requirements
3.5.6.3 Correlation between the
IT Service QoS Monitoring Metrics and Services SLA needs
4.1.2 Chief
Information Officer
4.1.3 Program
Management Office (PMO)
4.1.6.3 Information / Data
Architects
4.1.8 Architecture
Steering Committee
4.1.11 Chief
Technology Officer (CTO)
4.1.12 Enterprise
Shared Services
4.1.13 Chief
Process Officer (CPO)
4.1.14 Chief
Security Officer (CSO)
4.2 SOA
Governance and Organizations
4.2.1 SOA
Development Organization
4.2.1.2 Traditional Development
Approach
4.2.2 Enterprise
Architecture: Roles and Responsibilities
4.2.2.2 Enterprise Architecture
Responsibilities
4.2.3 IT
Enterprise Resource Management Process Flow
4.2.4 Project
Initiation Request Form
4.2.5 Request
for Architecture Work
4.3 Simplified
common vocabulary
4.5 Service
Component Architecture and Service Date Object
4.7 Traditional
Data Movement Technologies
4.7.1 Electronic
Data Interchange (EDI)
4.7.2 Extract,
Transform and Load (ETL)
4.8.4 Analysts'
Web Sites with focus on SOA
1.1 Abstract
SOA is relatively new, so companies seeking to
implement it cannot tap into a wealth of practical expertise. Without a common
language and industry vocabulary based on shared experience, SOA may end up
adding more custom logic and increased complexity to IT infrastructure, instead
of delivering on its promise of intra and inter-enterprise services reuse and
process interoperability. To help develop a shared language and collective body
of knowledge about SOA, a group of SOA practitioners created this SOA
Practitioners’ Guide series of documents. In it, these SOA experts describe and
document best practices and key learnings relating to SOA, to help other
companies address the challenges of SOA. The SOA Practitioners’ Guide is
envisioned as a multi-part collection of publications that can act as a
standard reference encyclopedia for all SOA stakeholders.
1.2 Intended Audience
This document is intended for the following audience:
·
Business and IT leaders, who need to start and manage an SOA strategy across
the enterprise/LOB
·
Enterprise Architects who need to drive the vision and roadmap of the
SOA program and the architecture of each implementation that falls under it
·
Program Managers who need to manage a portfolio of sub-projects within
an overall SOA business strategy
·
Project Team Members, who need to map dependencies and develop a
timeline that meets the business expectations
·
Vendors who provide solutions and tools for new business capabilities to
the business and IT
·
Standards bodies which need a better understanding of use cases of how business
and IT plan to leverage technology to meet their objectives.
1.3 Benefits of the SOA Practitioners’ Guide
This document
helps readers to:
- Learn from others: Early adopters of SOA share
their best practices, insights, and views on the state of SOA adoption
across the industry
- Compare alternatives: Identify and define the
key technology components of SOA to establish a baseline reference for
comparison of options
- Improve collaboration: A common language
clarifies the nature of SOA components defined in this document
- Accelerate implementations: This guide defines
the services lifecycle along with the requirements, recommended tools, and
best practices for each of the stages.
- Understand the value of standards: This
document recommends standards for aspects of SOA
- Avoid potential risks: The guide identifies some problem areas not yet addressed by the vendor community.
1.4 SOA Practitioners’ Guide: Chapters
There are three separate chapters that make up the SOA Practitioners’
Guide.
Chapter 1, Why Services-Oriented
Architecture? provides a high-level summary of SOA.
Chapter 2: SOA Reference
Architecture provides a worked design of an enterprise-wide SOA
implementation, with detailed architecture diagrams, component descriptions,
detailed requirements, design patterns, opinions about standards, patterns on
regulation compliance, standards templates, and potential code assets from
members.
This is Chapter 3: Introduction to
Services Lifecycle. It provides a detailed process for services management
though the service lifecycle, from inception through to retirement or
repurposing of the services. It also contains an appendix that includes
organization and governance best practices, templates, comments on key SOA
standards, and recommended links for more information.
2.1 Introduction
After establishing an architecture baseline based on the SOA reference architecture, practitioners should review the services lifecycle. This section briefly describes the service lifecycle and identifies the actors, potential tools, and artifacts associated with each stage of its stages. This document does not cover all the cultural, governance, and organizations changes required to make SOA a success; instead, it focuses on defining best practices for the services lifecycle. The services lifecycle is part of the execution stage in the SOA lifecycle diagram below.
Figure 1: SOA Lifecycle
2.2 Definition
The service lifecycle begins at inception (definition) and ends at its retirement (de-commissioning or repurposing). The service lifecycle enables service governance across its three stages: requirements and analysis, design and development, and IT operations.
Figure 2: Three Stages of the Services Lifecycle
The above diagram illustrates the three stages and the need for an enterprise service repository to enable service governance.
· Requirements & analysis: business initially identifies and prioritizes the business needs. Based on the identified priorities, non-technical staff work closely with business analysts to document the business process, rules, and requirements. High-level requirements include:
o Visually map business process starting from Level 0 downwards
o Define each of the business processes
o Identify business owners for each of the processes
o Identify objectives and current business services gaps
o Map Input and output data elements
o Prioritize business processes and business services
o Capture all the aspects of business service definitions
o Simulate user interface and/or business processes.
· Design & development: during the design phase, the business analysts work closely with the architect to hand off the business requirements. The architect is responsible for the high-level estimates, design, and handover to the development team. The development teams are responsible for developing, assembling, testing, and handing over the composite application to IT operations. Following are some high-level design requirements:
o Review requirements and identify alternatives for each business process
o Design and estimate the components for each of the services, such as portal, integration, infrastructure, data, policy, and business (logical) services
o Identify reuse opportunities for business services
o Develop and execute to a detailed project plan
o Track and report progress to business and IT management
o Obtain business sign-off at delivery of each business service.
· IT operations: this team is responsible for the testing, staging, and production environment with the production environment taking the highest priority. IT operations is responsible for sizing the network and data center. In addition, IT operations is responsible for deploying, monitoring, and providing tier 1 support for all applications supported by IT. Following are some of the high-level requirements:
o Review requirements and identify infrastructure needs
o Establish systems environment consisting of development, system integration testing, performance testing, user acceptance, and product environments
o Assist solutions development teams in systems and application configuration, periodic builds, and capacity planning
o Track and manage dependencies among services and assets
o Deploy and manage business services in production
o Provide application support for business services based on business priority
The details for each of the stages are described later in this section. Following is the high-level IT-process for delivering composite applications to the business.
Figure 3: IT-Process of delivering business composite applications
This process also identifies the role of each of the three organizations in delivering the business application.
2.3 Service Lifecycle Governance
Governance is a set of processes, tools, and organizational structure that is essential for delivering on the SOA promise. Effective re-use of services can only be achieved when organizations adhere to standards and follow proper procedures throughout the service lifecycle. As services are shared among applications, organizations must take care in design, development, and deployment of services to ensure that there is no impact on existing consumers of a service.
Services are shared among various organizational silos with conflicting priorities. Effective governance helps ensure maximum re-usability with minimum disruption. The primary responsibilities of the SOA governance function include:
·
Publication of SOA standards and best
practices
·
Definition and execution of processes
to promote the use and re-use of services at project level
·
To be the custodian of all shared
services for the enterprise or LOB
·
To be the propagator of standards and
best practices across the organization
·
Advertise SOA achievements within the
organization.
Services governance underpins the entire service lifecycle.
Figure 4: Service Lifecycle Governance
The above diagram illustrates the services lifecycle at a high level and observes the following stages.
2.3.1 Requirements and Analysis
The business analysts work with the business to capture the business requirements, preferably in the form of business processes. For initial SOA projects, teams typically focus on a business process that is not enterprise- or LOB-wide, but limited to the scope identified by the leadership team while approving the project funding. The team captures the business logic for the composite application being delivered.
Once the team captures the business process, the business analyst identifies any duplication of the process across the enterprise or LOB. The business analyst searches the SOA repository for business processes that the team could potentially reuse. Once this phase is complete, the business analyst uploads the artifacts to the SOA repository, which in turn triggers the governance process.
The governance process should be specific to the organization and the project. Teams should not consider this stage complete until all approvals are in, especially from the business owners.
2.3.2 Design
Business analysts shall pass on the requirements and business processes to the architect to design the application. Each IT organization typically has its own approach or framework for designing applications.
During this phase the architect identifies the services and their implementation. The architect then searches the SOA repository for potential reuse. The architect need not limit the search for services currently deployed in production; the search could be expanded to search for services currently under development by other teams.
At the end of this process, the architect may have identified services for reuse that have already deployed in products, services that need to be modified to create a new version, services that need to be developed, and services that need to be decommissioned.
The architect uploads all the design artifacts to the SOA repository, triggering a governance process that includes approval from enterprise architecture review boards, project managers, and operations. The project manager shall also use this information for distributing the service development tasks.
2.3.3 Service Development
The architect sends development teams the design details, preferably from the SOA repository. The development teams could be distributed in multiple locations, and each team may have a expertise in a business or product domain.
The development teams develop and test the composite application in an iterative manner and upload the artifacts to the enterprise service repository. When the development teams indicate that the service is ready for deployment, they trigger the governance process.
2.3.4 IT Operations
This team is typically responsible for providing the development, QA, staging, and production environment. As the service development organization receives the design details from the architects, IT operations establishes the environment for development. IT Operations often manages the QA environment as well, because it should be identical to the production environment.
The development team typically provides a build to the operations team. For composite applications consisting of services, the development team provides the IT operations teams with the service assembly. The recommended best practice would be to assemble services based on the information found in the SOA repository.
Once IT operations has assembled the services the team deploys those services to the target node. The business analyst and architect would have defined the business, security, and management policies during the earlier stages. It is now the responsibility of the IT operations to monitor and provide metrics to the business to track business KPIs and review IT-SLAs.
The recommended best practice is for the IT operations teams to map the product instance—including hardware, node name, product version, and application version—back to the SOA repository.
2.3.5 Business Dashboard
Business would like to view different types of information that combine data from monitoring systems, operations data stores, and BPM tools. Such information might fall into one of the following categories:
·
IT-SLAs
·
Business activity monitoring
·
Policy management
·
Service maturity model (matrix for monitoring the life of
the service, and a searchable attribute in the enterprise service repository).
This section identifies the actors, tools used, deliverables, lifecycle stage recommendations, lifecycle stage processes, end-user tooling descriptions, and best practices for each of the service lifecycle stages.
3.1 Requirements and Analysis
3.1.1 Actors
·
Business personnel (typically business operations from LOB)
·
Project managers (business & IT)
·
Business analysts
· Architects (optional)
3.1.2 Tools Used
·
Business requirements tools including office, business process modeling tool,
requirements capturing tools
·
Business process modeling tools including BPMN, Visio, and Pro*Activity
·
Business rules tools including product rules engines and Word
·
User Interface tools including portal simulation tools, Macromedia, Visual Studio, Eclipse, and JSP and HTML
editors
3.1.3 Artifacts (Deliverables)
·
Design models such as UML, BPM (business process models), data flow models
·
Bindings such as JMS, RMI, IIOP, and HTTP(s)
3.1.3.1 Artifact Description
Each LOB defines its own business process, which is captured during this stage of the services lifecycle. Some LOBs may have similar business processes or sub-processes with slight variances. For example, the consumer banking division and the mortgage banking division would be two separate LOBs within a large enterprise with common business processes. Both these LOBs could benefit from documenting and sharing their business processes as well as their key learnings.
The LOB would potentially also run simulations in order to optimize business processes and would use a monitoring and management system to capture and compare actual and simulated results. The business activity monitor provides a dashboard for comparing business results to the established objectives.
The lower levels of the business process definitions would typically be used for developing composite applications. At this level services are identified and mapped to each of the business services (activities). An SOA repository should be the system of record for all these service definitions and dependencies, both for external consumption, and to help IT operations to deploy, monitor, and manage services.
3.1.4 Service Lifecycle stage key considerations
Following are some of the key considerations businesses should factor in during the requirements and analysis stage of the service lifecycle.
3.1.4.1 Business Motivation
Recording business motivation helps map the business process to services. This enables business and IT to have a productive dialog on how to develop and fund the portfolio of services. Mapping helps make the business case for funding the development of the services because it helps businesses understand how services benefit them.
3.1.4.2 Differentiation from Application Lifecycle
Even though the service lifecycle is iterative, it is similar to the application lifecycle. However, one of the best practices for the service lifecycle is to identify existing services that may provide the required functionality. Designers begin by reviewing what already exists to see if it’s applicable; this increases the re-use of existing services and saves time.
3.1.5 Service Lifecycle Stage Recommended Process
Following are some of the recommended templates businesses use to initiate projects.
3.1.5.1 Project Initiation Request
Businesses use this template to submit requests for a project. At this stage the business sponsor of the project evaluates whether the project is feasible and engages the LOB-IT or PMO to assist in this effort.
3.1.5.2 Architecture Statement of Work
Once the business submits the PIR to the LOB-IT or PMO, the IT leadership team engages the business to validate that it meets all the initial criteria. The IT organization then establishes a project team consisting of the project manager, business analyst, and architect to work with the business to estimate the effort involved. Depending on the business priority, the team may or may not be working full time on this estimation.
3.1.6 Best Practices and Requirements
This phase begins as soon as the project is funded and the core team is assembled. Following are the high-level best practices and requirements for this stage of the service lifecycle.
3.1.6.1 Portfolio Management
Business and IT jointly leverage portfolio management tools to manage the portfolio of SOA projects. These tools enable business users to submit their project requests. Tools map requests to the IT governance model and help IT manage applications, integration, data centers, and networks. Depending on the particular tool and objective of the IT organization, tools can also be used for resource planning, skills mapping, and monitoring funding for a project.
Portfolio management software helps IT define a roadmap aligned closely to the business by translating business strategy into high-level business prioritization plans. IT organizations can then execute to this plan, while monitoring it to ensure that there isn’t any deviation. Functionality supported by this type of tool includes:
·
Mapping all the projects to the original business case to help make sure
that they are aligned to the business objectives
·
Keeping track of all these assets in a single repository (different from
the SOA repository) with the capability to highlight duplicate business logic,
dependencies, and resource constraints
·
Mapping all the dependencies and being able to send alerts whenever a
change violates the business rules
·
Managing all change requests and defect tracking, including impact on
other projects
· Exporting tasks and projects to third-party tools such as enterprise service repository, project management, and development tools.
Typically only large IT organizations require a portfolio management tool, because of the licensing and administrative overhead cost associated with such a tool. A single instance of this tool could be used enterprise-wide or for a specific LOB, unless regulations require IT organizations to deploy multiple instances of such a tool. The biggest challenge of leveraging such a tool is encouraging adoption; the IT leadership team needs to enforce it.
The first task of all IT organizations is to document and communicate the process and lifecycle for managing project requests . This task is typically the responsibility of the program management office (PMO) or the application development team.
There are typically two steps to initiate a project. The business owners submits a request to IT for initiating a project, and IT engages a technical team to estimate the effort for the projects.
Based on the estimates, the IT board of directors may approve or reject the project. If they approve, a team is assembled under the leadership of a project manager to deliver the application to the business. The best practice is to map the entire application lifecycle management using this tool.
3.1.6.2 Requirements Capture
These tools help capture, prioritize, and track the development of all the business requirements. Following are the some of the capabilities that these tools should provide:
·
Create a repository of business requirements for a given project
·
Provide a single repository for all projects
·
Provide capability to prioritize requirements based on cost, resources,
and benefits
·
Identify and track cross-project dependencies
·
Conduct what-if scenarios and provide impact analysis reports
· Assign owners to requirements and tasks and track status.
It does not matter whether the business analysts capture this information using a requirements capture tool or a product like Microsoft Office. What is important is that the requirements are captured in business terms, without technology vocabulary, SQL statements, or references to packaged applications. In addition, the project team should categorize requirements by business functions and have them approved across different phases.
3.1.6.3 User Experience Simulation
With text-based specifications of applications, business people don't
get to see and interact with applications until they're already completed. Making
changes at this stage leads to cost overruns, time-to-market delays, and
miscommunication between business and IT. Prototyping—either with static screen
images or low-fidelity coded wireframes— has largely failed to solve these
problems, since business people and end users must "fill in the
gaps" to picture the full functionality of the application. And
prototyping typically siphons off precious development resources, which
increases cost and time to market.
New tools
can simulate the user interfaces to all kinds of business applications. These
tools offer a simple, drag-and-drop paradigm to assemble rich,
high-fidelity simulations of applications—including business logic and
data interactions—prior to development. The simulations are easy
for business people and end users to understand, providing a true
"test drive" of the final product. The output is a visual blueprint
for what to build, eliminating confusion, cutting costs, and enhancing user
adoption. Best of all, no IT resources are required to build the simulations,
which can be done quickly by business analysts, user-experience designers,
project managers, and architects.
The
following capabilities should be provided by this class of simulation
tool:
·
Drag-and-drop assembly of high- or low-fidelity simulation screens
·
Ability to link data and business logic into the simulation
·
Collaborative, team-based definition environment
·
Capture and documentation of requirements in context of the
simulation
·
Built-in support for use-case scenarios and workflows
·
Reusable definition assets
·
Ability to encapsulate a simulation in a document that can
be e-mailed.
People don’t adopt business applications unless they’re easy to use—or
at least, easier than what users were working with before. But teams often
don’t test applications with end users until they are almost ready to deploy.
This can have costly consequences if users demand changes. A new class
of tools solves this problem by letting usability experts quickly create
and test high-fidelity simulations directly with users in a rapid, iterative
process prior to development.
Simulation is now a best practice for development organizations that
want to move the process of usability testing to the front of the software
development lifecycle (SDLC) process. By working closely with business analysts
and developers early in the process of defining applications, teams quickly and
inexpensively can fix many of the common problems associated with poor
usability. A centralized user experience team can provide the following benefits:
·
Standardized best practices around usability and user testing
·
Education, training, and mentorship to the rest of the design and
development team
·
Creation and maintenance of reusable simulation (definition) assets that
reflect corporate best practices
·
Feedback and direction early in the SDLC
·
Process
guidelines, style guides.
3.1.6.4 Business Process Modeling
The BPM tool is used to capture the business processes during the requirements stages. The tool should provide the following capabilities:
·
Business process modeling: capability for business users to easily model processes, define
business rules and key performance indicators (KPIs), and simulate, test and
develop end-to-end process flows.
·
Business activity monitoring: real-time and historic analysis and reporting capability. Real-time
process monitoring, escalation and management helps quickly identify any
problem in the business process quickly to help resolve it.
· Business process execution: execution of the automated component of the business. This includes orchestrating all resources—people, organizations, applications and systems—to ensure flawless execution and exception management.
The business process modeling tool can help capture business processes during the requirements stages. This tool is generally used by business analysts to model the business process using common industry notations provided in the tool and based on standards such as BPMN and UML. Typically the business process modeling starts from Level 0 and processes are further defined to lower levels, as required. The business process could be modeled with a view to achieving one of these objectives:
·
To simulate a new process through multiple scenarios before committing
to the resources for executing it. For example, a line of business is focusing
on business optimization because it is entering a new market, rolling out a new
product, or starting a marketing campaign.
·
To align IT more closely with the business. In this case, the business
process modeling tool helps capture and share
the business process—and maybe even screen flows—to help build consensus across
multiple teams and geographies.
Figure 5: Business Process Modeling
The above diagram illustrates a typical business process modeled during the requirements phase. The business analyst interacts with the business to capture events, manual and automated activities, and business rules. The architect may participate in these meetings as an observer to better understand the rationale driving the business process.
The business analyst interacts with the architect to define and refine the next level of details during the analysis phase. Once the business analysts and the architects have modeled the business processes to the lowest level that the business can define without going into the technical details, they jointly review business services in the enterprise service repository to determine whether the services already exist or will need to be built. BPM tools help them in this process by enabling them to:
·
Capture all business requirements in the form of business processes such
as activities, rules, and policies
·
Simulate end-to-end business processes to identify bottlenecks and
improve overall process
·
Review business processes globally and invite other LOBs to participate
in these discussions
·
Capture local and regional requirements
·
Capture
both manual and automated processes.
3.1.6.5 SOA Repository
This is the repository that enables automating the governance process across all products. It stores all the relevant product metadata defining the business processes, requirements, and simulation parameters. In addition, enterprise architects can also upload to this repository the enterprise standard documents consisting of patterns and architecture frameworks. The SOA repository should also enable both IT and business to modify the business process to match their internal governance.
3.2 Composite Application Design
3.2.1 Actors
·
Project manager (IT)
·
Business analysts
·
·
Project architects
·
Designers
·
Technical leads or lead developer
3.2.2 Tools Used
· Design: Rational, Together Architecture, Eclipse, and others
3.2.3 Artifacts (Deliverables)
·
Design models: UML, SCA service assembly model, and others
·
Bindings: JMS, RMI, IIOP,
HTTP(s), and others
3.2.3.1 Artifact Description
This stage of the service lifecycle generates models that represent the system flow, data flow, enterprise data model (represented in the form of Entity Relationship Diagram(ERD)), application design (represented in UML), activity diagram, and sequence diagram. During this phase, the team also generates the high-level deployment model, identifying the servers, OS, middleware, databases, firewall, and load balancers.
The application designer could be an architect, technical lead, or lead developer, and may decide to use some of the tools in the market. Typically this tool is based on RUP or a variation of RUP and would consist of artifacts such as activity diagrams, use cases, class diagrams, ERDs, deployment models, and deployment models. Architects should share these artifacts with the team for review and approval, and provide instructions to the development teams.
3.2.4 Service Lifecycle Stage Key Considerations
3.2.4.1
Enterprise
IT organizations should standardize on an architecture framework that defines architecture standards, development processes, design patterns, and tools. Most IT organizations will already have adopted one of the standard application lifecycle management processes and modified it to fit its own needs. In addition, there are other well known architecture frameworks such as Zachman, Federal Enterprise Architecture (FEA) and The Open-Group Architecture Framework (TOGAF). IT must adopt an architecture framework enterprise-wide to be successful in implementing SOA.
3.2.4.2 Services Classification Framework
A services classification framework helps provide a basis for design and development of services and is essential to achieving a flexible architecture. Services could be classified into multiple categories such as:
·
SOA reference architecture, including shared data service, business
process, and portal service
·
Portfolio of services, including quote-to-cash services and mortgage
approval services
·
LOB services, including sales and support services.
After
the services have been identified, the team classifies them based on the defined
standards. Classification helps business managers, project managers, and the development
team to identify what services are being developed and for what purpose. This
makes it easier for the project manager to distribute development tasks to the
appropriate teams.
3.2.4.3 Service Granularity
Service granularity refers to the level of abstraction or how much functionality the service covers. Teams can apply the concept of granularity either to the service itself or to the service methods.
In determining service granularity, architects need to consider performance requirements. Fine-grained services such as Enterprise Java Beans (EJBs) are typically easier to understand and implement, since in many cases much of the work is already done. However, if performance is a consideration, then aligning services with existing EJBs may not turn out to be the optimal solution. A fine-grained architecture that relies on multiple request and response pairs (a “chatty” protocol) may offer slower performance. In order to reduce the effects of network latency, system I/O, and thread/process wait states, it is much better to create a coarse-grained service that internally composes multiple business domain services and uses fewer messages.
Service granularity must take into account legacy system interfaces that are (and must remain) unaware of the new protocol. Architects must plan carefully to avoid any changes to legacy systems when adding a new data channel in the form of the Web service.
Finally, in determining granularity architects must consider the possibility of future changes to the underlying implementation. In general, businesses benefit from using coarse-grained facades or patterns to hide the fine-grained services beneath them. The goal is to insulate services from changes to the underlying implementation by designing them at a level of granularity that will allow for future expansion with little impact to the clients.
3.2.4.4 Reuse Strategy
Reuse of a component starts at the design layer. Architects should design components so that the client use of that component only executes or inherits the methods that are needed to perform a given task. Shared components must be written as standalone elements that perform a task while hiding its complexity. Architects should consider using the facade pattern, as it tends to encapsulate each member of a related task or class within a common interface so that client code may use those tasks interchangeably. Since a task is usually coded as one or a few isolated methods, encapsulation emphasizes reuse of methods that perform a single task. Reusing a single task is easier than reusing objects containing code and data, which may perform multiple tasks.
3.2.5 Service Lifecycle Stage Recommended Process
This phase begins as soon as the project manager or business analyst hands over the requirements to the technical team. The team then begins composite application design, typically by following these steps::
1. Architect downloads requirements from SCM/SOA repository, reviews them, and submits them to business analyst for further clarifications, if required
2. Architect selects tools to model and design the application
3. Architect identifies services and may search the SOA repository to identify potential reuse
4. Architect defines services, implementations, bindings, and dependencies
5. Once the design is complete, architect uploads all design artifacts to the SOA repository for approval
6. Architecture review board—consisting of enterprise architects, project architects, business analysts, and the project manager—reviews design to ensure architecture meets business requirements and is consistent across the enterprise.
The SOA repository should provide capability to generate service templates for each service category based on patterns defined by the enterprise architects.
3.2.6 Best Practices and Requirements
This phase begins as soon as the requirements for the composite applications are approved. This section describes the high-level best practices and requirements for this stage of the service lifecycle.
3.2.6.1 Service Orchestration (Modeling)
During the requirements and analysis stage of the services lifecycle, the team should capture all requirements in the form of business processes, including business rules and policies. This enables reuse, at both the business process and services level. Most BPM tools provide two separate tools: a BPM tool for the business analyst to capture requirements, and a service orchestration modeling tool for the architect. The service orchestration modeling tool typically includes the BPM tool and enables the architect to develop the service orchestration or flow model for each business service or activity. Most of these tools either generate the code or create metadata for executing the logic.
Best practices for service orchestration modeling include:
·
Leverage the BPM tool for service orchestration modeling
·
Adopt open-standards based tools for modeling (such as BPMN) and
orchestration (BPEL)
·
Have business analysts focus on business process modeling and architects
focus on service orchestration modeling
·
Have architects develop the services orchestration model for composite
applications even if the business analysts haven’t used a BPM tool to define
the business requirements
·
Upload all service orchestration models to the SOA repository.
3.2.6.2 Service Composition
Most leading software vendors have agreed to
a new standard called the service composition architecture (SCA). The SCA
standard defines services, service dependencies, service implementation,
services composition, and the deployment and runtime aspects of developing
composite applications. In addition, open-source projects are under way to
develop the Java and C++ runtime for SCA, such as the
The SCA standard defines the following:
·
How to auto-generate code based on the metadata via the mechanisms of
byte-code enhancement, dependency injection, and aspect-oriented programming (AOP)
·
Mechanism to extend the annotations (controls framework)
·
Annotations
that come out of the box for Java “plain old Java objects” (POJOs), business
process execution language (BPEL), Web services, and .NET or J2EE components
·
Configuration
parameters and deployment options for a service
·
List
of mechanisms to instrument and monitor a service.
Additional information about this proposed standard
is available at http://www.osoa.org
Figure 6: Service Composition Architecture
The above diagram demonstrates at a high level the service assembly model, in which multiple composites form an application. The composite consists of component services.
Figure 7: Service Composition Architecture
Multiple tools enable architects to compose services. Architects need the following capabilities:
·
Map each service to business activities. This is called service
orchestration, and it is the lowest level of the business process.
·
Compose services based on SCA. Architects define the service,
implementation, properties, interfaces, and bindings based on SCA. The
development team then leverages this service model for developing and modifying
the service.
·
Identify which business rules could be externalized and embedded
in code for better performance. This is only appropriate for rules that are
relatively static; rules must often change to
meet the needs of the business. A rules engine should interpret the rules
accurately based on the rule parameters.
·
Define
the business, management, and security policies associated with each of the
services
·
Identify
and define measurement matrixes for enabling business groups to review their
KPIs.
3.2.6.3 SOA Repository
The SOA repository is the system of record for all enterprise metadata, service definitions, and dependencies. All metadata generated by the tools used by the architect/designer is uploaded to the SOA repository. It provides information required by the consumer as well as additional details required by IT operations for managing the service. The repository defines not only what metrics to capture while monitoring a service from a support perspective but also provides for technical services that are provided by vendors. These technical services can provide dashboards that trigger events such as service alerts for business users.
Teams can also use the SOA repository for service governance, to support the process of submitting designed artifacts to appropriate reviewers for approval. Only after all approvals have taken place does the project manager assign tasks to developers and IT operations.
While there are currently no standards for repositories, several vendors
have repositories with capabilities for managing SOA metadata. While there are
several ‘hub’ repositories that are available for complete enterprise metadata
management, some vendors concentrate solely on SOA repositories that store a
subset of metadata, such as SCA models, BPEL, XPDL, JPD, and WSRP.
Following are the best practices for the SOA repository:
·
Search the SOA repository for potential reuse, including business
processes, policies, and services
·
Review the
·
Upload all the architecture framework documents, enterprise and
application models, and standards to the SOA repository
·
Define
the SOA repository workflow to enforce both design time and runtime governance
across the enterprise
·
Leverage
the service registry (UDDI) for integrating the SOA repository with other
repositories within the enterprise.
3.2.6.4 Service Registry
The service registry is based on UDDI and the system of record for all
deployed services. It contains metadata including service definitions, service
dependencies, and service interfaces. Service registries are now also being
extended to act as repositories, although they do not store the assets
themselves and are focused more on runtime metadata, a subset of metadata from
an SOA repository.
The best practices for the service registry are to search it for
potential reuse of services, and review the
3.2.6.5 Information Modeling
There are different types of modeling associated with information modeling
·
Reference data modeling
·
Master data management (such as CDI and PIM)
·
Shared
data services
·
Use
of domain standards where applicable (HR-XML, XBRL, ACORD, MDDL, and RIXML for
standards-based service payloads).
IT organizations rarely model
reference data, the common data such as country names, state names, and state
codes. However, partial standardization of reference data may be required to
provide a consistent user experience across the enterprise.
Following are some of the best practices for information modeling
·
Identify
all systems, data flow, and attributes between systems, business owners, and system
of records, then make it mandatory for every project team to update this model
·
Identify the data flow while capturing the business requirements
·
Identify shared data services and master data entities while reviewing
the application design
·
Develop the ERD for each custom application
·
Update
the ERD whenever a packaged or custom application is modified.
Refer to SOA Practitioners
Guide Part 2, SOA Reference Architecture
for information on master data management and shared data services.
3.2.6.6 Application Modeling
Most teams use modeling tools based on UML, as well as tools that enable architects to model sequence diagrams, activity diagrams, data flows, system flows, and network diagrams.
Packaged application vendors provide the capability to design and model their products and would recommend that IT organizations adopt the documented best practices associated with those applications.
3.3 Service Development
3.3.1 Actors
·
Project manager
·
Architects
·
Development teams
·
Release management
·
IT operations
3.3.2 Tools Used
·
IDE (for example, Visual Studio, Eclipse, JBuilder, JDeveloper, and BEA
Workshop)
·
Packaged application development tools
·
Regression and performance testing tools
·
Build tools (for example, Maven, Cruise Control, ANT, and shell scripts)
·
Source control management systems
3.3.3 Artifacts (Deliverables)
·
Source code
·
Product specific metadata for configuration as well as service execution
·
Java documents
·
Release
notes
3.3.3.1 Artifact Description
The artifacts produced during this stage include service definition, configuration, contract, and application configuration, as well as management, security and business policies at the service, application, department, and enterprise level. The application configuration also includes implementation configuration.
3.3.4 Service Lifecycle Stage Key Considerations
Tasks for this stage of service lifecycle include:
·
Define criteria for when to outsource development of a service
·
Perform technology review process prior to using a new technology within
IT
·
Assess skills required for the entire lifecycle of the service prior to
development of service
·
Map each service back to the business requirement
·
Evaluate existing services to eliminate duplicate development.
3.3.5 Service Lifecycle stage recommended process
Developers can start developing services as soon as project managers or architects provide them with the design documents. These could be office documents or models based on enterprise architecture standards.
Developers can also start developing or modifying services as soon as business or IT operations opens a change request(CR). In this case the architect may not be involved. The application support technical lead or developer will review the change request and make the changes. Depending on the level of change and the IT PMO process, governance may be triggered when the developer uploads the metadata change to the SOA repository.
Service creation typically follows this process:
1. The application design or the change request is approved for development.
2. In case of new development, the designer may already have created service templates and assigned them to the developer. The developer downloads the service templates and completes them.
3. In case of new development where no templates exist, the developer either uses a development tool to create the service or searches for a similar service in the SOA repository and copies it over as a template.
4. In case of a change request, the developer downloads the code and modifies it.
5. In all cases, the developer also downloads the requirements and design artifacts for review and may modify them after clarifications from architects, project managers, or business users. The service governance process is triggered whenever a developer modifies the requirements or the design artifacts.
6. If the architect has wired services based on SCA, the developer could leverage an SCA-based tool to double click on the component to confirm that the service is created.
7. If the service being created is to be consumed by services being developed by the other teams, the developer should define the service and develop and configure the service simulation. The service producer does this by defining responses to sample requests and publishing them for consumption. This enables consuming services to test out the contracts prior to the service actually being developed.
8. If the service being created is consuming a service being developed by the other teams, the developer can leverage the service simulations produced by the other team.
9. The developer goes through multiple interactions to develop and test the services. As the regression test is generally end-to-end, the developer can either use the simulated testing environment for unit-level testing or move the service through the various testing stages.
10. The developer periodically synchronizes the metadata with the SOA repository. The SOA repository validates all the metadata before accepting it and also triggers the service governance process, if required.
11. The developer generates documentation, such as Java documents and release notes, that are synchronized with the SOA repository.
This describes the traditional services creation and maintenance process. Most software vendors now also provide business users the ability to create composite applications using a portal. Business users can create composite applications by loosely coupling various user interactions and interactions processes, and dynamically creating forms based on service definitions. The business user can perform most of these tasks directly in production. Tools provide the capability to develop, test, and deploy the service, and synchronize the metadata that drives these composite applications to the SOA repository.
3.3.6 Best Practices and Requirements
These checklists cover what an SOA team should be looking for in development and testing tools, and how it should leverage the SOA repository.
3.3.6.1 Development tools
·
Standards-based
·
Ability to import/export metadata based on standards
·
Backward compatibility