We will start with XML. XML, or Extensible Markup Language, is a set of guidelines, or rules, for encoding data eletronically. W3C defines XML in it’s XML 1.0 Specification. XML’s purpose is to make the transmission of data over the Internet more simple and usable. There are several schema systems and programming interfaces based on many different XML languages but XML by itself is just a set of rules that defines how to encode data. Let’s say you have a computer program that you use to enter orders for a new car. Let’s also say that computer program send the order to another computer system. It would be beneficial for the order to be sent in XML so the back-end system knows if the data is properly formatted. I’ll give an example of what this order may look like: 

<?xml version=”1.0″ encoding=”UTF-8 ?>  

  <auto_order>
    <auto_year>2010</auto_year>
    <auto_make>Cheverolet</auto_make>
    <auto_model>Cobalt</auto_model>
    <auto_color>Black</auto_color>
  </auto_order> 

This is obviously an over-generalized example but as you can see, it would be obvious for the back-end system to sort through this data and validate if it is correct or not.

Now that you have a general understanding of XML, let’s talk about Business Processes. A business process is a collection of tasks or activities that outputs a particular product or service for a specific customer. It is common that business processes are put on paper as a flowchart. An example of a business process could be the steps necessary to create a widget in a factory. Another business process could be the activities involved in sending data from one system to another. Why is it so important to document and know the many different business processes in your job or industry? Without knowing these processes, you can not accurately measure the efficiency and effectiveness of these processes. 

Before I start rambling, let’s get into the subject at hand: XPDL or XML Process Definition Language. The organization Workflow Management Coalition, or WfMC, were the first to define and standardize XPDL. As I mentioned before, different products communicate with each other using XML. Even though XML is a standard, these different products were using XML in their own ways. The WfMC saw a need for improvement in this communication of data and created a standard XML format for these workflow products to interchange Business Process definitions. This standard became XML Process Definition Language. Let me clarify that XPDL is not a format to communicate to actual data. XPDL is used to communicate the Business Process definitions. 

One area the greatly benefited from XPDL is Business Process Modeling Notation or BPMN. BPMN is a graphical representation for defining the business processes in a workflow. Before XPDL was standardized, there wasn’t an efficient way for workflow products to communicate these business processes in a graphical way. For instance, XPDL contains elements to hold graphical information, such as the X and Y position of the nodes, as well as executable aspects which would be used to run a process. 

In summary, XML Process Definition Language is a way for workflow products to communicate Busines Process definitions over XML in a standardized, simple format. XPDL revolutionized the communication of BPMN and remains to be the best format for doing so. While XPDL is only used in a specialized, niche area of industry, it’s importance should not be overlooked. 

By: Michael 

Refrences:
1. http://en.wikipedia.org/wiki/XPDL
2. http://www.pcmag.com/encyclopedia_term/0,2542,t=XPDL&i=55083,00.asp
3. http://en.wikipedia.org/wiki/Business_Process_Modeling_Notation
4. http://en.wikipedia.org/wiki/Workflow_Management_Coalition
5. http://www.wfmc.org/xpdl.htmlhttp://www.wfmc.org/xpdl.html
6. http://en.wikipedia.org/wiki/XML
7. http://en.wikipedia.org/wiki/Business_Process

Web Services (WS) are becoming the prominent paradigm for distributing, computing, and electronic business, while there is an increasing surge to provide online Business-to- Business collaborations. Web Services are unable to handle true peer-to-peer collaborations. Never the less, Web Services Choreography Description Language (WS-CDL) is the solution to such a need. WS-CDL is a Web service specification developed by W3C; it provides peer-to-peer collaborations for participants from different parties.

The WS-CDL is an XML-based language, where ordered message exchanges result in accomplishing a common business goal. The WS-CDL specification is targeted for composing any type of Web Service participant regardless of the supporting platform or programming model used by the hosting environment.
Goals of WS-CDL

Here are some goals of WS-CDL:

• Reusability: The same choreography definition is usable by different participants operating in different contexts with different software.
• Cooperative: Choreographies define the sequence of exchanging messages between two (or more) independent participants or processes by describing how they should cooperate.
• Multi-Party: Choreographies can be defined involving any number of participants or processes.
• Semantics: Choreographies can include human-readable documentation and semantics for all the components in the choreography.
• Compensability: Existing Choreographies can be combined to form new Choreographies that may be reused in different contexts.
• Exception Handling: Choreographies can define how exceptional or unusual conditions that occur at the same time as the choreography is performed are handled.

WS-CDL Model Overview

In order to facilitate interoperable, peer-to-peer collaborations between parties, web services commit to mutual responsibilities by establishing relationships. Their collaboration takes place in a jointly agreed set of ordering and constraint rules, whereby information is exchanged between the parties.

The WS-CDL model consists of the following entities:

