Let’s start from the beginning. It seems that the derivative of WS-CDL is Web Services Descriptive Language. Web Services Descriptive Language is defined as a XML formatted language used to convey network services as a collection of endpoints or points. It is also seen as a standard way to represent software parts. This occurs by abstractly binding messages and operations to a concrete protocol and then defining an endpoint. This binding must not specify address info and only use one protocol. WSDL is extensible so that messages and operations can be communicated regardless to the format and protocols used. There are several functions of WSDL but the function that allows the success of the previously mentioned process is binding. WSDL defines collections of network endpoints, or ports as services. Separation of abstractly defined endpoints from their concrete network deployment or data format also occurs via bindings. Abstract definitions enable abstract descriptions of the data being exchanged (messages), and abstract collections of operations called port types. A port is defined by associating a network address with a reusable binding, and a collection of ports define a service. The following are elements in the define WSDL network services:

• Types– a container for data type definitions using some type system (such as XSD).
• Message– an abstract, typed definition of the data being communicated.
• Operation– an abstract description of an action supported by the service.
• Port Type–an abstract set of operations supported by one or more endpoints.
• Binding– a concrete protocol and data format specification for a particular port type.
• Port– a single endpoint defined as a combination of a binding and a network address.
• Service– a collection of related endpoints.

There are different four different port types or ways of transmission:

• One-way. The endpoint receives a message.
• Request-response. The endpoint receives a message, and sends a correlated message.
• Solicit-response. The endpoint sends a message, and receives a correlated message.
• Notification. The endpoint sends a message.

Please see example below:

(code sample intentionally omitted)

Now on to WS-CDL, is utilized by languages such as SOAP, HTTP/S, and MIME as a universal way to view the work of all parties involved. WS-CDL is a XML-based language that describes peer-to-peer collaborations of participants by defining their common behavior. The purposes of these messages are to send information and exchange results in order to accomplish a common business goal. Simply put, WS-CDL “choreographs” the sending and receiving of messages.

WS-CDL uses the following key elements as message specifications:

• role: specifies the operations implemented by a given participant that will perform this role in the choreography. What is interesting is that a WSDL specification is not mandatory here. So WS-CDL is not a choreography of WSDLs but merely a choreography of operations that can be specified in some WSDL once the choreography is implemented.
• relationship: ultimately every choreography can be divided into a series of binaries relationships. A relationship expresses just that, the commitments of each participant to another.
• participant: a participant implements one or more role in the choreography (e.g. a distributor can be both a buyer and a seller in a choreography, using the same relationship definition with respect to its manufacturer or customers).

As with WSDL you have the ability to globally send and receive information to all users. WS-CDL provides “reactive” rules that are used by each party to view the state of the choreography and decide the order of the message exchange. The following are used to foster this type of environment in WS-CDL:

• Reusability-The ability to use the same Choreography definition by different parties operating in different contexts (industry, business, etc.) with different software (e.g. application software)
• Cooperation- Choreographs the sequence of exchanging messages between two (or more) independent parties or processes by describes how they should cooperate
• Multi-Party Collaboration- As stated earlier. Multiple users can utilize at it at the same time
• Semantics- Contains easily readable documentation and semantics for all participants to understand
• Composition- Can reuse existing choreographies for the future
• Modularity- Similar to above except the reusable portions can be modules and later combined into a new document.
• Information Driven Collaboration- Progress of a project can be displayed/updated through the recording of exchanged information and changes to information that cause ordering constraints to be fulfilled and hinders or aids progress made
• Information Alignment- Allow the parties that take part in Choreographies to communicate and synchronize their information
• Exception Handling- Exceptions or unusual conditions that occur while the Choreography can be defined and are handled
• Transactionality- Participants can work in a “transactional” way with the ability to coordinate the outcome of the long-lived collaborations, which include multiple participants, each with their own, non-observable business rules and goals
• Specification Composition- Can work alongside and complement other specifications such as the WS-Reliability [WSRM], WS-Composite Application Framework (WS-CAF) [WSCAF], WS-Security [WSS], Business Process Execution Language for WS (WS-BPEL) [WSBPEL], etc.

An example of the use of WS-CDL is shown below:

(code sample intentionally omitted)

Please see the diagram below for an example of the flow and impact choreography can have:

WS-CDL seems to be a great way for developers to collaborate globally. Multiple users can utilize WS-CDL regardless to the language or transmission protocol they employ. Users can freely collaborate and modify without a “czar” controlling the content with the modularity of object orientation at their whim.

By: Hasana

References

http://xml.coverpages.org/ni2004-04-27-a.html

http://www.ibm.com/developerworks/xml/library/ws-choreography/index.html

http://soa.sys-con.com/node/175396

http://www.ebpml.org/ws_-_cdl.htm

Definition

A Web service is a software system that facilitates “application-to-application” interactions, most commonly over the Internet. This is accomplished through independent, open standards such as the eXtensible Markup Language (XML)-based Simple Object Access Protocol (SOAP) and Web Services Description Language (WSDL), and Universal Description, Discovery and Integration (UDDI). In a nutshell: XML is used to tag the data, SOAP is used to transfer the data, and WSDL describes the available services listed by UDDI.

