By:  Elbert Jenkins II
(Repost from 2/1/2012)

Enterprise architecture (EA) is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements; principles and models that describe the enterprise’s future state and enable its evolution. At least, that’s how Wikipedia defines Enterprise Architecture. But what does it mean in layman’s terms? As it was once explained to me by one of my college roommates (who is now a teacher a private college in Atlanta), Enterprise Architecture is simply a “blueprint that explains the layout and operations of a business entity merge together via a specific type of technology”. And, just in case were wondering, the US Government defines it in such a way that it is considered a documented result of an examination of an entity rather than the process of examining a business entity. Either way you put it, EA plays a vital role in help determining the amount of success an entity may experience in future based upon how much thought was placed into the framing of the organization via initial business strategy.

The field of Enterprise Architecture started around 1987, with the publication in the IBM Systems Journal of an article called “A Framework for Information Systems, by J.A. Zachman. It was in this publication that Zachman laid out the challenges and the vision of enterprise architectures that would guide the field for the next 20 years. Over time as the desire to implement the process became more integrated within the standard business model, the framework became more revised and designed to merge all aspects of a business together into four separate yet closely related categories.

· Business Architecture – Normally deals with the normal day to day business processes

· Technology Architecture – Links the Business, Data and Application Architectures together with interoperable technology platforms

· Information Architecture – Consists of the databases and data models used by all the participating employees to help implement and develop all of the strategies and policies within the organization

· Application Architecture – Joins the business and data architectures together to support the work activities of the business process.

Once all of the data is collected and plugged into the model a number of gains are typically realized within a very short time frame after the play is put into operation. Changes like increased efficiency within the Information Technology department due to improved methods and tools that resulted from the detailed outline. From a Developer’s perspective, increased productivity without omitting creativity would surely lead to increased confidence and a higher quality product at the end of the day. With these types of benefits, it’s easy to understand how EA has grown into such a large desirable field. As the need increases so does the qualifications to obtain the role of Enterprise Architect. In the beginning any well versed IT professional would have a shot at such a position but due to the broadening of the application and use of the data and activities surround EA the position has evolved into one that requires one to have more than just a solid foundation in technology, but also have a myriad of qualities that complement the business aspects of an organization.

CITED WORKS

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

http://www.tdan.com/view-articles/5041/

http://www.cio.com/article/101401/The_Rising_Importance_of_the_Enterprise_Architect

Advertisements

Business Process Execution Language (BPEL)
Business Process Execution Language is based on XML and defines the behavior of a Business Process in terms of the interactions between the Process and external entities. This interaction occurs through Web Services, with publicly exposed interfaces represented by the Web Services Description Language (WSDL). Wikipedia describes it as language which is not choreographed but a management of complex computer systems using an automated arrangement to provide a service. According to some there is an issue with the language. BPEL originated as XLANG developed by Microsoft and WSFL was developed by IBM, the two do not mix well.
Within the enterprise, BPEL is used to:
– standardize enterprise application integration
– extend the integration to previously isolated systems
• Between enterprises, BPEL enables:
– Easier and more effective integration with business partners
• BPEL stimulates enterprises to further define their business processes
– leads to business process optimization, reengineering,
– Definitions of business processes described in BPEL do not affect existing systems
• With increases in the use of Web services, the importance of BPEL has increased as well
BPEL supports two different ways of describing business
Processes that support orchestration and choreography: Executable processes
– specify exact details of business processes
– follow the orchestration paradigm
– can be executed by an orchestration engine
Abstract business protocols
– specify public message exchange between parties only
– Do not include the internal details of process flows are not executable
A BPEL process specifies the exact order in which participating Web services should be invoked
– Sequentially or in parallel
Can express conditional behaviors
– For example, an invocation of a Web service can depend on the value of a previous invocation.
Can also construct loops, declare variables, copy and assign values, define fault handlers, and so on.
By combining all these constructs, you can define complex business processes in an algorithmic manner.
So when you go to the web and decide to shop online at Amazon.com, Wal-Mart.com and or booking a flight somewhere, remember the interfaces and look at all the menus and the buttons that perform this amazing process, you can be rest assured BPEL is being used.

Dan Prabhu

References:

