April 21, 2011

Web Services

When I first saw the phrase “web services” I said to myself, “this topic should be fairly simple.” Then I started researching and realized just how fast this could spiral into something much bigger than I expected. With all of the related topics and acronyms I found my next thought was “can someone explain this in plain English?” To add to the confusion, I also needed to know how web services relate to business process modeling.

Let’s start with the definition of web services. “Web services are self-contained, modular business process applications that are based on the industry standard technologies of WSDL (to describe), UDDI (to advertise and syndicate), and SOAP (to communicate). They enable users to connect different components even across organizational boundaries in a platform- and language-independent manner.” (Leymann) Right away we know what industry standards are used and for what reasons. We also get an idea of how they help organizations communicate. That’s a lot of information but the simplest definition is as follows: “A web service is a method of communication between two electronic devices over a network”. (Wikipedia) So, how does that relate to business processes modeling?

In order to relate the two you must introduce Extensible Markup Language (XML) execution languages that are focused on web services such as BPEL4WS. “The key element of such languages is that they are optimized for the operation and interpretation of [Business Process Modeling] Systems.” (Minoli) The drawback of BPEL4WS is that it still doesn’t sound like plain English to the business people that need it most. This is where the Business Process Modeling Notation (BPMN) enters the scene. “This specification provides a graphical notation for expressing business processes in a Business Process Diagram (BPD).” (Minoli) In other words, BPMN is used to paint a picture for business people (and others that aren’t technically savvy) so they can understand and use web services as computer systems do.

So we know what web services are. We also know what is needed for business people to better understand them. Now the question is how do web services work? Like most architectures, web services are “built from layers of technology and standards on which services can be implemented and deployed”. (O’Riordan) David O’Riordan offers a straight forward, high level description of these layers:

· Packaging/Transport – This enables information to be packaged into messages and transported reliably and securely between participants. It is sometimes just called the messaging layer.

· Service – This layer describes the operational interfaces of a Web Service.

· Quality of Service – This layer describes non-operational aspects of services, including reliability and security characteristics.

· Orchestration – This layer describes how services interact with each other in business processes using workflow descriptions. This layer is also sometimes referred to as the choreography layer.

· Agreements – This layer describes how specific trading partners will collaborate to perform some shared business process.

Not only was I in favor of these descriptions for their comprehensible information but also the fact that they are easily related to business processes.

All of that information is great but still isn’t worth anything if you don’t know when to use web services. So my final question is when are web services useful? Because they are so popular, web services can seem like the “magic pill” that will solve any communication issue within a business. There are, however, some optimal times in which web services are recommended. First and foremost, “web services support heterogeneous integration”. (Manes) In other words, applications in environments that normally can’t communicate with each other can do so through web services. That’s great if you know what you’re getting into and even better when “you have little knowledge of or control over the client applications that will be used”. (Manes) Other web services applications discussed by Anne Thomas Manes are point-to-point integration, consolidated views, managing legacy assets, and reducing duplicative applications. All of which lead to more productive and efficient business.

With this overview of web services, I hope some of the potential confusion is cleared up a bit. True, there are a number of definitions, acronyms, and applications but at the end of the day web services are powerful tools that improve the communication of business processes and clarify business process models internally and externally. Web services essentially act as an interpreter for business processes and I hope that I have been somewhat of an interpreter of web services for you.

April 20, 2011

EE615 Brandon Morgado

Throughout the last decade, the term Service Oriented Architecture (SOA) has been thrown around IT departments and organizational meetings like crazy. As business fads usually do, it seems to have taken the entire industry by storm. However, the strange thing about this buzz word is that it actually makes a lot of sense.

Perhaps SOA won’t actually save the world, but chances are that applying this architecture to your organization will provide great benefits in the following ways.

-Loose Coupling Applies to Everything

"Things should be made as simple as possible, but no simpler." — Albert Einstein

In system design a loosely coupled system is one where each of its components has no knowledge of the definitions of other separate components (1). This is desirable in a service oriented architecture because it enables developers to focus on the real dependencies of their systems and avoid needless overhead and burdensome rewrites.

