Ideally the execution of business processes should have a machine-like predictability and repeatability. In contrast, Software development processes–and to a certain extend IT processes–are inherently knowledge based (performed by knowledge workers with specialized expertise), and although a certain level of repeatability is desired, are not mechanically repeatable.

I was reading a very interesting Reuters article about Honda’s new entry into the hybrid car market. It talks about how Honda has differentiated itself from Toyota (the previous market leader in this area) by incorporating an innovative software in its new hybrid model: Insight.

But pressure to innovate in the hybrid market won’t necessarily be all about the hardware. If hybrids and other cars embedded with electronic controls and more advanced computing power make their way into the mass market, opportunities could also arise for software. The Insight, for example, includes an “Eco-Assist” display on the dashboard that takes a cue from video games to help educate and encourage drivers to accelerate and decelerate for maximum fuel efficiency. As Wagner James Au explained in an Earth2Tech post about the feature earlier this year, “Like a role-playing game, the driver’s behavior is also tallied over time, and displayed symbolically — here, in the form of an ivy-ringed trophy achievement that a driver can gradually unlock with green-friendly driving. It’s sort of like Wii Fit, but for cars.” Depending on how much Honda decides to open that data, it could provide fodder for game developers, application platform providers and other industrious web entrepreneurs.

Software as a critical competitive advantage has already been a proven fact in the cell phone industry. Now it’s the auto industry’s turn. As software developers, we live in exciting times.

Previously, I categorized process asset repository as an enterprise class system. In here I will clarify the term “enterprise class” and justify the categorization of process asset repository system as enterprise class.

The common aspects of enterprise applications include the following:

• Enterprise applications are used by a large number of people with varied roles. Each role requires it’s own view of a common set of data. Moreover, these applications must meet strict scalability (number of concurrent users) and response time benchmarks. And they should be accessible from any of the organization’s client machine.

• Enterprise applications are mission critical and incorporate large amount of specialized business logic.

• Enterprise applications are data-centric and built on top of a logical (relational) model infrastructure. In most cases the underlying schemas are share across multiple application.

• Enterprise application deal with the organization’s proprietary and valuable assets—data and methods. Hence they require secure—password policies–role based access and data encryption. Moreover, these assets much be centrally managed on a robust infrastructure.

As I state in a white paper on this subject, the organization’s process asset repository system is used by a large number of users with distinct set of roles. It manages all of the organization’s processes, which are proprietary and valuable. And it plays a critical role in the quality and risk management of mission critical projects.

As a side conclusion, process asset repository system cannot be implemented as a desktop application nor a non-transactional website.

In the next post on the subject, I will try to provide you with a more definitive view of the above requirements. To do so, I intend to formulate a set of concrete control objects–based on the above requirements–for development of enterprise applications/solutions. By looking from the perspective of developing such applications, I hope that you will get a fresh insight into the nature of enterprise applications. Also, you may find—as I do—the concept of control objectives interesting.

IT and software development processes and business processes are inherently different and are driven by their own domain needs. System workflow and service oriented architecture (SOA) are the main drivers of business processes. Low-fidelity human centric activities are the main drivers of IT and software development processes.

Execution of inline machine logic and invocation of external systems form the majority of business process logic; human interactions are limited to simple tasks such as approvals.

In contrast, low-fidelity activities of IT and software development processes only capture, at high-level, the expected work to be performed. These processes also rely heavy on role-based creation of work products—for example system analysts create requirement documents, architects create design documents, tester create test cases, and developers produce code. Also, the workflow aspect of these processes is indeterminist and it heavily relies on the knowledge workers involved.

Based on these fundamental differences a single set of systems cannot satisfy the needs of both IT and software development processes and business processes.

Earlier this week, one of our key customers was looking into exporting some of its IT processes from the organizations process asset repository system to IBM Process Server, a business process management (BPM) system.

BPM systems utilize business process execution language (BPEL), XML based language, for process representation. Using IRIS Process Author’s export facility, we are able to quickly define a script that generates BPEL representation of a process which can be consumed by BPM applications. The flexibility of the export facility stems from the fact that IRIS Process Author’s process object model is accessible from within export scripts. Hence, the script logic can directly reference process objects of the asset repository and transform and export the process elements into the desired format.

Usefulness of BPEL goes beyond BPM systems, Microsoft Window Workflow Foundation, currently embedded in BizTalk, SharePoint and Dynamics CRM, also supports BPEL. Therefore, aside from BPM systems, once in BPEL format, the organization’s processes can be used by a variety of applications.

In the first draft of my white paper, I failed to point out the importance of a flexible export facility for the organization’s process asset repository system. I will correct this omission in the next version of the white paper.

Seamless interface with BMP extends the usefulness of the organization’s process asset repository system beyond IT and software process improvement and extends it to the realm of business process improvement. But, the relationship between BPM and process improvement and the differences between IT processes and business processes deserve much more discussion. I will dig deeper into these areas in future posts.

Few days ago, I came across an old (May 1998) article by David Chappell, one my favorite technology writers/thinkers, titled “The Trouble With CORBA “. I could specially relate to his conclusion:

From the beginning, CORBA was never a true standard. Instead, the vendors who controlled the OMG process chose to create something that was more a marketing exercise than a complete technology. And ultimately, this is very sad. What could have been a crucially important industry standard has instead become just another marketing tool for selling proprietary products. The opportunity for a true standard, a TCP/IP for distributed objects, has been lost.

OMG and its supporters argue that given time, CORBA will become a true standard. It’s been seven years, and we’re still waiting. Why should we believe them now?

Believe it or not, this was exactly how OMG handled the development of Software Process Metamodel (SPEM). And once more missed the opportunity to create a true multi-vendor standard. It’s unfortunite that OMG has not changed over the years. I guess the fat cats never learn–or maybe the don’t want to learn.

I have just completed the first draft of a white paper on Process Asset Repository System. I greatly appreciate all comments, corrections and feedbacks. You can reach me at phodaie@osellus.com.
collaborative-process-asset-repository-system.pdf