By 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.