http://en.wikipedia.org/wiki/BPEL
http://www.sparxsystems.com.au/products/mdg/tech/bpel/bpel.html
http://hercules.infotech.monash.edu.au/~shonali/FIT5030/BPEL%20and%20Composition/WSBPEL.pdf
http://ro.uow.edu.au/cgi/viewcontent.cgi?article=1435&context=infopapers&sei-redir=1&referer=http%3A%2F%2Fwww.google.com.au%2Furl%3Fsa%3Dt%26rct%3Dj%26q%3Dbusiness%2520process%2520execution%2520language%26source%3Dweb%26cd%3D9%26ved%3D0CIIBEBYwCA%26url%3Dhttp%253A%252F%252Fro.uow.edu.au%252Fcgi%252Fviewcontent.cgi%253Farticle%253D1435%2526context%253Dinfopapers%26ei%3DiRqRT_OpF–ZmQX81sXqAQ%26usg%3DAFQjCNHhDMYqsAyg4pp3cBPPLamJg7NsTw%26cad%3Drja#search=%22business%20process%20execution%20language%22

Web Services

April 20, 2012

Web Services – The Foundation

After selecting “Web Services” as my Blog Assignment in the EGR 644 – Business Process Modeling Course at the University of Alabama at Birmingham, I first thought it would be about what services the World Wide Web consists of. When I searched for this subject on the Internet, Wikipedia mentions that “A Web service is a method of communication between two electronic devices over the web (internet). – The W3C (World Wide Web Consortium) defines a ‘Web service" as "a software system designed to support interoperable machine-to-machine interaction over a network’.” In regards to the Internet, Wikipedia stated “The history of the Internet began with the development of computers in the 1950s. This began with point-to-point communication between mainframe computers and terminals, expanded to point-to-point connections between computers and then early research into packet switching.” In this respect, communication between computers has been evolving for approximately sixty years.

Looking deeper on the internet regarding Web Services, w3schools.com described how Web Services works by stating “The basic Web services platform is XML (Extensible Markup Language) + HTTP (Hypertext Transfer Protocol). XML provides a language which can be used between different platforms and programming languages and still express complex messages and functions. The HTTP protocol is the most used Internet protocol.” W3schools.com also mentioned the platforms of Web Services as: “SOAP (Simple Object Access Protocol), UDDI (Universal Description, Discovery and Integration), and WSDL (Web Services Description Language).

To elaborate on the platforms of Web Services, SOAP is “an XML-based protocol to let applications exchange information over HTTP” according to www.w3schools.com. Simply put, SOAP is a method or protocol for accessing a Web Service. SOAP is a format to send messages, it is a communication protocol designed to communicate via or through the Internet, it allows ways to get around firewalls, and it is language and platform independent. SOAP is a standard by World Wide Web Consortium (W3C), and is based on XML.

Another Web Service platform is WSDL or Web Services Description Language, which is also based on XML and a standard by W3C as well. WSDL is utilized to describe and locate Web Services. Lastly, UDDI is a platform where companies can search and register for Web services like a directory or where information is stored. UDDI communicates through SOAP, it is described by WSDL, and is “built into the Microsoft.NET platform” according to w3schools.com. One important benefit of UDDI according to w3schools.com is “Before UDDI, there was no Internet standard for businesses to reach their customers and partners with information about their products and services. Nor was there a method of how to integrate into each other’s systems and processes.”

One of the most amazing things about Web service is that “any application can have a Web Service component” and “Web Services can be created regardless of programming language”. Therefore, mainframe, mid-range, and client server languages can be used for Web services, and communicate with each other.

W3schools.com was very informative, and gave the following description for HTML. “HTML is a language for describing web pages. HTML stands for Hyper Text Markup Language. HTML is not a programming language, it is a markup language. A markup language is a set of markup tags. HTML uses markup tags to describe web pages.” Also, it stated that a HTML document is a Web Page which describes web pages, contains HTML tags, plain text, and “The purpose of a web browser (like Internet Explorer or Firefox) is to read HTML documents and display them as web pages. The browser does not display the HTML tags, but uses the tags to interpret the content of the page.”

This information is a foundation of Web Services. There are new developments in technology continuously improving how computers communicate with each other over the internet and into the Cloud. According to Webservices.com “XML is well suited and widely used for data transfer. For example, SOAP messaging in Web services is based on XML (well, technically speaking SOAP 1.2 is based on XML Infoset). With SOAP messaging becoming more widespread as adoption grows within organisations, the challenge of how to send non-text based data along with your message is becoming more important. Many organisations now have “image and workflow” type applications for example, where a jpeg (say a scanned insurance claim) needs to be sent between applications.”

