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 Author