• Participant Types, Role Types and Relationship Types: Within Choreography, information is always exchanged between parties within or across trust boundaries. A Role Type enumerates the observable behavior a party exhibits in order to collaborate with other parties. A Relationship Type identifies the mutual commitments that must be made between two parties for them to collaborate successfully.
• Information Type, Variables and Tokens: Variables contain information about commonly observable objects in collaboration, such as the information exchanged or the observable information of the Roles involved. Tokens are aliases that can be used to reference parts of a Variable. Both Variables and Tokens have Types that define the structure of what the Variable contains or the Token references
• Choreographies: Choreographies define collaborations between interacting parties:
o Choreography Life-line: The Choreography Life-line expresses the progression of collaboration.
o Choreography Exception Blocks: An Exception Block specifies what additional interactions should occur when a Choreography behaves in an abnormal way
o Choreography Finalizer Blocks: A Finalizer Block describes how to specify additional interactions that should occur to modify the effect of an earlier successfully completed Choreography, for example to confirm or undo the effect
• Channels: A Channel realizes a point of collaboration between parties by specifying where and how information is exchanged
• Work Units: A Work Unit prescribes the constraints that must be fulfilled for making progress and thus performing actual work within a Choreography
• Activities and Ordering Structures: Activities are the lowest level components of the Choreography that perform the actual work.
• Interaction Activity: An Interaction is the basic building block of a Choreography, which results in an exchange of information between parties and possible synchronization of their observable information changes and the actual values of the exchanged information
• Semantics: Semantics allow the creation of descriptions that can record the semantic definitions of every component in the model

An Example of WS-CDL in use

In figure1 , Company A and Company B wishes to integrate their Web Services based applications. The respective business analysts at both companies agree upon the services involved in the collaboration, their interactions, and their common ordering and constraint rules under which the interactions occur. In this example, Choreography specifies the interactions between services across business entities ensuring interoperability, while leaving actual implementation decisions in the hands of each individual company.
Conclusion

WS-CDL enables the business stake holder, the business analyst, the enterprise architect and the application engineer to share their views of the same system in a synchronized fashion, by providing the means for each level of detail for each stake holder to be captured without that detail being necessarily exposed to the others. Also WS-CDL provides the necessary provenance to enforce requirements at each level.

By: Suman

References
1) http://www.w3.org/TR/2004/WD-ws-cdl-10-20041217/
2) http://www.ibm.com/developerworks/xml/library/ws-choreography/index.html
3) http://www.service-architecture.com/web-services/articles/ws_choreography_description_language_cdl.html
4) http://www.infoq.com/news/2007/11/wscomposition
5) http://student.cse.fau.edu/~jsloan11/CEN6076/168_ChoreographyExecutionEngine.pdf

Web services make application functionality available over the Internet in a standardized, programmatic way. Applications that couldn’t be accessed except by following rigid proprietary protocols can now talk to one another over the Internet, regardless of their native language, platform or internal protocols.
Web services have resulted from the convergence of three important events. The first was the emergence of the Internet as a cost-effective and widespread infrastructure. The second was the adoption of XML as a standard. And the third was the emergence of a set of common Web services standards–namely, the Simple Object Access Protocol (SOAP) and Web Services Description Language (WSDL)–which have been accepted by major platform vendors in place of proprietary standards such as CORBA and DCOM.
Web services have special behavioral characteristics:

XML-based

Web Services uses XML at data representation and data transportation layers. Using XML eliminates any networking, operating system, or platform binding.
Loosely coupled

A consumer of a web service is not tied to that web service directly. The web service interface can change over time without compromising the client’s ability to interact with the service.
Coarse-grained

Businesses and the interfaces that they expose should be coarse-grained. Web services technology provides a natural way of defining coarse-grained services that access the right amount of business logic.

Ability to be synchronous or asynchronous

Aynchronicity refers to the binding of the client to the execution of the service. In synchronous invocations, the client blocks and waits for the service to complete its operation before continuing. Asynchronous operations allow a client to invoke a service and then execute other functions.

Supports Remote Procedure Calls (RPCs)

Web services allow clients to invoke procedures, functions, and methods on remote objects using an XML-based protocol.

Supports document exchange
One of the key advantages of XML is its generic way of representing not only data, but also complex documents.

Web Service Architecture

Two ways to view the web service architecture.
Examine the individual roles of each web service actor.
Examine the emerging web service protocol stack.
________________________________________

Web Service Roles

There are three major roles within the web service architecture:
Service provider:

This is the provider of the web service. The service provider implements the service and makes it available on the Internet.
Service requestor

This is any consumer of the web service. The requestor utilizes an existing web service by opening a network connection and sending an XML request.
Service registry

This is a logically centralized directory of services. The registry provides a central place where developers can publish new services or find existing ones. It therefore serves as a centralized clearinghouse for companies and their services.
________________________________________

Web Service Protocol Stack

A second option for viewing the web service architecture is to examine the emerging web service protocol stack. The stack is still evolving, but currently has four main layers.

Service transport layer is responsible for transporting messages between applications. Currently, this layer includes HTTP, SMTP, FTP, and newer protocols, such as Blocks Extensible Exchange Protocol (BEEP).

XML messaging layer is responsible for encoding messages in a common XML format so that messages can be understood at either end.

Service description layer is responsible for describing the public interface to a specific web service. Currently, service description is handled via WSDL.

Service discovery layer is responsible for centralizing services into a common registry, and providing easy publish/find functionality.

Over the past few years, three primary technologies have emerged as worldwide standards that make up the core of today’s web services technology.

XML-RPC is the simplest XML based protocol for exchanging information between computers.
SOAP is an XML-based protocol for exchanging information between computers.
WSDL is an XML-based language for describing Web services and how to access them.
UDDI is an XML-based standard for describing, publishing, and finding Web services.