I’m sure it will be quite interesting to view Web Services next year just to see what developments or quantum leaps this technology brings forth.

Christopher Robinson

Works Cited:

Wikipedia. “Web Service”. http://en.wikipedia.org/wiki/Web_service

Wikipedia. “History of the Internet”. http://en.wikipedia.org/wiki/History_of_the_Internet

W3Scools.com “Web services” http://www.w3schools.com/webservices/wsintro.asp

Webservices.org http://webservices.org/index.php/weblog/website_editor/becoming_attached_to_soap

WS-CDL, stands for Web Services Choreography Description Language, which is an XML-based language that describes peer-to-peer collaborations. WS-CDL is a language for specifying peer-to-peer protocols where no party is master over the other and each party will remain autonomous. Each party (peer) sends messages and WS-CDL choreographs how the Web Services are consumed, making use of their functionality to accomplish a common business goal. Standards for service composition cover three different, although overlapping, viewpoints: Choreography, Behavioral Interface, and Orchestration. This blog will focus on choreography. One major difference I would like to point out about orchestration is that orchestration focuses on the behavior of a single participation.

Choreography is concerned with global, multi-party, peer-to-pear collaborations interoperable between any type of application components, regardless of the supporting platform or programming model used, being distributed within or across an organization’s trusted domain. Choreography does not depend on a centralized controller. It was initially designed by Oracle and then submitted into the W3C Choreography in September 2003.

In real-world scenarios, corporate entities often do not allow control of their business processes to their integration partners. Choreography is a way by which the rules of participation with a collaboration can be clearly defined and agreed to. Each entity may then implement its portion of the choreography as determined by the common or global view. It is the intent of WS-CDL is to make each common view expressed easy to determine.

The figure below demonstrates a possible usage of WS-CDL

