DFSS as an Enabler of Service-Oriented Architecture

	Bookmark This Page Email This Page Format for Printing Cite This Article Submit an Article Read More Articles
	Related Tools & Articles Improving the Value of the IT Service Delivery Process Ten Key Technologies for Lean Process Improvement DFSS Technology Tips For Successful Technology Implementation
	Discussion Forum "We are considering DFSS as a new product development process. Already we have a new product development process...so I need something to persuade myself and the others. Can we replace current...process....Or shall we merge DFSS and current process?" Contribute to this Discussion

B

Download Products Lessons in Six Sigma ebook Electric Load Forecasting Project Example Strategy Deployment Templates

y Robert Cardone and Russell Danziger

Finding ways to automate and improve business processes is a major focus for today's organizations. At the heart of every business is a complicated web of human and automated processes. For the business to be as effective as possible, these processes must be as efficient as possible. Service-oriented architecture (SOA) is a concept whose time has come. The promise of SOA is that it can transform the information technology assets of a business, making it possible to do more with less. However, if care is not taken when implementing SOA, there is significant risk that the promise will not be realized.

By incorporating the Design for Six Sigma methodology with SOA initiatives, the promise of SOA can be achieved by assuring services are optimally designed from the start. This approach also will result in improved success rates, shorter delivery times and significant savings relative to traditional development approaches.

Overview of Service-oriented Architecture

Service-oriented architecture is a systematic approach to how IT functionality can be planned, conceptualized, designed and implemented as modular business services to achieve business results. The SOA vision includes clearly defined business, IT and architecture goals coupled with a governance model to help enforce standards and technical requirements over time. The SOA target state is achieved over time rather than as a big bang.

At the heart of an SOA are services. Services in an SOA are modules of business or application functionality with exposed interfaces that are invoked by messages from service consumers. The SOA design model assures reusability, interoperability and integration of services across all business processes and technology platforms.

Because services are the primary asset of an SOA, they require primary focus for the designer of an SOA. The critical nature of well-designed services necessitates a methodology for the design and management of processes used to deliver and maintain the services to customers. One must adopt a total approach to the design and development of services. The idea behind this concept is that service design and development does not merely consist of technology specific engineering functions.

Customers and business process owners do not care about IT engineering methods used to deliver a service. They are only concerned with the ability of the service to consistently satisfy customers' performance needs. The ability of a service to consistently and reliably perform is related to the technology used in its design. However, an approach that focuses primarily on the technology used in its design, without clearly understanding the customer requirements for the service and the context within which it will be used, cannot be expected to deliver services that meet or exceed customer expectations. Therefore, a design methodology is needed that combines customer focus and technology independent methods with the IT engineering design processes. The Design for Six Sigma (DFSS) methodology delivers a total design and is an enabler of SOA.

Pitfalls of Typical Software Design

Software development initiatives are prone to design vulnerabilities that result from flawed or incomplete requirements. In addition, operational vulnerabilities may be introduced due to lack of process robustness. These design and operational vulnerabilities result from lack of a true design methodology, a rush to a favored solution, the pressure of a schedule and budget limitations. Traditional software quality methods such as system testing are after-the-fact practices that result in numerous cycles of design-test-fix and retest. These added-on quality methods result in suboptimal designs, increased development costs, longer development cycles and designs that are difficult to change or enhance.

Designing Services Optimally the First Time

The principle objective of DFSS is to design services optimally the first time. Services that are designed from the start to operate at a Six Sigma level are not subject to design vulnerabilities and operational vulnerabilities. These robust designs function as intended under all operating conditions throughout its intended life cycle. DFSS using the DIDVO roadmap has five phases and nine steps:

• Define – Project characterization (Step 1)
• Innovate – Conceptual design (2)
• Design – Preliminary design (3), detail design (4) and design realization (5)
• Validate – Prototype/pilot (6) and pre-launch (7)
• Operate – Launch (8) and manage the service maintaining a continuous improvement mindset (9)

The DIDVO methodology and tools can be used to enhance an existing SOA or create a new SOA. The following table highlights how the DIDVO roadmap relates to SOA development tasks step by step. After each step a tollgate is scheduled so the project team can report its accomplishments and thus make sure each step is complete.

DIDVO Roadmap Charts SOA Development Tasks
SOA Tasks	Method/Tools
Step 1. Project Characterization:
Define project scope	SIPOC
Identify process owners and stakeholders	Project charter
Identify project objectives and goals	Project charter
Initiate project plan	Project plan
Identify project risks	Risk matrix
Align project to CFOs	Business flowdown
Understand VOC for services	Interviews, focus groups and surveys
Quantify measurable customer requirements (CTQs)	Prioritization
Step 2. Conceptual Design
Identify service functions to deliver CTQs	Function decomposition
Prioritize service functions	QFD matrix
Generate innovative solutions	Benchmarking, brainstorming and TRIZ
Select design concept	Pugh matrix
Step 3. Preliminary Design
Create high-level design	SIPOC, high-level process diagrams
Address design risks	DFMEA
Mistake proof design	Poke yoke
Step 4. Detailed Design
Create detailed design and measures	Detailed process diagram
Develop technical requirements	BRS
Identify infrastructure requirements	Infrastructure specifications
Evaluate detailed design capability, robustness and risks	Probabilistic design
Plan controls and governance tools	Design scorecard
Stpe 5. Design Realization
Build and test unit	Project plan, test scripts
Shape change management actions	Change plot/plans
Confirm cost-benefit analysis	Cost-benefit analysis
Step 6. Prototype/Pilot
Generate test requirements/environment	BRS and SRS
Test prototype or run pilot	Test plans
Analyze prototype or pilot results	Accept prototype or pilot results
Step 7. Prelaunch
Update design as needed from prototype test/pilot results
Confirm that design meets requirements	BRS and SRS
Plan for full implementation	Change plot/plans, implementation plan
Step 8. Launch
Implement new service(s)	Launch plan
Hand over to process owner	Control management package
Stabilize design elements	Control charts
Step 9. Management
Monitor system with established controls	Scorecard
Demonstrate process performance	Process capability analysis
Maintain continuous improvement mindset	Periodic audits

About the Authors: Robert Cardone is an enterprise Master Black Belt with Merrill Lynch Six Sigma Central Deployment Office. He can be reached at Robert_Cardone@ML.com. Russell Danziger is the deployment manager for the Six Sigma Central Deployment Office. He can be reached at Russell_Danziger@ML.com.