As a part of Web Services implementation, we will create following two components:
Service provider or publisher: The service provider implements the service and makes it available on the Internet or intranet.

Service requestor or consumer: The requestor utilizes an existing web service by opening a network connection and sending an XML request.
Types of Web Services:

Big Web Services: use XML messages that follow the SOAP standard and have been popular with traditional enterprise.

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.
Web Service Benefits:
• Exposing the existing function on to network
• Connecting Different Applications.
• Standardized Protocol
• Low Cost of communication

Conclusion: Web services utilize existing IT infrastructures and allow companies to wrap legacy applications in a standardized, consistent and reusable format so every investment can be leveraged. They provide a low-cost way to connect internal applications and collaborate among business partners.

By: KN

References

http://www.ebizq.net/topics/web_services/features/1542.html?page=1

http://www.tutorialspoint.com/webservices/index.htm

http://msdn.microsoft.com/library/ee958158.aspx

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

BPEL, also referred to as WS-BPEL or Web Services Business Process Execution Language, is an XML based language used for orchestrating web services. BPEL is considered “programming in the large”. In 1975, long before the emergence of web services and BPEL, Frank DeRemer and Hans Kron discussed “programming in the large” in a way that that is very helpful in understanding the purpose of BPEL:

“We distinguish the activity of writing large programs from that of writing small ones. By large programs we mean systems consisting of many small programs (modules), possibly written by different people. We need languages for programming-in-the-small […] for writing modules. We also need a “module interconnection language” for knitting those modules together into an integrated whole”

In this reference, one can look at the business process as the large program/system , the web service as the small program/module, and BPEL as the yarn that knits the web services together. BPEL has grown in popularity over recent years as Services Oriented Architecture (SOA) has emerged as one of the leading standards for system development.

History

BPEL, like many technical standards, emerged from cooperation of companies that started off developing their own specifications. In the early 2000’s, Microsoft and IBM were both developing their own standards for orchestrating web services. Microsoft was developing XLANG and IBM was developing WSFL, Web Services Flow Language. In 2002, Microsoft, IBM, and BEA jointly developed the initial version of BPEL, BPEL4WS 1.0, and submitted the specification to OASIS for publication. SAP and Siebel joined these companies in developing BPEL4WS 1.1. When WS-BPEL 2.0 was

The Technical Side

BPEL is an XML-based programming language. Just like other programming languages, it includes constructs for conditional branching, looping, variable declaration, simple data manipulation, and sequential command processing. Most importantly, BPEL provides constructs for messaging and invoking web services and for handling the transactional state of the BPEL process.

BPEL can invoke web services in two manners, synchronously and asynchronously. An asynchronous web service call employs a “fire and forget” pattern, the BPEL message invokes a web service and then continues on with its processing. A synchronous web service follows a request and response pattern. In a synchronous call the BPEL process invokes a web service and then waits for a reply to continue processing.

BPEL also handles transactional state processing for web services. BPEL processes can have execution times that span from a number of seconds periods to long periods of time from days to months depending on response time of the web services being called. Both long and short running BPEL processes must be capable of being rolled back if the need arises. BPEL provides a construct called compensation to handle this situation. Compensation is the reversing of business process steps that have previously been executed.

What BPEL is NOT

BPEL is not a graphical representation of a business process. Although Business Process Modeling Notation (BPMN), a flow charting notation for businesses, can be mapped to the BPEL specification, there is no direct mapping of BPEL back to a graphical format.

BPEL is not used for defining business processes which include human interaction. By itself, WS-BPEL is only capable of defining the communication and interaction of web services. Two extensions to BPEL, WS-HumanTask and BPEL4People, are currently being developed with the purpose of adding the ability to account for human activities in business processes.

BPEL Tools

Although the BPEL XML file provides all of the information necessary to describe and invoke web services as part of business process, an engine is needed to execute that process. Many BPEL engines are available today. There are open source engines such as ActiveBPEL and Open ESB as well as commercial engines provided by large vendors including Oracle, SAP, and Websphere. A number of IDE’s are also available, including Eclipse and JDeveloper, to assist with generating BPEL XML documents.

Conclusion

Service oriented architecture is becoming the new standard for building large IT systems. The BPEL specification is an enabler of more widespread and standard use of the web services exposed in the SOA model .

By: Jill

Sources:

1) http://bpel.xml.org/history
2) http://en.wikipedia.org/wiki/Bpel
3) DeRemer, F. and Kron, H. (1975). Programming-in-the large versus programming-in-the-small. In Proceedings of the international conference on Reliable software, pages 114-121, New York, NY, USA. ACM.
4) Oasis: Web Services Business Process Execution Language Version 2.0, Primer, 9 May 2007
5) http://www.oracle.com/technology/tech/soa/mastering-soa-series/part3.html

Model-driven architecture (MDA) is a software design approach for the development of software systems. It provides a set of guidelines for the structuring of specifications, which are expressed as models. Model-driven architecture is a kind of domain engineering, and supports model engineering of software systems. It was launched by the Object Management Group (OMG) in 2001.

Model-Driven Architecture is a “philosophy” of how models should be used in the software development process. Developers across the software industry are embracing this philosophy as they apply and evolve MDA principles as defined by the OMG.