In Figure above, Company A and Company B wish 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. They then generate a WS-CDL based representation. In this example, a choreography specifies the interactions between services across business entities ensuring interoperability, while leaving actual implementation decisions in the hands of each individual company:

  • Company "A" relies on a WS-BPEL [WSBPEL] solution to implement its own part of the choreography
  • Company "B", having greater legacy driven integration needs, relies on a J2EE [J2EE] solution incorporating Java and Enterprise Java Bean Components or a .NET [C#S] solution incorporating C# to implement its own part of the choreography

Similarly, a choreography can specify the interoperability and interactions between services within one business entity.1

The goals of the WS-CDL specification are to permit:

1. Reusability

2. Cooperation

3. Multi-Party Collaboration

4. Semantics

5. Composability

6. Modularity

7. Information Driven Collaboration

8. Information Alignment

9. Exception Handling

10. Transactionality

11. Specification Composability

The specification of WS-CDL does depend on some specifications of other languages, a couple in particular are XML 1.0 and support for including and referencing service definitions given in WSDL 2.0 is a normative part of the WS-CDL specification. WS-CDL is not an “executable business process description language” or an implementation language.

Choreography combines actions with common behavioral characteristics, forming a collaboration unit of work. The WS-CDL model allows scalable modeling by: building smaller choreographies first, combines them together to form a larger choreography, then do participant projections to get a participant’s viewpoint.

The benefits of Web Services Choreography includes:

1. Promoting a common understanding between WS participants

2. Automatically guarantee conformance

3. Ensure interoperability.

4. Increase robustness

5. Generate code skeletons

6. More robust Web Services to be constructed

7. Enable more effective interoperability of Web Services through behavioral multi-party contracts

Which are choreography descriptions

8. Reduce the cost of implementing Web Services by ensuring conformance to expected behavior

9. Increase the utility of Web Services, as they will be able to be shown to meet contractual behavior.

-Larry Robinson (EGR644, Spring 2012)

References

1. http://www.w3.org/TR/ws-cdl-10/#Purpose-of-WS-CDL

2. http://www.rimtengg.com/coit2007/proceedings/pdfs/49.pdf

3. http://www.bptrends.com/publicationfiles/03-05%20WP%20WS-CDL%20Barros%20et%20al.pdf

4. http://lists.w3.org/Archives/Public/www-archive/2004Jun/att-0008/WS-CDL-April2004.pdf

The Web Services Choreography Description Language (WS-CDL) is a W3C candidate recommendation. It is a language for describing how peer-to-peer participants’ collaborate.1 In this shared environment, the computer network can act as a client or server for the other computers in the network. This allows shared access to files and devices connect to host computers, without the need for a central server. Each network type needs all computers in the network to use the same or a compatible program to connect to each other. Audio, data, video or anything in digital format can be shared. Further in this article, a discussion of WS-CDL and its impact on business processes will take place.

Activities that involve different organizations or independent processes are engaged in a collaborative fashion to achieve a common business goal, such as order fulfillment or data sharing. For the collaboration to work properly, the rules of assignation between all the interacting participants must be provided. The WS-CDL is aimed at being able to describe collaborations between any type of participant, regardless of the supporting platform or programming model used by the implementation of the hosting environment.

Using the WS-CDL, a contract containing a "global" definition of the common ordering conditions and constraints under which messages are exchanged, is produced that describes, from a global viewpoint, the common and complementary observable behavior of all the participants involved. Each participant can then use the global definition to build and test solutions that conform to it. The global specification is in turn realized by a combination of the consequential local systems, on the basis of appropriate infrastructure support.

In real-world scenarios, companies are often unwilling to delegate control of their business processes to their integration partners. WS-CDL offers a means by which the rules of participation within collaboration can be clearly defined and agreed to, collectively. Each part may then implement its portion of the choreography as determined by the common agreed view.

The figure below demonstrates a possible usage of WS-CDL.

Company A Company B

In Figure 1, 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. They then generate a WS-CDL based representation. 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:

  • Company "A" relies on a WS-BPEL3 solution to implement its own part of the choreography
  • Company "B", having greater legacy driven integration needs, relies on a J2EE4 solution incorporating Java and Enterprise Java Bean Components or a .NET5 solution incorporating C# to implement its own part of the choreography2

More specifically, the goals of the WS-CDL specification are to permit: Reusability, Cooperation, Multiple party, Ability to compose, information alignment, transactional and Information Driven collaboration of shared resources.

This type of peer-to peer participation collaboration is a method used with six sigma and lean initiatives throughout many industries. WS-CDL is enabling companies to save money, time and eliminate bottlenecks in their business processes. What do I mean by bottlenecks? These are simply the limiting steps in a process. Bottlenecks destroy productivity. Bottlenecks are the perfect example of a small change that can have a huge impact on your productivity. If an activity takes four hours, but three are spent on just one step, speeding up that step could make a system 7 times more productive. With the use of WS-CDL, each trust entity on a network can see each other’s files, share information and greatly decrease data loss. Over-all WS-CDL can make a corporation run more efficiently and is increasingly utilized because of its great benefits.

Ronique Carter

EVENT DRIVEN PROCESS CHAIN

An Event Driven Process Chain is used in many industries to model business process work flows, ERP implementation, and business process improvement. It is more commonly known as an EPC. This process was developed in the early 90’s my Professor Scheer at the University of Sarrland. Many industries utilize this process thus making it an industry-wide standing. The elements of an EPC are activities (functions), events, and rules. These rules are denoted by logical operators such as AND, OR, and XOR. It is crucial to note that multiple functions can follow each event or multiple events can follow each function. There must be rules between those events though. In addition, these rules are represented by graphical connectors. Presently there are a number of tools that are available for creating EPC diagrams. They are ARIS Toolset of IDS Scheer AG, ADONIS of BOC Group, Mavim Rules of Mavim BV, Business Process Visual ARCHITECT of Visual Paradigm, Visio of Microsoft Corporation, Semtalk of Semation GmbH, or Bonapart by Pikos GmbH. Simply put, an EPC is an ordered graph of events and functions. One advantage of using the EPC is its easy-to-understand notation. This in turn makes the EPC one of the most widely acceptable techniques to denote business processes. In my research, I noticed some articles about EPCs refer to them as ordered graphs. These are actually directed graphs without any node ordering. EPCs most closely resemble UML activity diagrams. One setback of the EPC is that the execution behavior of nodes within an EPC sometimes depends on the state of other parts of the EPC, which may be ‘far’ away. There are ten elements of an event-driven process chain. The elements of an event-driven process chain are events, functions, organization unit, resource object, logical connector, logical relationships, control flow, information flow, organization unit assignment, and process paths. Events are elements in the event driven process chain that are critical to the formation of the model. Events are represented by hexagons. In general, the event driven-process diagram must start with an event an end with an event. Events always point out what a business process results in. On the other hand, functions are more active elements. They take on the role of tasks/processes within the company. Functions are represented as rounded rectangles. Organization units are vital within event driven process chains. These units identify which individual(s) are responsible for various functions. Logical connectors are important relationship connectors. They control the flow of events. These connectors are very crucial because they are able to split the flow of control from one flow to multiple flows and to reverse flow from two or more to one flow. The next most important factor within event driven process chains are logical relationships. The three kinds of logical relationships are Fork/Join, OR, and Branch/Merge. A branch in the EPC is represented by an opening XOR, while closing of the XOR connectors are symbolized by a merge. Forks are represented by an opening. On the other hand, a join is represented as a closing in addition to connectors. The most crucial elements of EPCs are the functions, events, and connectors. These form the foundations for the entire EPC diagram. Throughout my research, I have noted benefits of this model. Although it is more complex than other models, it was formulated to deal with simple to complex business processes. Because business processes have varying conditions, it needs a business flow model like the event driven process chain to represent elements in a simplistic manner. The EPC ensures that all aspects are indicated while making it easy to recognize any inefficiencies and/or duplication of actions.

BY: JAMILAH VESTER

1. http://www.sts.tu-harburg.de/pw-and-m-theses/2001/Ferd01.pdf
2. http://www.valuestreamguru.com/?p=214
3. http://www.slideshare.net/ariscommunity/what-is-an-eventdriven-process-chain

Event Process Chain

April 19, 2012

An Event Process Chain is a type of flowchart used for business process modeling. Event Driven Process Chain can also be used for configuring an enterprise resource planning and business process improvement. Businesses are using EPC diagrams to lay out business process work flows. EPC diagrams use symbols of several kinds to show the control flow structure of a business structure.
The EPC method was developed within the framework of ARIS, constructed by Professor Wilhelm-August Scheer. (Architecture of Integrated Information Systems), is an approach to enterprise modeling. ARIS offers methods for analyzing processes and taking a holistic view of process design, management, work flow, and application processing. As such it forms the core technique for modeling in ARIS, which serves to link to different views in the so-called control view.
The EPC publication quotes “An EPC is an ordered graph of events and functions. It provides various connectors that allow alternative and parallel execution of processes. In addition to it is specified by the usages of logical operators. A major strength of EPC is said to be its simplicity and easy to understand the process. This makes EPC a widely acceptable technique to denote business processes.” Events are passive elements in EPC. They describe under what circumstances a function or process works. Examples of events are “requirement captured” and “material on stock.”On the EPC graph an event is represented as a hexagon. The diagram must start with an event and end with a event.
Functions are active elements in EPC. They model the task s or activities within the company. Functions describe transformations from an initial state to a resulting state. Examples of functions are “capture requirement” and “check material on stock.” On the EPC diagram a function is represented by a rounded rectangle.
Organization units determine which person or organization within the structure of an enterprise is responsible for a specific function. Examples are “sales manager and sales department.” Organization is represented by an ellipse with a vertical line.
In the EPC, the information, material, or resource object portray objects in the real world. Examples are “material” and “order.” The object is represented as a rectangle.
In the EPC the logical relationships between elements in the control flow is events and functions are described by logical connectors. There are three kinds of logical relationships defined in EPC: 1.) Branch and merge correspond to making decision of which path to choose among several control flows. The branch activates exactly only one of the outgoing control flows and deactivates the others. A branch in the EPC is represented by an opening XOR, whereas a merge is represented as a closing XOR connectors.
2.) Fork and join correspond to activating all paths in the control flow concurrently. A fork has one incoming control flow and two or more outgoing control flows. When the condition is completed, a fork activates all of the outgoing control flows in parallel. A join may have two or more incoming control flows and one outgoing control flow. A join locks into all activated incoming control flows. A fork in the EPC is represented by an opening “AND”, and join is represented as a closing “AND” connectors.
3.) An ‘OR’ relationship corresponds to activating one or more paths among control flows. When at least one of the incoming control flows is activated, the closing ‘OR’ connector will pass the control to the next element after it.
A control flow connects events with functions, process paths, or logical connectors creating a sequence and logical between them. A control flow is represented as a dashed arrow.
Information flows show the connection between functions and input or output data, upon which the function reads changes or writes. Organization unit assignments show the connection between an organization unit and the function it is responsible for. Process paths serve as navigation aid in the EPC.
Event-driven Process Chains are best used in place of any other process diagram if the process begins with a specific event. This event sets the situation for the rest of the process. It is not just a process, but a process completed under very specific circumstances. • Start the diagram. An Event-driven Process Chain begins with an event, symbolized by a hexagon. Add an event to the top of the page. • Add a function. Functions are represented by rounded rectangles and represent an action or process taken that leads from one state to the next.
• Input and output. Input and output from outside or inside sources can also trigger certain functions or processes and are symbolized by rounded rectangles with a vertical line through it.
• Add information. Information or materials are represented by rectangles. • Make connections. Use arrows to connect between two different nodes. You may also branch off if one node may lead to one of two others. You may also use a fork or join two different process flows together, in other words, two nodes lead to the same conclusion.
• Finish. In an Event-driven Process Chain must finish with an event. To best sum up event driven process given by Dr. Mani Chandy, is one is you need to continuously acquire data and there are various ways in which this is done. Some of it is done through sensors. Companies and enterprises all over are finding that they have a lot more sensors in their manufacturing and logistics and they’re generating a lot more statistics than they’re actually using. So number one is the acquisition of data, and two is the fusion of data – correlating data from multiple sources of information. Once you fuse the data you have an idea of what the world is like outside and how it’s changed. And so the third part is to plan. You want to plan a response to this change. And the fourth part is to execute the response. The combination of all four parts is what makes event processing very useful to the business.