If a software system could be transformed into a restaurant we would see this principle illustrated. A waiter’s job is to take the customer’s order and relay it to the cooks. The waiter doesn’t need to know how or what the cooks do to the order. All they know is their specific task; take the order. By keeping the roles at their absolute minimum, the individual contributors within the system can perform efficiently, independently and extensibly. (2)

-The Simplicity of Services

In a Service Oriented Architecture, services are like the foundational building blocks. They make up the unique tasks and objectives and are represented in their simplest and most basic form.

These services hide the internal workings from outside intrusion. The system as a whole is much less susceptible to security issues as well as bugs stemming from overly complex design.

Services also present a simple interface to the rest of the organism. Each service may interact with the system as needed. Nothing stands to complicate the system or interfere with other processes.

-Increased Organizational Agility

As a system or organization transitions to a service oriented structure, the organization itself will become much more fluid. Each component, whether a developer or team of developers, has the freedom to worry only about their own objectives. Surely an organization that is truly built on SOA will take some time to develop, but once it is mature, it is easy to envision a company where upstream issues genuinely have little to no affect on the outcome of another portion of the company.

This results in the creation of services that are highly standardized and reusable. Practically speaking, no company will probably ever experience partitioning to this level, but the goal of a flexible and agile organization is definitely a worthy one. (4)

-Reduce IT Burden

In his book, What is SOA?, Thomas Erl states:
“Consistently applying service-orientation results in an IT enterprise with reduced waste and redundancy, reduced size and operational cost, and reduced overhead associated with its governance and evolution. Such an enterprise can benefit an organization through dramatic increases in efficiency and cost-effectiveness.”(4)

Simply rephrased: employers will spend less money and will experience less frustration in a Service Oriented Architecture. This makes sense, as problems will be easier to identify, and the flow of information will be free and organic. Transitioning to a new architecture is another story.

But if the transition is handled in a successful manner…

-It Makes Business Sense

It is not difficult to imagine a near future where most software will be delivered or consumed in the form of a service. (3) And why not? If the developers have the freedom and autonomy to create code based on loosely coupled dependencies, if the services of the product can be reduced to their simplest form, if the organization becomes more flexible while lifting most of the undue burden from the IT department, it’s not hard to see the value here.

By clearly explaining to the decision makers, the advantage of utilizing a Service Oriented Architecture, most organizations should readily see the advantages.

April 20, 2011

XML Process Definition Language (XPDL)

What is XPDL?

The XML Process Definition Language (XPDL) is a format standardized by the Workflow Management Coalition (WfMC) to interchange business process definitions between different workflow products, i.e. between different modeling tools and management suites. XPDL defines an XML schema for specifying the declarative part of workflow / business process.

In order to talk about XPDL one has to know about XML, which is a set of rules in machine-readable form. It is defined in the XML 1.0 Specification produced by W3C, and several other related specifications, all gratis open standards. One could go on and on about XML, but the purpose of this document is to talk on XPDL.

One of the reasons XPDL was designed was to exchange the process definition, both the graphics and the semantics of a workflow business process. XPDL is currently the best file format for exchange of BPMN diagrams; it has been designed specifically to store all aspects of a BPMN diagram. 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. This distinguishes XPDL from BPEL which focuses exclusively on the executable aspects of the process. BPEL does not contain elements to represent the graphical aspects of a process diagram.

XPDL also provides file format that supports all the different aspects of the BPMN process definition notation including the graphical descriptions of the diagrams, as well as executable properties used at run time. XML Process Definition Language is also extensible. In this aspect it allows all the different tools to store implementation specific information within the XPDL. In turn those values will preserved even when they are manipulated by tools that do not understand those extensions.

In conclusion, XPDL is used throughout many different products today to exchange process definitions. This makes XPDL very useful to the business process. As time continues, the use of XPDL will grow and become used more frequently. With XPDL, a product can write out a process definition with full fidelity, and another product can read it in and reproduce the same diagram that was sent.

April 20, 2011

What is MDA?