The OMG Model-Driven Architecture (MDA) addresses the life cycle that spans design, deployment, integration, and management of applications. The OMG’s MDA initiative is an evolving conceptual architecture for a set of industry-wide technology specifications that support a model-driven approach to software development.

Model-Driven Architecture (MDA) is a style of enterprise application development and integration, based on using automated tools to build a system-independent model and transform them into efficient implementations. The Object Management Group (OMG) has defined standards for representing MDA models, but the principles and practice of MDA are still evolving. At one extreme, MDA is little more than a front end to writing code in traditional programming languages, such as C++ and Java. At the other extreme, some authors expect an almost magical increase in power by simply using models. Some believe that MDA has the potential to greatly reduce development time and greatly increase the suitability of appplications; it does so not by magic, but by providing mechanisms by which developers can capture their knowledge of the domain and the implementation technology more directly in a standardized form and by using this knowledge to produce automated tools that eliminate much of the low-level work of development. More importantly, MDA has the potential to simplify the more challenging task of integrating existing application and data with new systems that are developed.

From my research, there are three main ideas or complimentary foundations of MDA I would like to briefly discuss.

1. Direct representation
2. Automation
3. Open Standards

Direct representation

Shift the focus of software development away from the technology domain toward the ideas and concepts of the problem domain. Reducing the semantic distance between problem domain and representation allows a more direct coupling of solutions to problems, leading to more accurate designs and increased productivity.

Perhaps the greatest difficulty associated with software development is the enormous semantic gap that exists between domain-specific concepts encountered in modern software applications, such as business process management or telephone call processing, and standard programming technologies used to implement them. This is true even with the use of present-day “high-level” software frameworks, such as .NET, J2EE, or various Web service architectures and standards. While these frameworks do raise the level of abstraction above that found in today’s programming languages, such as Java or C#, they are still focused primarily on computer concepts rather than application-level concepts. Hence, the effort required to implement complex applications is still formidable because the semantic gap is so large

Clearly, the more directly we can represent concepts in the application domain, the easier it becomes to specify our systems. Conversely, the greater the distance between the application domain and the model, the less value we get from modeling. Thus, although it is still beneficial to model C# or Java programs using UML–because UML hides a lot of irrelevant detail related to programming language syntax–the full value of MDA is only achieved when the modeling concepts map directly to domain concepts rather than computer technology concepts.

Of course, there are many different application domains, often requiring very different concepts. Furthermore, as experience and knowledge grow, these domains become increasingly more complex and sophisticated. It does not require much insight to realize that different domains will need different, domain specific languages (DSLs).

Domain-specific languages have been around for a long time. Graphical User Interface (GUI) builder systems allow developers to build interfaces by directly selecting and manipulating buttons and other interface widgets, rather than writing pages of repetitive code using a graphics library. Query-by-example database systems allow users to construct simple queries by entering values in a table, rather than writing SQL code. A WYSIWYG desktop publishing application, such as FrameMaker® or Microsoft Word®, is a lot faster and less error-prone than scripting a document in Unix LaTeX.

Domain-specific languages make assumptions about the domain to greatly reduce the size of the specification by exploiting regularities. Only certain kinds of buttons or queries can be used in a GUI. There are things that you can do in troff that you cannot do in a WYSIWYG application. In exchange for the restrictions, however, there is a great simplification in representation that more than justifies the occasional limitation. In fact, the regularity imposed by a domain framework often benefits users by ensuring that all applications use a similar style.

Automation

Direct representation of an application problem is useful for capturing thoughts (the “modeling language as sketch” approach), but if humans must translate the model into an implementation language it will take a lot of time and introduce a lot of errors. MDA increases speed and reduces errors by using automated tools to transform domain-specific models into implementation code. This is the same thing that compilers do for traditional programming languages. Automated model transformations can be applied for other purposes as well. For example, they can be used to provide custom views of complex systems from various viewpoints. They can be used to transform a model based on one type of formalism to a different one, perhaps one that is suitable for some kind of specialized analysis, such as performance or schedulability analyses.

Automation can also analyze models for various flaws, for example, to verify whether a given specification possesses desired safety and liveness properties. Testing can also be automated through generation and execution of test cases or through formalized analysis techniques such as model checking and theorem proving.

Yet another important form of automation available in MDA is the ability to execute models directly, using run-time interpreters. This is, in effect, a transformation directly to execution.
Automation is not magic. An MDA framework makes assumptions about the application domain and the implementation environment. These assumptions constrain the model and permit efficient mappings from the model to the execution domain. For example, in a GUI builder, the buttons all have a regular form, and, more importantly, they are all used in a particular way. The logic of the domain can be built into the application framework, rather than being written by the developer from scratch each time.

Open Standards

Industry-wide standards achieve more than just reuse; they also encourage the emergence of an entire ecosystem of tool vendors addressing many different needs. No single vendor can afford to address all needs. Big vendors, such as IBM, Microsoft, and Sun, can afford the investment needed for large integrated platforms, but they rarely cover the full spectrum of smaller niche markets that may require highly specialized domain knowledge. Small niche vendors can succeed in relatively small markets if they can minimize their development costs by building specialized knowledge on top of generic platform tools. But, they cannot succeed if their tools will not work with the generic tools or if they do not have access to the entire population of users because the big vendors have fragmented the market. The success of automation requires an ecosystem of a few large vendors, many medium vendors, and hundreds of small niche vendors, together providing much more capability to users than any one vendor could supply alone. But this ecosystem will be attractive to vendors and users only if standards ensure that the many tools work together. The CASE industry of the 1980’s failed in part because each vendor tried to do everything alone.