Work Cited: Wikipedia, Visipedia, and Dr. Mani Chandy author of Event Processing: Designing IT Systems for Agile Companies
Event driven process.docx

Model Driven Architecture

April 18, 2012

Definition

In recent months many organizations have begun to focus attention on Model Driven Architecture (MDA) as an approach to application design and implementation. This is a very positive development for several reasons. MDA encourages efficient use of system models in the software development process, and it supports reuse of best practices when creating families of systems. As defined by the Object Management Group (OMG), MDA is a way to organize and manage enterprise architectures supported by automated tools and services for both defining the models and facilitating transformations between different model types. [3]

Image source OMG.org/MDA/

The MDA seperates business and application logic from the underlying platform and technology being used. It was chosen to be the offical base architecture for OMG specifications by an unanimous vote in 2001. Since modeling is at the heart of the MDA, let’s take a look at how modeling is used in the enerprise. In software development, modeling has been a rich tradition since the earlyest days of programming. Most recent changes have been focused around the notations and tools that system architects and develpers use to a map models to programming language code that can be complied for a particular operating system platform. A complete MDA implementation will include a definite platform-independent model (PIM) to achieve modling without being tied to a specific platform, then also consist of one or more platform-specific models (PSM) to complete the implementation.

Image source IBM.com

The principles of MDA