MDA is a software design approach for the development of software systems. It was launched by the Object Management Group (OMG) in 2001.
Effective enterprise software development in today’s world requires an approach to software architecture that helps architects evolve their solution in flexible ways.
I am curious on your thoughts on the viability of MDA and model driven development approach. OMG has created a conceptual framework that separates business-oriented decisions from platform decisions. OMG’s MDA provides vendor-neutral approach to system interoperability via established modeling standards: Unified Modeling Language (UML), Meta-Object Facility (MOF), XML Metadata Interchange (XMI), and Common Warehouse Meta-model (CWM). The modeling standards can be transformed to major open or proprietary platform including CORBA, J2EE, .NET and web-based platforms.
Currently lot of companies do “modeling” is in the form of programming abstractions embedded in the code. Any separate modeling of architectural designs lives on white boards, power point slides and to be frank in developer’s heads. This approach may be adequate for small teams; it makes it difficult to understand key characteristics of the system among the details of the implementation of the business logic. This becomes much more difficult to manage the evolution as their scale and complexity increases.
To achieve a model-centric approach the system model includes for ex: representation of persistent and non-persistent data, business logic, and presentation elements. If there is any integration with legacy data and services, the interfaces to those elements may also need to be modeled. MDA’s awareness is growing and it had a major impact on software engineering and I agree, it is critical to the success of every enterprise-scale solution.
As per OMG’s view of MDA it identifies four types of models. Computation Independent Model (CIM), Platform Independent Model (PIM), Platform Specific Model (PSM model and Implementation Specific Model (ISM). The models may be developed as a precursor to implementing the physical system or they may be derived from an existing system or a system in development as an aid to understanding its behavior.
CIM: is a model of a system that shows the system in the environment in which it will operate, and thus it helps in presenting exactly what the system is expected to do.

PIM: A platform independent model, a PIM, is built. It describes the system, but does not show details of its use of its platform.

PSM: PIM implemented on a specific platform.

PM: The architect will then choose a platform (or several) that enables implementation of the system with the desired architectural qualities.

Simplified MDA Framework
First, a Computational Independent Model (CIM), that is a model of the business rules of the system in focus and has no computer implementation details specification, is transformed into a Platform Independent Model (PIM), a high level model tied to computational concepts but not to a computer platform specific implementation. Second, the PIM is transformed into a Platform Specific Model (PSM), a model of a specific computer platform implementation. Third, the model with platform specific information (the PSM) is translated into code.

MDA Framework
The notion of “platform” is rather complex and highly context dependent. In some situations platform may be the operating system; in some situations it may be a technology infrastructure. In other words, one person’s PIM is another person’s PSM. For ex, a model may be a PIM with respect to choice of communication middleware if that model does not prescribe a particular choice of middleware technology. However, when you decide to use CORBA as middleware, the model is transformed to PSM.

This simplified example from IBM helped me understand the concept much better; I hope it would help you all.

In the above example, there are two classes Customer and Account. The model describes the class and its attributes but does not specify platform-specific choice. Three specific mappings, or transformations, defined to create the PSMs, together with the standards used to express these mappings.In my opinion the large companies are moving towards this architecture but it is still in the beginning stage.

April 20, 2011

Introduction

Business Process Execution Language (BPEL) is an XML-based web services standard designed to define the way in which business processes utilize web services. Written by developers from BEA Systems, IBM and Microsoft in 2002, it is a compilation of IBM’s Web Services Flow Language (WSFL) and Microsoft’s XLANG. [2] In April 2003, SAP and Siebel Systems signed on to create and submit BPEL4WS 1.1 to OASIS for standardization via the Web Services BPEL Technical Committee. In September 2004, the committee voted to change the name to WS-BPEL 2.0. [1]

Overview

Most modern business processes today utilize computer systems and applications to perform any number of everyday tasks. The development of Service-Oriented Architecture (SOA) frameworks have allowed for shared functionality of application modules regardless of their technical differences. For enterprises to exploit these applications, however, it is necessary to implement a language framework that enables information such as when to send messages, when to wait for messages and when to compensate for failed transactions. [2] Web service interactions can be described in two ways: executable and abstract business processes and BPEL is used to model the behavior of both. Executable business processes model actual behavior of a participant in a business interaction while abstract business processes are partially specified processes not intended to be executed. BPEL refers to programming in the large as an abstract process. Programming in the small, in contrast, deals with short-lived programmatic behavior, often executed as a single transaction and involving access to local logic and resources such as files, databases, etc. BPEL’s development came out of the notion that programming in the large and programming in the small required different types of languages. [1]

Scope

The scope of what BPEL includes is:

· The sequencing of process activities, especially Web service interactions.

· Correlation of messages and process instances.

· Recovery behavior in case of failures and exceptional conditions.

· Bilateral Web service-based relationships between process roles.[4]

Design Goals

There were ten original design goals associated with BPEL:

1. Define business processes that interact with external entities through web service operations defined using WSDL 1.1 and that manifest themselves as Web services defined using WSDL 1.1.

2. Define business processes using an XML-based language. Do not define a graphical representation of processes or provide any particular design methodology for processes.

3. Define a set of Web service orchestration concepts that are meant to be used by both the external (abstract) and internal (executable) views of a business process.

4. Provide both hierarchical and graph-like control regimes, and allow their use to be blended as seamlessly as possible. This should reduce the fragmentation of the process modeling space.

5. Provide data manipulation functions for the simple manipulation of data needed to define process data and control flow.

6. Support an identification mechanism for process instances that allows the definition of instance identifiers at the application message level.

7. Support the implicit creation and termination of process instances as the basic lifecycle mechanism. Advanced lifecycle operations such as “suspend” and “resume” may be added in future releases for enhanced lifecycle management.

8. Define a long-running transaction model that is based on proven techniques like compensation actions and scoping to support failure recovery for parts of long-running business processes.

9. Use Web Services as the model for process decomposition and assembly.

10. Build on Web services standards (approved and proposed) as much as possible in a composable and modular manner. [1]

The BPEL Language

BPEL is an orchestration language, not a choreography language. The primary difference is executability and control. An orchestration specifies an executable process that involves message exchanges with other systems, such that the message exchange sequences are controlled by the orchestration designer. A choreography language specifies a protocol for peer-to-peer interactions, defining, for example, the legal sequences of messages exchanged with the purpose of guaranteeing interoperability. Such a protocol is not directly executable, as it allows many different realizations. A choreography can be realized by writing an orchestration for each peer involved in it. The orchestration and the choreography distinctions are based on analogies; orchestration refers to the central control of the behavior of a distributed system, while choreography refers to a distributed system which operates according to rules but without centralized control. [1]

Benefits

The use of BPEL tools to access the functionality of web services offers a wide range of benefits, including:

· Improved access to data and services.

· Increased business agility.

· Reduced integration expense. [2]

Conclusion

In situations where private implementation aspects use platform-dependent functionality, the continuity of the basic conceptual model between abstract and executable processes in BPEL makes it possible to export and import processes or role templates while maintaining the intent and structure of the protocols. This is the most important prospect for the use of BPEL4WS for unlocking the potential of Web Services because it allows the development of tools and other technologies that greatly increase the level of automation and lower the cost in establishing cross-enterprise automated business processes. [3]

April 20, 2011

Effective enterprise software development in today’s world requires an approach to software architecture that helps architects evolve their solution in flexible ways.

I am curious on your thoughts on the viability of MDA and model driven development approach. OMG has created a conceptual framework that separates business-oriented decisions from platform decisions. OMG’s MDA provides vendor-neutral approach to system interoperability via established modeling standards: Unified Modeling Language (UML), Meta-Object Facility (MOF), XML Metadata Interchange (XMI), and Common Warehouse Meta-model (CWM). The modeling standards can be transformed to major open or proprietary platform including CORBA, J2EE, .NET and web-based platforms.

Currently lot of companies do “modeling” is in the form of programming abstractions embedded in the code. Any separate modeling of architectural designs lives on white boards, power point slides and to be frank in developer’s heads. This approach may be adequate for small teams; it makes it difficult to understand key characteristics of the system among the details of the implementation of the business logic. This becomes much more difficult to manage the evolution as their scale and complexity increases.

To achieve a model-centric approach the system model includes for ex: representation of persistent and non-persistent data, business logic, and presentation elements. If there is any integration with legacy data and services, the interfaces to those elements may also need to be modeled. MDA’s awareness is growing and it had a major impact on software engineering and I agree, it is critical to the success of every enterprise-scale solution.

As per OMG’s view of MDA it identifies four types of models. Computation Independent Model (CIM), Platform Independent Model (PIM), Platform Specific Model (PSM model and Implementation Specific Model (ISM). The models may be developed as a precursor to implementing the physical system or they may be derived from an existing system or a system in development as an aid to understanding its behavior.

CIM: is a model of a system that shows the system in the environment in which it will operate, and thus it helps in presenting exactly what the system is expected to do.

PIM: A platform independent model, a PIM, is built. It describes the system, but does not show details of its use of its platform.

PSM: PIM implemented on a specific platform.

PM: The architect will then choose a platform (or several) that enables implementation of the system with the desired architectural qualities.

Simplified MDA Framework

First, a Computational Independent Model (CIM), that is a model of the business rules of the system in focus and has no computer implementation details specification, is transformed into a Platform Independent Model (PIM), a high level model tied to computational concepts but not to a computer platform specific implementation. Second, the PIM is transformed into a Platform Specific Model (PSM), a model of a specific computer platform implementation. Third, the model with platform specific information (the PSM) is translated into code.

MDA Framework

The notion of “platform” is rather complex and highly context dependent. In some situations platform may be the operating system; in some situations it may be a technology infrastructure. In other words, one person’s PIM is another person’s PSM. For ex, a model may be a PIM with respect to choice of communication middleware if that model does not prescribe a particular choice of middleware technology. However, when you decide to use CORBA as middleware, the model is transformed to PSM.

This simplified example from IBM helped me understand the concept much better; I hope it would help you all.

In the above example, there are two classes Customer and Account. The model describes the class and its attributes but does not specify platform-specific choice. Three specific mappings, or transformations, defined to create the PSMs, together with the standards used to express these mappings.

In my opinion the large companies are moving towards this architecture but it is still in the beginning stage.

April 20, 2011

The direct origination of Event Driven Process Chain (EPC) cannot be pin point. However there are two commonly told histories of this type of process modeling. One is that EPC originates from an old essential system analysis technique. This analysis technique is known as Event Driven Process (EDP). EDPs include both unplanned and planned responses. These “systems are interactive; they act on things beyond their control and these eternal things act on them.”5 Due to its interactive nature and basis in EDP, EPCs “have become an established industry standard since a decade.” 1 The other, is that a professor by the name of Wihlem-August Scheer at the Institut für Wirtschaftsinformatik at the Universität des Saarlandes begin using the EPCs within the framework of ARIS.

THE REQUIREMENTS
Functions and events are the main requirements for Event Driven Process Chains. Functions happen because of events and functions cause events to happen. This flow of requirements is defined as a sequence of alternating events and functions. Other requirements included are organizational units, information, material or resource objects, logical connectors, logical relationships (branch vs. merger, fork vs. join, and OR), control flow, information flow, organization unit assignment and process path. Simple EPCs can be represented mathematically through the following:

A five-tuple (E, F, C, ℓ, A)
– E is a finite (non-empty) set of events,
– F is a finite (non-empty) set of functions,
– C is a finite set of connectors
– ℓ [X] C → {Ʌ, XOR, V} is a function which maps each connector onto a connector type.
– A • (ExF) [X] (FxE) [X] (ExC) [X] (CxE)[X] (FxC)[X] (CxF) [X] (CxC) is a set of arcs.2
This is not the only way EPCs are represented. Normally they are viewed graphically which look similar to flow charts.

THE TYPES
There are different types of Even Driven Process Chains. The most common are oEPCs and eEPCs. oEPCs are Object Oriented Event Driven Process Chains. They are used to achieve a more powerful description of a business process. This is accomplished by extending the base model of an EPC by incorporating “class function as outputs and functions’ pre-conditions.”4 eEPCs or Extended Event Driven Process Chains differs from a regular EPC because it focuses more on resources. However the downside to eEPC is that there are “no formal semantics or verifications tools.”3

THE TOOLS
Since Event Driven Process Chain is graphically similar to a flow chat or workflow there are plenty of tools available for production. In the beginning the main modeling tools used with EPCs were SAP R/3 and ARIS. The use of ARIS is still prominent with the ARIS Toolset, a free modeling told called ARIS Express. There is SemTalk which a Microsoft Visio add on. SemTalk has the ability to import EPCs that have already been created. Other tools include Communication Structured Analysis (CSA), ABC FlowCharter flow charts, ADONIS, Mavim Rules, Business Process Visual Architect and Bonapart. Some but not all of these tools may support the integration tool that was produced in 2002. EPML or Event Driven Process Chain Mark Up Language is unlike the other tools because it “provides standardized tags for the main EPC elements as well as some attributes such as “descriptions” and “positions.”1

When businesses use EPCs there can either be high leveled or detailed. The more detailed the EPC is the more EPCs one can have for any particular process. These detailed processes can show how one function can cause multiple events, or how one event can cause multiple functions. EPCs are relative easy to make and understand however due to it not being standardized those working on a process can make multiple ones at the same time that are correct, but look totally different. This is why there has been a movement to try and get EPML set as the industry standard to make this simple business process model even simpler. The cause-effect relationship of Event Driven Process Chain makes it easy for businesses to use it in modeling as a focal point for development of systems and with the definition of workflows. Not only can EPCs be used for modeling than can also be used in implementation of reengineering.

April 13, 2011

EE615 Trent Richardson

In the e-commerce business dance floor, the new digital jumps and jives demand real-time connections to many business steps and swings. No longer is it satisfactory to just shuffle data to update a single process overnight in batch. For example, a consumer enters a website to buy a new PC. The transaction must interact with the vendor CRM system, the vendor inventory (ERP) system, and a payment clearing service (authorize.net). The challenge is that all of the required left footed touchpoints are not necessarily listening to the same music. In order solve this tangled mess, web developers must teach their webs to tango.

In the past, these web dance steps were strictly defined and tightly coupled. The digital participants simply stepped into painted shoe prints on the cyber floor. This enabled high efficiency, but changes were difficult and expansion opportunities limited. If any system were changed, then all had to be upgraded or retested as the changes could have a wide impact. If the vendor needed to expand, it was difficult to engage other products from other vendors with system not under the local control. Our webs were being pushed to do more than 2-step, but the costs were too high to learn the more exotic dances.

The first solution was to establish “orchestration”. This is essentially a local and centrally defined model as to how the interaction will behave. Certainly, a conductor could enforce the right moves, right? The developers essentially enforced a certain structure for inputs, outputs, and error handling. This evolved into WS-BPEL (Business Process Execution Language) which can be defined as (3):

But this still didn’t create the beautiful ballet we needed. The primary difference between orchestration and choreography is executability and control. An orchestration specifies an executable process that involves message exchanges with other systems, such that the message exchange sequences are tightly controlled. In other words, orchestration refers to the central control of a distributed system while choreography refers to a distributed system which operates according to choreography rules but without centralized control. (1) The challenges to the old orchestration WS-BPEL dance are:

· It requires centralized execution

· The semantics are not globally formalized

· It is not scalable as dual control and connectivity are required

· It is rigid so it is non-collaborative

Originally marketed by Oracle, Web Services Choreography Descriptive Language is a specification by the W3C defining a XML-based business process modeling language that describes collaboration protocols of cooperating peer Web Services. The XML model defines a global scenario which is long-lived and stateful without a single point of control. Each service executes its own orchestration based upon its defined role and sequence. (2) The W3C Web Services Choreography Working Group, was closed on the 10th July 2009 leaving WS-CDL as a Candidate Recommendation which is intended to (3):

· Promote a common understanding between services

· Automatically guarantee conformance which reduces cost of ownership

· Ensure interoperability through behavior contracts

· Increase robustness and utilization

· Generate code skeletons

The key components of WS-CDL are:

· interactions

· Channels

· Participants

· Roles

· State

WS-CDL fits on top of the new technology stack as the key glue to bring it all together and make it work in the global context (4).

The design approach is different:

· BPEL: Design the baby steps first then put them together into a waltz.

· WS-CDL: Establish the flow of the tango first then distill it into simpler moves. (From WS-CDL we can generate BPEL/Java/C# logic for each participant.)

· Identifying & Coupling Collaborating Participants. In other words, the XML defines the participants, their roles, and how they relate together so there is no overlap or competition causing race conditions or deadlocks.

· Information Driven Collaborations. The key elements are the channel type, variable definitions, activities, and units of work. For example:

· Activities. These are interactions which enable collaborating participants to communicate and align information

The end purpose of Choreography is to combine actions with common behavioral characteristics, building a unit of work. In order to list all the binary relationships the dance is often expressed in complex PI calculus notations. The notation shows alternative patterns of behavior using workunits. This enables recovery backward by using exception handling and forward by finalizing already completed activities. But it has some drawbacks (5):

• Lack of separation between meta-model and syntax.

• Lack of direct support for certain categories of use cases.

• Lack of comprehensive formal grounding.

The bottom line is that Choreography complements Orchestration. Choreography is concerned with global, multi-party, peer-to-peer collaborations, between application components, distributed within or across an organizations trusted domain (5). WS-CDL can allow a developer to get their web into the global ball. However, its complex notation and broad scope may be too overwhelming for so many dancers that they just sit this one out and head for the bar.

History tells us during the Industrial Revolution (i.e., late 1700’s to early 1900’s), Monarchies were overwhelmed by capitalism; and eventually Socialism as capitalists worked their employees relentlessly in order to make money.
In 1891, Pope Leo XIII published Rerum Novarum, in which the Pope “commented critically on those whose economic policies had created slums and repressive economic and social pressure. The encyclical criticized both socialist and capitalist excesses and offered in their place classic Roman Catholic Christian guidance that Leo believed would lead to an improved social system. The "Rerum" was hailed worldwide by both Roman Catholics and non-Roman Catholics.”9

What are interesting are the significant events that contributed to JIT and what it has contributed towards.

In 1910 Henry Ford’s Manufacturing Strategy produced the Ford Production System which was noted for its Assembly Lines and Flow Lines. In the 1920’s, labor unions produced challenges; and annual changes to models did not fit the Ford Production System. Ford opposed war, but eventually his plants retooled for war production. What was significant is that in 1940, Ford’s Willow Run facility in San Diego produced B24 Bombers at an amazing one an hour (i.e., 18 a day) and by the end of the war had built 8,800. Some researchers say that Willow Run was the epitome of the Ford Production System which later was transformed by Toyota into Just in Time and Lean manufacturing.1

Toyota Motor Company began to incorporate the principals of the Ford Production System along with the Statistical Quality Control practices (e.g. Total Quality Management) of Ishikawa, Edward Deming and Joseph Duran.1

What eventually inspired the founders was their visit to Piggly Wiggly and observed the automatic drink dispenser. When a customer wants a drink, he gets one and another replaces it. However, on a subsequent visit to a Piggly Wiggly, the delegation was inspired by how the supermarket only reordered and restocked goods once they had been bought by customers. Toyota applied the lesson from Piggly Wiggly by reducing the amount of inventory they would hold only to a level that its employees would need for a small period of time, and then subsequently reorder. This would become the precursor of the Just-in-Time inventory system or sometimes referred to as the “Toyota Production System”.2

Major differences between Just-in-Time and the Ford Production System included the role of inventory, the importance of employees, product variety, quality circles, kanban cards and a “socio-technical system”3. As Toyota continued to perfect Just in Time from 1949 to 19751, other Japanese and American companies started to study and incorporate it.

Throughout the late 1900’s a new buzzword, “Lean Manufacturing”6, emerged. Lean meant manufacturing without waste. Lean Manufacturing would be the set of techniques that would identify and eliminate waste (e.g., Pull Scheduling, Six Sigma, TQM).

Benefits include:1

· Reduced setup time and operating costs.

· Higher quality.

· The flow of goods from warehouse to shelves improves.

“Kanban”4 is a scheduling system, which similarities to Scrum are:5

1. Lean and Agile

2. Use pull scheduling – Production determined by the “pull” from the demand. Movement only occurs when the work station needing materials requests it.

3. Focus on delivering releasable software early and often

4. Based on self organizing teams

5. Require breaking the work into pieces

6. Release plan is continually optimized.

· Employees with multiple skills are used more efficiently.

· Increased emphasis on supplier relationships.

On February 1, 1997 a fire destroyed “Aisin Seiki Co.’s Factory, which supplied brake fluid proportioning ("P") valves to Toyota’s 20 automobile plants. Toyota was producing 14,000 cars a day; and experts estimated that it would be weeks to recover. By the following Thursday, 36 suppliers, aided by more than 150 other subcontractors, had nearly 50 separate lines producing small batches of the brake valve. Toyota deployed 800 Engineers to assist in the recovery. This could have only occurred had it not been for the excellent ongoing supplier relationships that existed.”7,8

Problem that Toyota encountered during initial implementation

Line stopping (i.e., production line had to be slowed or stopped) was frequent (i.e., almost hourly during the first week) whenever there was a process or parts quality problem which surfaced on the production line. By the end of the first month, the rate had fallen to a few line stops per day. After six months, line stops had so little economic effect that Toyota installed an overhead pull-line, similar to a bus bell-pull, that let any worker on the line order a line stop for a process or quality problem. Even with this, line stops fell to a few per week.1

Conclusion

I was fascinated by the history and the events which contributed to Just-in-Time; but more importantly how all this contributed to “Lean Manufacturing”6 and some of the tools that are available that help eliminate waste (e.g., “Value Stream Mapping and Process Mapping)”6.

March 30, 2011

Corporate Governance

April 1, 2011

By Erica Brown

Have you ever wonder who is keeping large companies and organizations in check. Who is "Big Brother" to the entities that govern your life? The answer is Corporate Governance. In recent years, corporate governance has received increased attention because of high-profile scandals involving abuse of corporate power and, in some cases, alleged criminal activity by corporate officers. Well this will lead you to ask “What is corporate governance?” Corporate governance is a term that refers broadly to the rules, processes, or laws by which businesses are operated, regulated, and controlled. The term can refer to internal factors defined by the officers, stockholders or constitution of a corporation, as well as to external forces such as consumer groups, clients, and government regulations. (1)

Parties to corporate governance

The most influential parties involved in corporate governance include government agencies and authorities, stock exchanges, management(including the board of directors and its chair, the Chief Executive Officer or the equivalent, other executives and line management, shareholders and auditors). Other influential stakeholders may include lenders, suppliers, employees, creditors, customers and the community at large. (2)

Styles corporate governance

There is no one specific style of corporate governance that fits every company. According to TE Research, however, there are four broad corporate governance styles. These four different styles of governance are suited to companies in various stages of their development, from the early stage of a new business to the final stage of a mature cash cow. (3)

The Controlled Board

A controlled board is a board of directors that is under the control of the company’s management. This can be achieved either directly, by having the management serve on the board, or indirectly, by placing management allies on the board of directors. The controlled board is best suited to upstart companies in the early stages of development because the environment for a new company is highly dynamic. In order to quickly change to market demands, a company needs to have management that can make strategic decisions on the fly.

The Trusted Board

The trusted board is a style of corporate governance that puts mechanisms in place to increase shareholders’ trust of the board. These mechanisms can include annual elections to the board of directors or restrictions on the ability of the board to use a poison pill to ward off takeover bids. This style of corporate governance is best suited to companies in the financing stage of their development. This is due to the simple fact that investors are more willing to commit capital to companies whose boards they can trust to make decisions in shareholders’ best interests.

The Sovereign Board

The sovereign board is a style of corporate governance in which the board is free from the influence of either the management or shareholders. An independent board of directors is able to make decisions in the long-term best interest of the company. Companies with independent boards of directors have, on average, a higher return on equity and profit margin. This increase in profitability makes this style of governance best suited to companies in the production phase of development, where they will begin to turn profits.

The Influenced Board

The influenced board is a moderate style of governance in which the board of directors is influenced (but not controlled) by management but in which there is little influence from shareholders. Companies with an influenced board yield the highest dividends to shareholders because shareholders, while well-intentioned, do not always have the long-term interest of the firm in mind. The influenced board is the style of corporate governance most important aspect of the business is continuing to yield high dividends for as long as possible.

Conclusion

Corporate Governance is rules, processes, or laws by which businesses are operated, regulated, and controlled. This is in place to safeguard the stockholders and stakeholders within companies. The key players involved in creating the corporate governance include government agencies and authorities, stock exchanges, management, lenders, suppliers, employees, creditors, customers and the community at large. There is not one style that fits all companies. A company can decide on their style by
the setup of their corporation. I’m personally glad corporate governances are in place to cover the companies that impact my life.