A good example of a software ecosystem surrounds Adobe® Photoshop®, an application that has revolutionized graphics design. A number of independent vendors supply add-ins, such as additional filters, that extend the power of Photoshop. Other vendors supply images that can be used with Photoshop. The combination of generic functionality and optional additions allows users to tailor solutions to their needs that no vendor could afford to develop alone, because the add-ins and images all adhere to a set of standards.

The presence of standards is generally a sign of the maturity of an industry. The MDA standards adopted to date—in particular, the UML and MOF modeling language standards—represent the consolidation of years of experience in the design and usage of software modeling languages in various situations and domains. In the future, we would expect standardization at higher levels and across various domains as well. Proposals are under development in OMG for the domains of Business Process Definition, Business Rules, Business Vocabularies, Life Sciences, Health Care, and Financial Services.

Conclusion

Model Driven Architecture gets power by building models that directly represent domain concepts. Domain-specific languages may either be built on top of general languages such as UML or through meta-modeling frameworks such as MOF. By using frameworks that explicitly model assumptions about the application domain and the implementation environment, automated tools can analyze models for flaws and transform them into implementations, avoiding the need to write large amounts of code and eliminating the errors caused by programming. Not all lower-level programming will be eliminated, of course, but much highly repetitive boilerplate code that realizes standard implementation patterns can be automatically generated. A marketplace of vendors of various sizes and interests can provide a range of capabilities that no single vendor can provide-provided standards exist so that vendors will be able to integrate with other tools of complementary capabilities.

MDA is not a vision of some future since it has already proven itself many times over in diverse application domains; instead, it is a map that, if we choose to follow it, will help us develop better software systems faster.

By: Christopher

References:

1. http://www.-ol.ibm.com/software/rational/uml/mda/
2. MDA Journal, May 2004, An MDA Manifesto, by Booch, Brown, Iyengar, Rumbaugh and Selic
3. http://www.omg.org/mda/
4. Enterprise Architecture A to Z, Chapter 7, Daniel Minoli.
5. Http//en.wikipeida.org/Model-Driven_architecture.

What is it?

SOA is an architecture design principals for publishing software code (normally in the form of services) and consuming said published code. The publishing and consuming of these services is accomplished because they use a standard communication definition. This means the published code and the consuming code do not have to be the same language or platform. The services do not have to reside on the same network or even in the same company! 

Figure 1 – Wikipedia

It also represents a shift in the mindset for companies’ business units. Code and applications developed for a business unit is normally only for that business unit and not shared throughout the company. This means that if another business unit is creating an application that has to do some of the same functions, it has to re-create those functions. Using SOA, functions can be created for one business unit and published on the network to be consumed by other business units’ projects.

What are the benefits?

Using and SOA architecture provides several benefits. As stated above, SOA promotes code reuse in the form of published services. These services can be consumed by other applications across the enterprise and the services can be updated and maintained with fewer overheads since the services can be updated without the consuming applications needing code changes. The cost of developing the services can be spread over the many business units that consume them, helping to keep development costs down. Once enough services are published, new application development can almost be reduced to simply consuming the needed services. Little if any custom code is needed with enough services being published. One of the largest benefits is the increased ability for Business-to-Business interaction. Businesses can publish services their customers and partners can consume that increase the scope and speed of the business they can do with their customers and partners. Most importantly, they retain more control over their code since they did not have to provide SDKs[1] or DLLs [2]that could be reverse engineered.

What are the problems?

As with all things IT, there are some problems, perceived or real. One has to remember that SOA is architecture and that architecture can be implemented using various technologies. Most problems that have been noted are related to the technology used to implement SOA, not really SOA itself. An example of this is in using web services with SOAP[3]. There is an overhead cost associated with serialization and de-serialization of SOAP XML messages as compared to native RPC[4] calls. Another issue is the management of metadata[5]. As an SOA environment grows, the amount of metadata to describe the services and what they offer can become difficult to manage.

Another issue that is not really technology is the fact that to properly design SOA architecture, the Business managers must work hand in hand with the IT architects. It is this close cooperation that will produce a successful SOA structure that meets the needs of the business drivers.

What is my opinion?

The ease of code re-uses, an ability to quickly combine services to create new applications, and increased Business to Business interaction capabilities well out weigh the drawbacks I have read about. I do not feel it is the end all solution to IT in business, but I do feel it is an important component.

I believe that SOA combined with advances in grid and cloud computing are going to enable the development of new ways to deliver powerful applications quickly and on more client platforms than before. For instance, presentation devices like the iPhone and iPad could consume an application that helps coordinate disaster relief. It could take input from the user and run complex calculations in the cloud based on real time data that is constantly updated to provide the best solution for the moment and needs forecasts generated from past trends. The presentation device provides minimum computing power but connects the user to the services and resources that do the heavy lifting.  A single company or a group of companies could provide these services that are combined to create the application.

By: Jaret

References