Web services allow the remote execution of hosted services in distributed client-server architectures through different Web Application Programming Interfaces (APIs), which are accessible from a common user interface (the interface is not provided by the services.) The idea is not new, but its application over the Internet (specifically, over the HTTP protocol) is fairly recent. The previous, much more complex application of this principal was accomplished through Java RMI, DCOM, CORBA, and RPC. Web services can be divided into two main architectures: “Big” Web Services and RESTful Web Services. Another important design issue to consider is security.

“Big” Web Services (WS-*)

“Big” Web Services (or WS-*) are generally perceived as more complex yet more flexible (extendable) by utilizing the SOAP messaging format and the WSDL interface definition language. WSDL, while not required by a SOAP endpoint, is a prerequisite for automatically generating client-side code generation in many Java and .NET SOAP frameworks. Some organizations (such as the Web Services Interoperability Organization) mandate both WSDL and SOAP in their definition of Web services. An advantage of using “Big” Web Services is the protocol transparency and independence provided by SOAP. “Big” Web Services also addresses the Quality of Service (QoS) requirements commonly found in enterprise computing.

REST

The second grouping of Web services utilizes REpresentational State Transfer (REST, or RESTful), which are more easily integrated with HTTP than SOAP because they do not require XML messaging or WSDL definitions. REST is defined as a collection of four network architecture principles which determine how resources are defined and addressed:

Resource identification through URI. A RESTful Web service that
exposes a set of resources which identify the targets of the interaction
with its clients. Resources are identified by URIs, which
provide a global addressing space for resource and service discovery.

Uniform application interface. Resources are manipulated using a fixed set
of four create, read, update, and delete operations: PUT, GET, POST,
and DELETE. PUT creates a new resource, which can be then removed
using DELETE. GET retrieves the current state of a resource. POST updates the resource to a new state.

Self-descriptive messages. Resources are disjoined from their
representation so that their content can be accessed in a variety of
formats (e.g., HTML, XML, plain text, PDF, JPEG, etc.). Metadata
about the resource is available and can be used to control
caching, detect transmission errors, negotiate the appropriate
representation format, and perform authentication or access control.

Stateful interactions through hyperlinks. Every interaction with
a resource is stateless, i.e., request messages are self-contained.
Stateful interactions are based on the concept of explicit state transfer.
Several techniques exist to exchange state, e.g., URI rewriting,
cookies, and hidden form fields. State can also be embedded in response
messages to point to valid future states of the interaction.

Security

A final consideration affecting any Web service architecture is security. The most commonly used security protocol in the Internet is Secure Sockets Layer (SSL). However, SSL is too limited to fully address Web services, so several XML-based solutions have been developed such as:

• XML digital signature
• XML Encryption
• XKMS (XML Key Management Specification)
• SAML (Secure Assertion Markup Language)
• WS-Security (Web Services Security)
• ebXML Message Service

Conclusion

The development and maturation of Web services has not only changed the way businesses operate, it has changed the way people live. With the proliferation of online shopping, telecommuting, and the emerging adoption of “mash ups” and Web 2.0 applications, Web services have created whole virtual communities. eBay founder Pierre Omidyar, for example, attributes its huge success to its active user community, not online auctions.

Web services are the next step in information services evolution in much the same way object-oriented programming revolutionized application development. The challenge for businesses today is not whether to incorporate Web services or not, but how.

By: Chris

References

http://www.webopedia.com/TERM/W/Web_services.html

http://www.webopedia.com/DidYouKnow/Computer_Science/2005/web_services.asp

http://www.w3.org/TR/ws-arch/

http://en.wikipedia.org/wiki/Web_service

http://www.paragoncorporation.com/ArticleDetail.aspx?ArticleID=13

http://www2008.org/papers/pdf/p805-pautassoA.pdf

Web Services in the business world, in the most simplistic fashion, provides a mechanism of communication between two remote systems, connected through the network of the Web Services. For example, in case of a merger or an acquisition, companies don’t have to invest large sums of money developing software to bring the systems of the different companies together. By extending the business applications as Web Services, the information systems of different companies can be linked. These business systems then can be accessed by using simple SOAP messages over the normal HTTP Web protocol. For example, a manufacturing company requires some raw materials to be supplied whenever the material in stock reaches the threshold levels. These levels can be constantly monitored by the business system of a trusted supplier, and promptly replenished, without having to wait for a supervisor to notice it and generate a work order.

XML (eXtensible Markup Language): XML is a general-purpose specification for creating custom markup languages. It is classified as an extensible language, because it allows the user to define the mark-up elements. XML’s purpose is to aid information systems in sharing structured data, especially via the Internet, to encode documents and to serialize data.XML was designed to transport and store data.

Web Service Orchestration The standard set of Web Service technologies (XML, SOAP, and WSDL) provides the means to describe locate and invoke a Web Service as an entity in its own right. Although a Web Service may expose many methods, each Web Service Description Language (WSDL) file describes fairly atomic, low-level functions. What the basic technologies do not give us is the rich behavioral detail that describes the role the service plays as part of a larger, more complex collaboration. When these collaborations are collections of activities designed to accomplish a given business objective, they are known as a business process. A business process may extend across one or more organizations. The description of the sequence of activities that make up a business process is called an orchestration.

BPEL for Web services (BPELWS or BPEL4WS) is an XML-based language designed to enable task-sharing for a distributed computing or grid computing environment – even across multiple organizations – using a combination of Web services. BPEL provides a very expressive grammar for defining real-world business processes. BPEL grew out of the need to model and execute complex interactions between Web Services.