Four principles underlie the OMG’s view of MDA:

  • Models expressed in a well-defined notation are a cornerstone to understanding systems for enterprise-scale solutions.
  • The building of systems can be organized around a set of models by imposing a series of transformations between models, organized into an architectural framework of layers and transformations.
  • A formal underpinning for describing models in a set of metamodels facilitates meaningful integration and transformation among models, and is the basis for automation through tools.
  • Acceptance and broad adoption of this model-based approach requires industry standards to provide openness to consumers, and foster competition among vendors.[2]

MDA tools

There are two types of models used, initial models and derived models. Initial models are created manually by people, while derived models are the product of an automated program. For example, analysts may create a UML initial model, then a Java model can be automatically derived from the UML model using a model transformation process.

There are many different kinds of tools used when working in an MDA approach. They are: creation, analysis, transformation, composition, test, simulation, metadata management, and reverse engineering.

A tool may be specialized or more general and comprise many types of tools in one. For example, a creation tools may include transformation and test functions.

Current Concerns

Although MDA was conceived as an approach for achieving (technical) platform independence, current MDA vendors have been reluctant to engineer their MDA toolsets to be interoperable. Such an outcome could result in vendor lock-in for those pursuing an MDA approach.[1]

The OMG hasn’t always had a perfect track record for the architectures they sponsor. They introduced and sponsored the CORBA standard which failed adaptation in the market.

The MDA is young in its development, as the definition itself is still evolving. In a narrow sense, it is about different abstract models of a system, and well-defined model transformations among them. In a broad sense, it is about models at different levels of abstraction that serve as the basis for software architectures.[2]

While many companies seem to be involved with the MDA, they have drawn some negative conclusions about some of the important standards of the architecture. For example, because Microsoft is staying away from Meta Object Facility (MOF), they will not be treading exactly along the path of the MDA.[4]