Wikipedia Service Oriented Architecture
http://en.wikipedia.org/wiki/Service-oriented_architecture

Service Oriented Architecture for Dummies
Hurtwiz, Bloor, Baroudi, and Kaufman

Enterprise Architecture A to Z
Daniel Minoli

Dictionary.com
http://www.dictionary.com

[2] Dynamically Linked Library (DLL) A library which is linked to application programs when they are loaded or run rather than as the final phase of compilation. 

[3] Simple Object Access Protocol (SOAP) A minimal set of conventions for invoking code using XML over HTTP.

[4] Remote Procedure Call (RPC) A protocol which allows a program running on one host to cause code to be executed on another host without the programmer needing to explicitly code for this.

[5] Metadata – data about data; “a library catalog is metadata because it describes publications”

The key elements of JIT, and the techniques for achieving JIT, are:
• Load leveling – This technique involves determining appropriate quantities and types of products needed in a given day to meet the customers orders. This allows organizations to produce products with a variety of customer specifications each day, in a smooth sequence that minimizes inventory and delay.
• Production Sequencing – This involves calculating the pattern for making each product type in the required amount for any given day.
• Kanban – Often referred to as the “nervous system” of lean production, kanban is a key technique that determines the processes of production quantities, and in doing so, facilitates JIT production and ordering systems. Kanban’s “pull” system creates greater flexibility on the production floor, so the organization only produces what is ordered.

Kanban (signals) are a critical part of the Just-in-time system. Therefore, it is important when implementing the kanban system, to focus on four important “rules”.
1. Kanban works from upstream to downstream in the production process (i.e., starting with the customer order). At each step, only as many parts are withdrawn as the kanban instructs, helping ensure that only what is ordered is made. The necessary parts in a given step always accompanies the kanban to ensure visual control.
2. The upstream processes only produce what has been withdrawn. This includes only producing items in the sequence in which the kanban are received, and only producing the number indicated on the kanban.
3. Only products that are 100 percent defect-free continue on through the production line. In this way, each step uncovers and then corrects the defects that are found, before any more can be produced.
4. The number of kanban should be decreased over time. Minimizing the total number of kanban is the best way to uncover areas of needed improvement. By constantly reducing the total number of kanban, continuous improvement is facilitated by concurrently reducing the overall level of stock in production.

Once the just-in-time and kanban systems are in place the benefits that are realized are:
• Reduced setup time – Cutting setup time allows the company to reduce or eliminate inventory for “changeover” time. The tool used here is single-minute exchange of dies (SMED).
• The flow of goods from warehouse to shelves improves – Small or individual piece lot sizes reduce lot delay inventories, which simplifies inventory flow and its management.
• Employees with multiple skills are used more efficiently – Having employees trained to work on different parts of the process allows companies to move workers where they are needed.
• Production scheduling and work hour consistency synchronized with demand – If there is no demand for a product at the time, it is not made. This saves the company money, either by not having to pay workers overtime or by having them focus on other work or participate in training.
• Increase emphasis on supplier relationships – A company without inventory does not want a supply system problem that creates a part shortage. This makes supplier relationships extremely important.
• Supplies come in at regular intervals throughout the production day – Supply is synchronized with production demand and the optimal amount of inventory is on hand at any time. When parts move directly from the truck to the point of assembly, the need for storage facilities is reduced.
• Eliminates over production – Overproduction affects the environment by increasing the number of products that must be scrapped/discarded as waste; increasing the amount of raw materials used in production; increasing the amount of energy/emissions/wastes that are generated by the processing of the unneeded output.

JIT also has its share of drawbacks as well.
• Can result in more frequent runs for parts/materials
• May not succeed in reducing/eliminating overproduction
• Overproduction can cause damaged goods and inventory storage space.

The philosophy behind JIT is simple: The just-in-time system is the planned elimination of all waste and continuous improvement of productivity, with the objective of producing the right part in the right place at the right time. Waste results from any activity that adds cost without adding value, such as the unnecessary moving of materials, the accumulation of excess inventory, or the use of faulty production methods that create products requiring subsequent rework.

By: April

References:

http://www.epa.gov/lean/thinking/kanban.htm

http://www.strategosinc.com/just_in_time.htm

http://smallbusiness.dnb.com/manage/finances/12375503-1.html

http://en.wikipedia.org/wiki/Just-in-time_(business)

At first glance, the name looks like someone, or a group, simply grabbed four words, slapped them together to form a new idea.

The first point is to get our brains around the name. Relating the name to processes, the idea is created for continuous improvement using mature models of a process to improve quality and potentially reduce costs.
One hypothesis is since it was ‘founded’ at Carnegie Mellon, the acronym for CMMI was a tip of the hat to Carnegie Mellon Institute. It is a registered service mark with the Software Engineering Institute (SEI) at Carnegie Mellon University in Pittsburgh, PA..

Breaking down the name…

Capability = able to do something;
Maturity = seasoned, aged, more developed;
Model = a representation, standard or example;
Integration = bringing all ingredients together.

Roughly translating, a seasoned and well thought example of how to do something that is repeatable and efficient using a model or best practices, and those involved learn from their mistakes or successes, constantly evolving or maturing the process which in turn improves quality, reduces costs, etc..