BPEL can be used to describe a business process that will take place across the Web in such a way that any cooperating entity can perform one or more steps in the process the same way. In a supply chain process, for example, a BPEL program might describe a business protocol that formalizes what pieces of information a product order consists of, and what exceptions may have to be handled. The BPEL program would not, however, specify how a given Web service should process a given order internally.

A High level overview Case Study: An auto body shop (truck parts ordering process)

The problem: An auto body shop with a technology headache. This body shop often needs to order parts from suppliers. They work with many suppliers of vehicle parts, and for the longest time, all of their orders for automobile parts were done by negotiating over the phone with many vendors. The industry recently moved to a Web Service environment, and all purchasing can now be done electronically between businesses. They need a solution that meets today’s requirements and business processes, but more importantly, they need a solution that is flexible enough to accommodate changing business processes.
The process: The internal flow of the simple process is as follows:

1. You must get information about the purchaser before you make the request.
2. You request a price quote from vendors (Ken’s Truck Parts and Computer Mom’s Trucks) for a certain part.
3. You purchase the part from the vendor with the lowest price.

High-Level Design Decisions: We know from the problem statement that there are complex and different processes for ordering different types of vehicle parts. Look at those processes involved as composite services that could be used together to build the main system process for ordering vehicle parts. Based on the type of vehicle, The Vehicle Parts Ordering Process simply propagates the request to the lower-level processes, and returns the purchase response to its consumer. Because BPEL designs can get pretty large, and large diagrams are often difficult to see when shrunk down, we make the truck parts ordering process pretty simple for the purpose of this example. In this case, there are only two competing vendors, ‘‘Ken’s Truck Parts’’ and ‘‘Computer Mom’s Trucks.’’ Looking externally from the service consumer’s perspective, we want to create a composite service that accepts a purchase request for a truck part and returns a response that shows the status of the transaction (whether the part was ordered, and if so, the specifics of the order).

BPEL Toolkits: In practice, constructing processes is done visually with various design tools, and many are free, including the BPEL Visual Designer for Eclipse and the BPEL plug-in for NetBeans. There are also commercial BPEL designer tools from companies such as Oracle, IBM, Active Endpoints, and BEA. These tools allow us to create visual flows and generate BPEL that can be executed on an orchestration server. Most tools have their own look and feel, and are ‘‘BPMN-like’’ in their visual notations, but they all export to BPEL. Once a design tool exports the model to BPEL, an orchestration engine is able to execute the process

Figure 1: BPEL Process for Truck part ordering

By: Kripal

References:

http://searchsoa.techtarget.com

http://www.developer.com

Applied SOA Service-Oriented architecture and Design Strategies
Mike Rosen, Boris Lublinsky, Kevin T. Smith, Marc J. Balcer

BPEL Samples: http://www.activebpel.org/samples/samples-2/BPEL_Samples/doc/index.html

Hello World BPEL development with net beans: http://www.netbeans.org/kb/61/soa/helloworldca.html

Hello World With eclipse: http://www.eclipse.org/tptp/platform/documents/design/choreography_html/tutorials/wsbpel_tut.html

Background
Like AJAX (Asynchronous Javascript and XML), SOA is not a new technology, it is merely an enhancement of an existing concept that was developed almost 30 years ago. Some of the earlier versions of SOA include DCOM and CORBA. DCOM is Microsoft’s Distributed Common Object Model and was introduced in 1996. CORBA is Object Management Group’s Common Object Requesting Broker Architecture and version 1.0 was introduced in 1991.

Since the days of DCOM and CORBA, SOA has been sort of resuscitated by the emergence of web services and XML. These technologies allow SOA to break out of the proprietary systems required by the implementations of DCOM and CORBA. A web service written in one language or technology can be accessed and its results consumed by a system written in a completely different language or technology.

Service-based architectures are much more granular than object-based architectures. Where object-based architectures allow access to functionality that is tightly coupled based on business procedures, SOA allows access to the individual pieces that make up those procedures. For instance, consider a banking implementation where a customer wants to transfer money from one account to another. In a typical object-based architecture this might be implemented as one method or procedure. The first step debits the amount from account A, the second step credits the amount to account B. This is done as a single unit of work or a single transaction and the steps cannot be accessed individually. An SOA implementation of the same process might expose the two steps separately. So, instead of accessing a single function to transfer the money, two different steps would be accessed sequentially.

Strengths/Benefits
Let’s examine some of the strengths of SOA. Because SOAs are so granular they are also very scalable. For example, if one specific service is used significantly more than the other services, that service can be separated and placed in a different physical location. This allows some performance problems to be solved simply by adding more hardware and rearranging the services.

Additionally, the granularity of SOAs promotes code reuse at the lowest level possible. Reuse of an object requires much more specific circumstances than reuse of a service because the service typically performs only one action while the object’s methods may perform many actions as an atomic unit. Also, code from one project can be reused in another project much more easily.

Because the interfaces to SOAs are usually implemented as web services, SOAs are typically platform-independent. A web service written in Java can be accessed by a consumer written in Microsoft’s .NET languages and vice versa.