-Dustin Corey (EGR644, Spring 2012)

References

[1]
http://en.wikipedia.org/wiki/Model-driven_architecture

[2]
http://www.ibm.com/developerworks/rational/library/3100.html

[3]
http://www.omg.org/mda/

[4]
http://martinfowler.com/bliki/ModelDrivenArchitecture.html

Corproate Governance 2012

April 18, 2012

Corporate Governance…2012
by noble1119

Are corporations operating more efficiently or ‘better’ than the pre Sarbanes Oxley Act era? Before I even begin to delve into this, we all need to have a clear understanding of the subject. What is corporate governance? According to the ‘Essentials of Corporate Governance’ by Sanjay Anand, “Corporate governance is a broad and complex concept that incorporates almost every aspect of corporate life, compounded by the fact that it has evolved to encompass ethical duties to employees, environmental activity, political involvement and employment practices”. (1) However, according to the Cadbury Committee (1992), simply put, corporate governance is "the system by which companies are directed and controlled”(2).

The corporate debacles of the early 2000’s brought into question the accounting practices and activities of many corporations throughout the United States and were a factor in the creation of the Sarbanes–Oxley Act (SOX) of 2002. SOX, a US federal law, set new or enhanced standards for all U.S. public company boards, management and public accounting firms.

SOX provided the basis for many revised, restructured and reengineered corporate governance strategies and policies in hundreds of organizations. Companies were being ‘forced’ to either take hard look at the structure of their organizations, the makeup of the board members, financial accounting systems and employee responsibilities and then make necessary changes or face fines in the millions of dollars and/or jail time.

Corporations continue to implement changes to their corporate governance practices and policies to increase director accountability. Much attention is being given to the board members, such as past performance, conflicts of interest, and their ability to do the job. Directors are required to work within the confines of the law and are responsible for the interests of the shareholders. But what about the interests of the employees? It could be said that by looking after the interests of the shareholders, that it would include the interests of the employees. IN MY OPINION, that thought process didn’t seem to hold true when we look at the horror the employees at Enron and HealthSouth experienced when they no longer had their retirement funds.
According to an article by Yvan-Claude J. Pierre and Jason M. Barr (3/2/2012), companies may need to address five governance issues in 2012. They cite: Rotation of committee members, board diversity, independent chairmanship, lead independent director and auditor rotation. (3) As you can see, most of these issues center on the board of directors.

In considering the rotation of the committee members, corporations might also weigh the value of that rotation against the benefits of continuity. Pierre and Barr states that “if it would balance director experience and interest, and aid the board in carrying out its fiduciary duties of the shareholders, then maybe a formal rotation policy may be in the a company’s best interest.”

The Securities and Exchange Commission “requires that companies discuss their board diversity policies in its proxy statements, disclose how they select nominating committees, how they are implemented, and how they measure their effectiveness.” However, the SEC does not define ‘diversity’. They leave that up to each company to disclose.

More on Pierre and Barr’s discussion on their view of the five corporate governance issues of 2012 can be found in the article: United States: Corporate Governance Best Practices – 2012 Proxy Season, 07 March 2012.

In light of all of the regulatory and compliance policies, corporations are taking on the challenge to improve current business processes by applying well thought out internal controls. Automating compliance initiatives allows corporations to lower the hard and soft cost of compliance.

Consider the company where you are currently employed. Have you had an opportunity to look over their corporate governance policies and guidelines? What about their structure? How diverse is the committee? How informed are you about the business, holdings, transactions? When was the last time your company made revisions to its governance policies? Have those changes directly impacted you as an employee? When was the last time that you really looked over the proxy or financial statements of the company?

Resources:

1. Anand, Sanjay. Essentials of Corporate Governance. Corporate Governance; 2008 Good Corporate Governance, Chapter 6

2. http://en.wikipedia.org/wiki/Corporate_Governance

3. United States: Corporate Governance Best Practices – 2012 Proxy Season

07 March 2012

Article by Yvan-Claude J. Pierre and Jason M. Barr

http://www.mondaq.com/unitedstates/x/167720/Corporate+Governance/Corporate+Governance+Best+Practices+2012+Proxy+Season