It is a methodology of continuous process improvement and apparently is a standard similar to ISO 9001 (i). The difference being that ISO 9001 sets a minimum standard of quality and CMMI a means to continually improve the development cycle (ii).

From the SEI/CMMI website, ‘CMMI is a process improvement approach that provides organizations with the essential elements of effective processes that ultimately improve their performance. CMMI can be used to guide process improvement across a project, a division, or an entire organization. (iii) Processes are identifiable actions or steps to an end or goal within organizations. Having a process that is poorly defined, insufficiently detailed, unrealistic or any other of a number issues, means the process will be flawed. CMMI helps eliminate those issues. ‘While process is often described as a node of the process-people-technology triad, it can also be considered the “glue” that ties the triad together. (iv)

How does it help? CMMI uses ‘maturity’ stages or layers to identify the age and wisdom of a process or organization. Those layers are initial, managed, defined, quantitatively managed and optimizing. No one step can be skipped to achieve varying levels of maturity.

• Initial- Process(es) that are poorly defined, unreliable and in many cases consistently over budget.
• Managed- Process(es) are still basic but planned and more refined. Some basic measurements and requirements are established.
• Defined- Processes are now defined with specific and generic goals. Further, processes are standardized for consistency throughout the organization.
• Quantitatively managed- Processes now have statistical, quantitative and qualitative measurements for process enhancement, improvement and control.
• Optimizing- Processes are now in focus with continual improvements using the various previously established methods of control, statistical measurements and methods.

Gleaned from a previous class, this is reminiscent of Bruce Tuckman’s ‘Forming, Storming, Norming, Performing’ of group development. Where the ‘initial’ and ‘managed’ phases may be represented by the ‘forming’ phase of a group. ‘Defined’ is represented as ‘storming.’ Layer 4, ‘quantitatively managed’ represents ‘norming.’ And the last layer of ‘performing’ is ‘optimizing.’ At each level, the group/process is sharpened and better organized.

One difference though is CMMI requires organizations utilizing various processes, big or small, to be certified or ‘recognized’ at different levels. Much like using a whetstone to hone a knife as a process is ‘sharpened,’ the process is identified at a certain stage until ‘level 5’ is achieved.

Using the CMMI models (currently V1.2) there are three areas for process improvement also known as ‘constellations.’ Those are 1) development, 2) services, and 3) acquisitions. ‘CMMI models are collections of best practices that you can compare to your organization’s best practices and guide improvement to your processes. (vi)

CMMI-DEV- Deals with development organizations and processes like software.
CMMI-SVC- Relatively new offering for service oriented industries, but similar mature models and best practices for the service industry.
CMMI-ACQ- Refers to models improving processes related to solution acquisitions. Improves control of projects and processes to meet the needs of an organization.

For greater detail and to drive down in the detail of CMMI, please see http://www.sei.cmu.edu/reports/06tr008.pdf

Within all of these is a framework. This framework provides the structure which includes models, manuals and training to build the previously mentioned constellations. This framework also helps identify the levels of maturity. For more detail of this framework and the varying levels at which a process is ‘mature,’ please visit http://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration.

Bottom line, when you see CMMI, think continuous process improvement, at any level and almost any size organization.

By: TD

i http://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci930057,00.html
ii http://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci930057,00.html
iii http://www.sei.cmu.edu/cmmi/index.cfm
iv http://www.sei.cmu.edu/library/assets/cmmi-overview071.pdf page 7
v http://en.wikipedia.org/wiki/Forming,_storming,_norming_and_performing
vi http://www.sei.cmu.edu/cmmi/index.cfm

In short, what sets Lean Six Sigma apart from its individual components is the recognition that you cannot just improve quality or just improve speed. You need the balanced processes that can help an organization to focus on improving service quality, as defined by the customer within a set time limit.

Six Sigma is a business management strategy realized by Motorola Corporation in 1981. With Six Sigma the goal is to reduce process variation statistically.

Lean is the practice of breaking down processes to the minimum required to be productive while also eliminating non-value added waste. Basically the bloated processes lose weight, or become “lean”. Lean is usually employed by determining and visually mapping the flow of processes, flowcharts can be used. Lean is often employed in five distinct steps—identify value, define value streams, determine flow, define pull, and improve process.

Lean Six Sigma is a business process improvement technique that maximizes value by achieving the speediest rate of improvement in customer satisfaction, cost, quality, process speed, and invested capital. The fusion of Lean and Six Sigma improvement methods is required because:
• Lean cannot bring a process under statistical control
• Six Sigma alone cannot dramatically improve process speed or reduce invested capital
• Both enable the reduction of the cost and reduction of the complexity of business processes. A lean process is a less complex process.

I conducted a brief interview of a classmate who has a foundational knowledge of lean, six sigma, and lean six sigma. I will allow my source to remain anonymous. This is her thoughts.

Lean—“power to the workers”

She explained that with lean the process improvement teams often get the best improvement results by surveying those who actually perform the work in the path of the process. Those with the hands-on knowledge of the flow usually know what is broken and sometimes have improvement ideas that can be included in the BPI plans.

Six Sigma—“solely based on data”

She explained that Six Sigma used alone in BPI initiatives will be focused on data gathering and data analyzing.

Lean Six Sigma—“gives you more tools to work with”