Weaknesses/Criticisms/Challenges
As with anything else, there are some drawbacks to using SOAs. One drawback or criticism of SOAs is that the use of XML adds costs to the system. In an SOA based on web services the data is encapsulated in XML. Wrapping data in XML on one end and unwrapping it on the other end requires extra processor cycles that would possibly not be necessary using other technologies.

Another drawback or challenge is keeping track of all the services available. Registration, discovery, binding, and invocation are all potential challenges in an SOA environment. Because of this, companies implementing an SOA must be very careful and diligent in publishing their services and making sure that directories of services are maintained so there is no confusion about what services are available or where they reside.

Examples of SOA

• ebay – Abstracting enterprise information from underlying systems
• IBM – Reducing application inventories
• Wachovia Bank – Changing the culture, bringing IT closer to the business, and improving business productivity
• Harley Davidson – Breaking up inflexible systems that were unresponsive to the business
• Amazon – Handling growing transaction loads as simply as possible
• Citigroup – Enabling the “separation of powers” between corporate, divisions, and departments
• OnStar – Moving business rules out of applications

Conclusion
While there are some drawbacks to using SOAs, when implemented correctly they can be very effective. The examples show that a lot of companies with high transaction volumes are using them and are happy with the results. The Amazon example in particular shows that mainstream, high-transaction applications can be successfully implemented in the architecture. However, some people are already claiming that SOA is already a dying or even dead architecture, but that it’s concepts will live on in newer technologies such as mashups, business process management (BPM), software as a service (SaaS), and cloud computing.

By: Mike

References
What is Service-Oriented Architecture? Dr. Hao He, Sep 2003, http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html
Common Object Request Broker Architecture, Wikipedia, http://en.wikipedia.org/wiki/CORBA
Component Object Model, Wikipedia, http://en.wikipedia.org/wiki/Component_Object_Model
Service Oriented Architecture, Wikipedia, http://en.wikipedia.org/wiki/Service-oriented_architecture
Service-oriented architecture in and beyond the credit crunch, Computer Weekly, http://www.computerweekly.com/Articles/2009/03/17/235299/service-oriented-architecture-in-and-beyond-the-credit.htm
Ten companies where SOA made a difference in 2006, ZDNet, http://blogs.zdnet.com/service-oriented/?p=781

Stated Benefits
The Object Modeling Group touts the following assurances and benefits in their executive summary of MDA which can be found at http://www.omg.org/mda/executive_overview.htm.

Assurances

• Portability, increasing application re-use and reducing the cost and complexity of application development and management, now and into the future.
• Cross-platform Interoperability, using rigorous methods to guarantee that standards based on multiple implementation technologies all implement identical business functions.
• Platform Independence, greatly reducing the time, cost and complexity associated with re-targeting applications for different platforms-including those yet to be introduced.
• Domain Specificity, through Domain-specific models that enable rapid implementation of new, industry-specific applications over diverse platforms.
• Productivity, by allowing developers, designers and system administrators to use languages and concepts they are comfortable with, while allowing seamless communication and integration across the teams.

Benefits

• Reduced cost throughout the application life-cycle
• Reduced development time for new applications
• Improved application quality
• Increased return on technology investments
• Rapid inclusion of emerging technology benefits into their existing systems

Explanation
Model Driven Architecture makes process modeling a central requirement in the software development process. This is better explained by first looking at how other software development processes use modeling:

First there is the code only process where the process model lives in the developer’s head and the business is at the mercy of the developer to accurately understand the business process and translate it into software correctly.

A second method is the process where requirements and/or models are created by Subject Matter Experts or Business Analysts and handed to the developer. In this scenario the business rules are entrusted to someone whose job it is to understand the business thereby leaving the developer responsible only for understanding the model and translating it into software. After this is completed successfully the original documentation is archived but never really maintained.

A third method is identical to the second previously mentioned method with the exception that as the software is updated so is the documentation and the two remain reflections of one another.
All of the methods mentioned so far are considered model assisted software development. Model Driven Architecture differs from these because the code that implements the software is generated directly from the models of the business process. Because the software is derived directly from the models, the software is considered “Model Driven”. Developers are left to do tweaking and integration.

Real Word Example
Microsoft is venturing into the MDA world with the forthcoming release of an entirely new development platform which they have Codenamed Oslo. Oslo will be comprised

Oslo Repository
A shared database for linking together all of the various model artifacts across the Microsoft platform, leveraged across various Microsoft products. The repository is a SQL Server database for managing domain models and includes a library of pre-built models. It stores models as SQL Server schema objects and model instance data as rows in the tables that implement the schema.

Oslo modeling language (codenamed “M”)
A new modeling language for authoring domains textually, providing a shared meta-model that enables developers to easily import/export models from the repository in an approachable, textual manner.

Oslo visual modeling tool (codenamed “Quadrant”)
A modeling and composition tool for authoring domains visually, such as designing business processes with well-understood, flowchart-like graphics.

Conclusion
Some tout MDA as the next evolution in software development and the fact that Microsoft is getting behind the methodology is certainly evidence that it has potential. The methodology and its adoption by the larger software community is something that I plan to keep my eye on but at this point, while intrigued, I’m not yet ready to claim that MDA is a silver bullet to all the problems we deal with in software development. I do think it has the potential to be a useful new tool. Time will tell if it lives up to that potential.

By: Eric

References

http://en.wikipedia.org/wiki/Common_Warehouse_Metamodel