BPEL, stands for Business Process Execution Language, and comes from a standards consortium of BEA Systems (acquired by Oracle Inc. in 2008), IBM and Microsoft. BPEL was first conceived in July 2002 with the release of BPEL4WS (BPEL for Web Service) 1.0 specifications. BPEL combines and replaces IBM’s Web Services Flow Language (WSFL) and Microsoft’s XLANG specification. It provides an orchestration engine for describing exchanges of information internally or externally. It deals explicitly with functional aspects of business processes like control flow (loop, branch, parallel), asynchronous conversations and correlation, long running nested units of work and compensation (1). In May 2003, other contributors from SAP and Siebel Systems joined and BPEL4WS version 1.1 was released. In April 2007, WS-BPEL TC (Web Service BPEL Technical committee) from OASIS (Organization for the Advancement of Structured Information Standards, a not-for-profit consortium) approved version 2.0.

BPEL is a XML (eXtensible Markup Language) based workflow definition language which allows businesses to describe inter or intra enterprise business processes that are connected via web services. It is a markup language for composing a set of discrete services into an end-to-end process flow, radically reducing the cost and complexity of process integration initiatives. It is a rich support for asynchronous interactions, parallel processing and exception management. The older technology like workflow can be replaced by BPEL, in organizations which use web services extensively.

BPEL will emerge as the leading industry standard for Web service orchestration and coordination of business processes (2). BPEL is the future of the integration space because the value is so much higher when you provide not only a way to integrate applications, but also a way to create services from them and put them into business processes (3).

BPEL is used to model the behavior of both executable and abstract processes. The scope includes:

· Sequencing of process activities, mainly Web service interactions.

· Correlation of messages and process instances

· Recovery behavior in case of exception conditions or failures

· Bilateral Web Service based relationships between process roles (4)

Some of the advantages of using BPEL are:

· Provides industry standard language for expressing business processes

· Leverage a common skill set and language

· Abstracts business logic and responsibility

· Designed to fit naturally into the Web services stack

· Expressed entirely in XML

· Uses and extends WSDL 1.1

· Portable across platform and vendor

· Uses XML Schema 1.0 type definitions for the data model

· Interoperable between interacting processes (5)

In recent years there has been the development of Service-Oriented Architecture (SOA), a framework that allows application modules to share functionality with each other, regardless of the technical differences between them. Through the use of these services it becomes possible for process designers to make use of applications both within and without the enterprise that would otherwise have remained unutilized, allowing them to design faster, more efficient processes.

For enterprises to exploit these applications, however, it is necessary to implement a language framework that enables programming in the large – that is, programming logic that encodes information such as when to send messages, when to wait for messages and when to compensate for failed transactions. This language allows process designers to write code that orchestrates the use of application modules such as web services in business processes.

The BPEL architecture allows process designers to perform these tasks using three tools: a BPEL Designer, a BPEL Engine and a process flow template.

BPEL Designer: The BPEL Designer is a graphical user interface (GUI) used to design a business process. A business process designer inputs the details of the process flow, including details of any web services required during the process. Once the process flow has been defined the BPEL designer generates a process flow template written in the BEPL language.

BPEL Engine: The BPEL Engine (such as IBM’s Web Sphere Process Server) is a tool used to execute the instruction provided by a process flow template. In addition to invoking the required web services the BPEL Engine also performs a number of related tasks such as error handling, data mapping, security, etc.

Process Flow Template: The process flow template is a set of instructions written in the BPEL standard that outlines the logic flow of a process. The process flow template generated by a BPEL designer, acts as an instructional roadmap for the BPEL engine.

Some of the BPEL engines and toolkits are ActiveVOS by Active Endpoints, Apache ODE by ASF, Oracle BPEL Process Manager and OPEN ESB by Oracle, BizTalk server by Microsoft, WebSphere Process Server by IBM, Parasoft BPEL Maestro by Parasoft, NetBeans IDE by Netbeans Community, JDeveloper by Oracle, ActiveBPEL Designer by Active Endpoints and JBoss developer.

By: Krishnan Iyer

References:

1. Softcare – http://www.softcare.com/whitepapers/wp_whatis_bpel.php

2. Gartner – http://www.gartner.com

3. Forrester Research Inc. – http://www.forrester.com

4. WS and SOA – http://www.service-architecture.com/web-services/articles/business_process_execution_language_for_web_services_bpel4ws.html

5. BPELXML.ORG http://bpel.xml.org/why-use-bpel

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

http://www.oracle.com

http://www.oasis-open.org/