The combination of two seemingly disparate methodologies can prove to solve A BPI initiative from all the angles required to reach genuine and measurable improvement.

One of these tools that will help standardize BPI across a business or organization is DMAIC. I have been discussing Business Process Improvement in the posting for over a dozen paragraphs now, so I was overdue to introduce another complex acronym. Please allow me to define DMAIC.

Define the problem
Measure the key aspects of the current process and collect relevant date.
Analyze the data to investigate and verify cause-and-effect relationships.
Improve the current process based upon data analysis
Control the future state process to ensure that any deviations from target are corrected before they result in defects.

One could write an entire book and hold graduate courses on the use of DMAIC. There are also countless other tools to use with DMAIC. The book ‘The Lean Six Sigma Pocket Toolbook” introduces DMAIC on page one with the well written and inspiring sentence that follows:

The structure of DMAIC encourages creative thinking within boundaries such as keeping the basic process, product, or service.

The book ‘The Lean Six Sigma Pocket Toolbook” also recognizes that some processes are to badly broken ….

From the book—If your process is so badly broken that you need to start from scratch or if you are designing a new product, service, or process, use Design for Lean Six Sigma (DMEDI)

As an outsider researching Lean Six Sigma I have found that using these techniques as a combined BPI toolkit makes a lot of sense and can be very powerful the hands of skilled and dedicated teams. Although, there are purists on both sides of the Lean vs. Six Sigma debate those claims their way is the only way to improve business processes.

I will close by saying that Lean Six Sigma as it has evolved from the two methodologies is very powerful and is logical to use each for its strengths. Use Lean for improved process flow. Use Six Sigma to reduce process variation.

By: Greg

References:
1. http://en.wikipedia.org/wiki/Six_Sigma
2. http://www.articlesbase.com/business-articles/lean-versus-six-sigma-whats-the-controversy-what-the-difference-595677.html
3. http://www.armyobt.army.mil/
4. Interview with IEM Classmate.
5. George, Rowlands, Price, Maxey (2005). “The Lean Six Sigma Pocket Toolbook”, McGraw-Hill Companies

Origin
Kaizen was introduced to us by the Japanese just after World War II when Japan’s economy was struggling. But over the last 30 years has gained momentum in the United States, appearing first in the west with Japanese car manufacturers.

It originates from the words represented below – loosely translated, means continuous improvement.

About the Kiazen methodology:
– It is based on the concept that everything can be improved.
– It encourages looking at a current process, whether broken or not, and assessing that process for improvement.
– It is people driven. To ensure success, the process should be embraced by employees, provoking a spirit of collaboration, bringing about improvements internally from within the organization by the people who participate in the workflow. Every worker is encouraged to make small suggestions in support of improvements.
– Its focus is on small incremental changes, always working toward improvement.

Eastern –vs- Western Philosophies
Perhaps one of the things that make Kaizen successful is the eastern philosophy that ALL people are important to the success or failure of the business. Traditional western management styles dictate a divide among staff by work type. Managers are seen as the leaders and the decision makers. They are often removed from the actual workers who are in a better position to provide them with ways to improve a certain process. Or at the very least, inform them of inefficiencies in a process.

The western management style is often, “if it ain’t broke, don’t fix it”. A style that is reactive rather than proactive. Changes are only implemented for reasons that impact the bottom line in a positive way. You almost never see the boss unless something is wrong. This has a negative effect on staff, it fosters negative behaviors, such as employees waiting to be told what to do, instead of acting on their own and feeling empowered to perform their job. I’ve taken the table below from one of my resources, Graphic Products, Inc. I believe it illustrates the differences in the 2 philosophies quite well.

Benefits
Research suggests that where Kaizen methodologies are properly implemented, unexpected results occur. Managers become better leaders, service line staff become better employees and the whole organization becomes more unified, all working toward a common goal. This methodology cultivates an environment of solidarity. But these kinds of realizations are only received by organizations who sincerely seek new, big or small, ideas from all sources.

Toyota, one of the largest automotive manufacturers is a pioneer in Kaizen principles. They claim they received 75,000 suggestions from 7,000 employees – 99% were actually implemented.

Implementing any new process requires change. Change is often difficult to effect in any cultural. According to research, implementing Kaizen principles takes time and dedication, but does produce favorable results when executed properly.

Conclusion
How can you go wrong fostering an environment where every employee is encouraged to look for a way to make a process better?!

In my own personal experience with culture change, it’s important early “in the game” to advertise small wins. Talk about where successes have been realized and what lessons have already been learned and gain some confidence and respect. That goes a long way.

In my research, I found “The 10 Commandments of Improvement” from Gemba Research LLC. They made me think about things with a different perspective. We are such a culture of negative thinking. I like these and plan to use them in future process improvement initiatives.

1. Abandon fixed ideas.
2. Think of ways to make it possible.
3. No excuses needed.
4. Go for the simple solution, not the perfect one.
5. Correct mistakes right away.
6. Use your wits, not your wallet
7. Problems are opportunities.
8. Repeat “why” five times.
9. Seek ideas from many people.
10. There is no end to improvement.

By: Lynn

References:
Gemba Research LLC– www.gemba.com
Graphic Products, Inc.– www.graphicproducts.com
Army Business Transformation Knowledge Center
Value Based Management- www.valuebasedmanagement.net/methods_kaizen.html