http://en.wikipedia.org/wiki/Software_Process_Engineering_Metamodel

http://en.wikipedia.org/wiki/Meta-Object_Facility

http://en.wikipedia.org/wiki/XMI

http://en.wikipedia.org/wiki/Enterprise_Distributed_Object_Computing

http://www.omg.org/mda/

http://www.sdtimes.com/content/article.aspx?ArticleID=26807

http://msdn.microsoft.com/en-us/library/dd129514.aspx

http://msdn.microsoft.com/en-us/library/dd129873.aspx

Architecture Development Method (ADM)
The ADM is the core of the framework integrates elements of TOGAF to meet the business and IT needs of an organization. The ADM is iterative throughout the entire process and for each iteration, a new decision must be taken. These decisions must cover items such as the level of detail to be defined, the amount of time to complete, and the architectural assets to be leveraged in the organization. As a generic method, the ADM is intended to be used by enterprises in different sectors and industry types. The basic structure of the ADM cycle is shown in the first picture (page 2) and throughout the cycle, results should be validated against original expectations. In the second picture (page 3), you can see that each phase of the cycle can be broken down into further steps. Although the ADM is a generic method for architecture development, it will often be necessary to modify the ADM to suit specific needs. The main guideline is to focus on what creates value to the enterprise, and to select scope and time horizons accordingly.

Enterprise Continuum
The Enterprise Continuum is an aid to communication and understanding within the enterprise organization and between the enterprise and vendor organizations. The Enterprise Continuum also aids in organizing re-usable architecture and organization assets from previous projects. It can be considered a virtual repository of artifacts that exist within the organization or in the general IT industry. TOGAF’s Enterprise Continuum specifies a progression for developing architectures and solutions using architecture building blocks and solution building blocks in a continuous fashion. The Enterprise Continuum is composed of the Architecture and Solution Continuums. The Architecture Continuum provides guidance, direction, and support to use the Solutions Continuum to build the technology architecture. The Solutions Continuum defines the solutions that deliver the architecture, and include commercial-off-the-shelf (COTS) solutions and an organization’s own in-place solutions.

Resource Base
The TOGAF Resource Base is a set of tools, guidelines, templates, background information, and other items to aid in the architecture process. The Resource Base also mentions the use of TOGAF in conjunction with frameworks. Since TOGAF is generic, it does not recommend a specific set of deliverables. Instead, it talks about the types of deliverables to be produced and the methods by which they should be developed. The framework can be used on its own with generic deliverables or those deliverables can be replaced with more specific ones from another framework that may be relevant to the organization’s needs.

Conclusion
TOGAF offers a proven method that is the result of years of research and development by the world’s leading enterprise architects. It also guides architects in using a standard vocabulary for business, information systems, and technology modeling. This shared terminology means that everyone in an organization can read and understand the information. TOGAF offers companies a way to align their technology to their business goals and reap the benefits of corporate alertness, governmental compliance, and improved cost management.

By: Mondra

References

Chase, Nicholas. “Introducing The Open Group Architecture Framework (TOGAF), Part 1: Understand TOGAF and IT architecture in today’s world”. www.ibm.com/developerworks/architecture/library/ar-togaf1/index.html?S_TACT=105AGX20&S_CMP=EDU. 14 Feb 2006.

Harrison, David and Varveris, Lou. “TOGAF: Establishing Itself As the Definitive Method for Building Enterprise Architectures in the Commercial World.” www.developer.com/design/article.php/3374171. 28 Jun 2004.

The Open Group Architecture Framework Version 8.1.1, Enterprise Edition. www.portal.mot.go.th/e_logistics/content%5Cpublic_document%5Ctogaf811e.pdf. Published by The Open Group. Apr 2007.

TOGAF Standard Courseware V9 Edition. www.togaf.info/togaf9/togafSlides9/TOGAF-V9-M2-TOGAF9-Components.pdf. Published by The Open Group. Jan 2009.

Diagram 1. http://www.opengroup.org/architecture/togaf8-doc/arch/Figures/adm.gif.

Diagram 2. http://www.opengroup.org/architecture/togaf8-doc/arch/Figures/adm_exp.gif.

JIT is commonly associated with the Toyota Production System (TPS) developed in the 1970’s. But, looking further back, JIT concepts are found in Henry Ford’s mass production system and its roots can be found in Eli Whitney’s development of interchangeable parts used to manufacturer U.S. Army muskets. More recently, “Lean Production”, popularized in James Womack’s 1990 book “The Machine that Changed the World”, has embraced JIT manufacturing techniques.

Eliminating inventory should result in perfect flow. Perfect flow is described as delivering the right parts to the right place at the right time. The right parts include raw materials, subassemblies and finished products. Perfect flow begins with pull from the customers. The customers dictate the amount of finished goods needed. The manufacturer’s goal is to produce as much product as its customers need as they need it.

JIT is best implemented when production rates are fixed or steady, lot sizes are small, and machine setup times are short. Like mass production, it works best for repetitive manufacturing processes. Small lot sizes and short setup times are what make JIT more agile than mass production techniques and allow for continuous process improvement.

Once reasonably accurate order projections are established, the manufacturing process can be optimized for internal JIT delivery and inventories for work-in-progress (WIP) reduced. When flow is optimized and WIP is minimized then JIT delivery can be required of suppliers.

Cooperation between buyers, manufacturer and suppliers is essential to successfully implement JIT. Suppliers must be dependable and capable of delivering quality parts and materials just-in-time. Suppliers may be forced to implement JIT in their own process so they don’t become the de facto warehouses of their customers. The result for the suppliers is either a higher cost of carrying inventory or of implementing JIT themselves. The supplier hopes a successful implementation will offset the cost of JIT. If the supplier chooses not to implement JIT then it will pass carrying costs back to the manufacturer.

Another cost associated with JIT is the cost to deliver small batches frequently. This cost is realized at either end of the supply chain. It is a direct cost when the manufacturer delivers to the customer and indirect when it is passed from the supplier. In return for assuming these costs, a manufacturer hopes to gain lower inventory and carrying costs, less rework, less scrap material and reduced floor space requirements.

Finding or developing reliable suppliers capable of consistently delivering quality parts, as needed, is a key to successfully implementing JIT. Suppliers must be confident there is a long term, strategic relationship with the manufacturer before they are likely to adopt JIT themselves. If the suppliers have not adopted JIT then the manufacturer has simply shifted a cost and can expect to see it shifted back in a different form. Worse, the supplier may never consistently attain the level of quality expected by the manufacturer. This could lead to delays or breaks in the supply chain and interrupt manufacturing flow.

JIT attempts to provide the cost benefits of mass production with the quality results of craft. It is best for repetitive processes where customer pull is steady. Once JIT is implemented internally, a manufacturer can push it externally. Suppliers who are required to deliver just-in-time face greater inventory carrying costs. The carrying costs can be mitigated by implementing JIT in their own processes or shifting the costs back to their customer. A tenuous relationship between manufacturer and supplier is a recipe for disaster.

By: Mitchell

Works Cited

“Just In Time, Toyota Production System & Lean Manufacturing Origins & History Lean Manufacturing.” Lean Manufacturing History. 11 Feb. 2009 .

“Lean Manufacturing and Just-in-Time Production: Encyclopedia of Management.” ENotes. 11 Feb. 2009 .

Sersland, Daniel R. “The just-in-time philosophy: a legacy of an obsession.” Business Resources, Advice and Forms for Large and Small Businesses. 22 June 1991. 11 Feb. 2009 .

Shahabuddin, Syed. “Is JIT really appropriate for American manufacturing?” Business Resources, Advice and Forms for Large and Small Businesses. 1 May 1992. 11 Feb. 2009 .

Songini, Marc L. “Just-in-Time Manufacturing.” Computerworld – News, Education & Headlines – Security, Storage & Networking – Information on Hardware, Software for Laptops & Desktops. 20 Nov. 2000. 11 Feb. 2009 .

Capability Maturity Model Integration (CMMI) is a process improvement approach that helps organizations increase the maturity of their processes to improve long-term business performance. It can be applied to a project, division or an entire organization. CMMI helps integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes. 1,2

History

In the 1970’s, technological improvements led to proliferation of computerized information systems and an increased demand for software developers and managers. As this demand was satisfied with less experienced professionals, software quality suffered and project failure became widespread.3

In 1979, Phil Crosby published the Quality Management Maturity Grid in his book Quality is Free. In 1984, the Carnegie-Mellon Software Engineering Institute (SEI) was established by the U.S. Department of Defense. Building on Crosby’s work, in 1989, Watts Humphrey’s Capability Maturity Model (CMM) was described in his book Managing the Software Process. SEI published version 1.0 of the CMM for Software (SW-CMM) in 1991. This was intended to be used as a tool for evaluating the ability of government contractors to perform contracted software development. 3,4

Subsequently, the Systems Engineering Capability Model and the Integrated Product Development Capability Maturity Model were released. Recognizing the problems of organizations using multiple CMM’s, the CMM Integration project was formed in 1997. Capability Maturity Model Integration (CMMI) version 1.02 was released in 2000, v1.1 in 2002 and v1.2 in 2006. 3,4

Current Models and Representations

Current models, known as constellations, for CMMI version 1.2 include CMMI for Services, CMMI for Acquisition, and CMMI for Development: 5

A model is a simplified representation of the world. The models have been developed to provide guidance during process development. CMMI models are neither processes nor process descriptions. The actual processes that are appropriate for an organization are dependent upon many factors including organizational structure and size. 5,6

There are two representations for CMMI, Continuous and Staged:

The Continuous Representation allows selection of the order of improvements that best meets the organization’s business objectives. It also provides an easy migration from EIA Interim Standard (EIA/IS) 731 to CMMI and an easy comparison to International Organization for Standardization and International Electrotechnical Commission (ISO/IEC) 15504.6

In the Continuous Representation, there are six capability levels which apply to an organization’s process-improvement level. The level applies to each individual process level within the organization. The levels are: 6

The Staged Representation provides a proven sequence of improvements beginning with basic management practices and progressing through a predefined path of successive levels known as a maturity levels. The maturity level applies to the organization as a whole. The levels are: 6

In both the Continuous and Staged Representation, higher level numbers represent greater levels of Capability or Maturity.6 The Standard CMMI Appraisal Method for Process Improvement (SCAMPI) is designed to provide benchmark quality ratings relative to CMMI. 7 There are three levels of formality for appraisals: Class A, B, and C. Class A is the most formal. A Class A appraisal, performed by an SEI-authorized Lead Appraiser, is required to achieve a rating for public record. 8

Benefits of CMMI

A number of organizations have reported on the results of their process improvement activities using CMMI. Several of these are available for review on the SEI Website.9 The following table contains data reported by 25 organizations as of December 15, 2005. The results are expressed as changes over time: 10

Conclusion

CMMI provides an approach for the improvement of processes within an organization with the goal of improving business performance of the organization. While initially focused on software development, the approach currently includes multiple models applicable to many different organizational activities. Many organizations have reported impressive process improvement results as they have applied CMMI methods and practices over time.

By: Ken

References

1 “Are you looking for Higher Quality and Productivity, Faster Delivery, Lower Costs and Better Morale?”, http://www.sei.cmu.edu/managing/, accessed 3/04/09.
2 “Capability Maturity Model Integration”, http://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration/, accessed 3/05/09.
3“History of CMM”, http://cmmcmmi.wordpress.com/2007/01/16/history-of-cmm/, accessed 3/04/09.
4 “History”, http://www.sei.cmu.edu/about/press/stats.html, accessed 3/05/09.
5 “CMMI Version 1.2 Overview presentation”, http://www.sei.cmu.edu/cmmi/adoption/pdf/cmmi-overview07.pdf, accessed 3/08/09.
6 “Capability Maturity Model Integration (CMMI), Version 1.1”, http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tr011.pdf, accessed 3/08/09.
7 “Standard CMMI Appraisal Method for Process Improvement (SCAMPI) A, Version 1.2: Method Definition Document”, http://www.sei.cmu.edu/publications/documents/06.reports/06hb002.html, accessed 3/08/09.
8“Standard CMMI Appraisal Method for Process Improvement”, http://en.wikipedia.org/wiki/Standard_CMMI_Appraisal_Method_for_Process_Improvement, accessed 3/08/09.
9 “CMMI Performance Results”, http://www.sei.cmu.edu/cmmi/results/results-by-organization.html, accessed 3/08/09.
10 “CMMI Performance Results”, http://www.sei.cmu.edu/cmmi/2005results.html, accessed 3/08/09.

Six Sigma is problem focused while Lean is process focused. Each has its own methods and tools that attempt to eliminate a common denominator, waste. Waste does not bring home the bacon. The statistical ‘sigma’ level is a measure of the amount of yield of your processes or services for every 1 million produced or performed. The table below shows the percentage of yield per sigma level.

Outside of the yield is considered waste. A lot of hard work pays off when you go from sigma level 1 to 3. Does all that hard work pay off going from 3 to 4 and so on? There doesn’t seem to be that much difference in the yield going from 4 to 5 to 6. Many companies today seem to think so, hence the Six Sigma way. From a Lean perspective, the industry looks at where or what in the flow of your process in producing the product or service is value added. When moving a part from one assembly line to another, the travel time does not add value. When going through a portion of the assembly line that paints the unit a color the customer wants, that is an addition to the value. The customer will pay for that. The travel time from one assembly line to another does not add value and is considered waste. In tackling this waste, each base’s its decisions on data and

facts. Never try to fix something that is broken when you can’t prove with data and facts that it is broken. Six Sigma tackles it’s waste by using a method called DMAIC: Define, Measure, Analyze, Improve, and Control. When you want to fix a problem, you better have a good understanding and knowledge of the problem otherwise you are wasting your time and money. Defining the problem is much like putting together a Project Charter. You are defining the problem, validating it exists, proving its financial worth, laying out the schedule or map of the fix, and creating a communication plan. In measuring, let’s make sure we are on the correct measuring plain using the correct measuring tools to take the correct measurements. In analyzing, you must look at the measurements and pinpoint the correct causes affecting the output. When you move to improve, hear and view all the potential solutions, prioritize them, way out the risks, and start making it happen. Then, you are in control. You complete the project and create the new process and pass it on to those who own it. Lean tackles waste using the following process:

1. Identify the activities that create value.
2. Determine the sequence of activities (also called the value stream)
3. Eliminate activities that do not add value
4. Allow the customer to ‘pull’ products/services
5. Improve the process (start over)

Those activities that add value are those that alter the product or service toward producing the desired output. Different colors of paint add value. Waiting for it to dry or transporting it to the next phase does not. Value Stream Mapping is one method used to visually map out the process. With Six Sigma we analyze the measurements of data; in Lean we visualize the process. Activities that do not add value are eliminated. We allow the customer to ‘pull’ as apposed to the manufacturer or service provider ‘pushing’. Ever walk into those mini-marts at midnight while traveling and see the already made Ham-n-Swiss sandwich. Sometimes you can never tell how long it’s been sitting there. The maker ‘pushes’ Ham-n-Swiss packaged sandwiches. Subway on the other hand, makes it the way you like it right there in front of you and you ‘pull’ the sandwich. In Lean, note the emphasis on the customer’s perception of ‘added value’. Improving the process or starting all over could be rather simple. In some case’s one could be looking at ‘a horse of another color’. Not wanting to get to deep into another philosophy of process improvement, that being the ‘Theory of Constraints’, one could go round and round. A constraint is something that causes a bottleneck. A constraint keeps the process or service from reaching its full potential. Who or what is perfect?? Take the analogy of the four man relay team in track. Each has to do his best and fastest. Inevitably, one is the slowest. Once you put all your effort to making him faster, then you could create another slower one. And round and round you go! So we look to identify and minimize the constraints. That’s all I got to say about the ‘Theory of Constraints’. Lean also uses the ‘5 S’s’:

• Sort
• Set in order
• Shine
• Standardize
• Sustain

You sort out the needed and items. Align the items in their proper place. Clean it all up. You standardize the first three ‘S’s’. You then make the ‘5S’s’ your job. Go forward!

How do you implement all this? Training, training, training! Proper training is paramount. A company may hire a Master Black Belt that could train personnel to the level of Black Belt. Black Belts can train Green Belts. The Master Black Belt is ‘The Man’. He will run all your projects. Black Belts will lead teams in the various projects. Green Belts assist the Black Belts. Enough Green Belts can change the culture of a company. A company should start with small projects to create the sense of success and to provide encouragement. A company should choose its projects wisely.

In conclusion, management has to show full commitment and select the right people to do the job. Management has to prove it too is amenable to change. Not all may be proficient with the tools and skills required to accomplish this task. Those chosen should be willing and able to learn the tools and skills. Personnel have to be willing to look outside their comfort zones to reach their full potential in making Lean Six Sigma a success. The company should utilize all available resources to use speed and quality to satisfy the customer, improve their process, work together to maximize gain, and base their decisions on accurate and pertinent data and facts.

By: Ed

• Flushes out opportunities at multiple business levels,
• Points out waste visually,
• Determines impact on overall business and/or production process,
• Solicits buy-in from all parties related to the process, and
• Improves existing process.

Utilizing Kaizen Events or Blitzes as a business strategy is committing to sustained continuous improvement. This does not necessarily mean an organization must spend large amounts of money on new equipment or plant expansions. It does mean you are serious about eliminating waste and keeping a close eye on waste creeping back into your operation. Events can be performed for both business and manufacturing processes.

Kaizen events are performed by a team of people that are usually impacted by the process and those most interested in making improvements. A Kaizen team should be made up of specialists (those who perform the task or operation), outsiders (employees from other departments or outside consultants) and decision makers (supervisors, managers, etc.). It is important to have someone on the team that has been trained in facilitating Kaizen events and can train the team. This can be someone inside the organization or a consultant. Many organizations hire outside consultants to facilitate Kaizen events because they offer a fresh perspective.

Once an organization has selected a process for the Kaizen event, a current state map should be developed. This map, generally in the form of a flow chart, shows all steps of the process. Through this mapping process the team must determine what activities are value added and non-value added. This is a critical part of the process because non-value added activities can represent waste in your process and one of the goals of a Kaizen event is to eliminate waste. Examples of non-value added time would be excessive walking in the process, pulling parts and searching for tools. Non-value added activities usually result in higher production costs and lower profit margins.

After the Kaizen team creates a current state map of the process, it determines and evaluates the non-value added activities. Based on this evaluation they now can identify areas for improvement or Kaizen bursts. These improvements are then illustrated on a future state map of the process. Improvements may involve rearranging or reorganizing a workstation, moving tooling or equipment closer to the point of use, purchasing additional tooling or equipment to allow for increased productivity, re-assigning tasks, etc. The team is also charged with making the changes or coordinating implementation of the changes. Once changes have been made, the team collects data on the improvements and report findings to the top management. Since Kaizen is gradual continuous improvement, an organization committed to continuous improvement will continue to utilize Kaizen teams to evaluate and improve its processes.

Kaizen Event Example

Since fast food services have utilized lean manufacturing processes, such as Kaizen events, they are good examples of lean process efficiency. Consider the process for making french fries that was utilized in the early days of fast food restaurants. The present state diagram below illustrates these steps for processing french fries:

Based on the data presented, it takes a little over 7 minutes to process one bin of french fries. Considering the amount of customers that eat at fast food restaurants, a Kaizen team would identify this as an area of potential improvement. Based on analysis of the present state, the following was identified:

• The french fry cook must walk to the freezer, located in the rear of the restaurant, each time fries must be cooked,
• The time it takes to measure the correct amount of frozen french fries varies and the measurement is not always consistent, and
• Too many frozen fries in the basket can result in under-cooked fries and too few frozen fries can result in over-cooked fries.

Based on these findings, our Kaizen team makes the following recommendations:

• The frozen fry storage should be located near the fryer, and
• An automated system for measuring and dispensing fries should be added to the process.

This process is what we now see in many fast food restaurants. To complete the process, the Kaizen team would identify the results of the improvements:

• The time to produce one basket of french fries was reduced by 2 minutes and 25 seconds, and
• They anticipate a reduction in over-cooked and under-cooked french fries since an automated measuring system has been implemented.

This is a simple example of how Kaizen can be utilized to continuously improve production or business processes. Based on my experience, organizations who utilize Kaizen events are able to increase productivity and improve overall process efficiency.

By: Alan

References

(1) http://www.strategosinc.com/kaizen.htm
(2) http://www.bevalengineering.com/Kaizen.html
(3) http://www.lclark.edu/~soan221/97/Mcdonald’s.production.chai.html
(4) Reengineering the Corporation, A Manifesto for Business Revolution, Michael Hammer and James Champy, HarperCollins Publishers, 2003.