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

This is the first in a series mini-posts on technical and architectural aspects of process asset repository systems. In this post I will introduce the process object engine sub-system.

Deployment of a process asset repository system is critical for any organization striving to advance from project-level process management—CMMI Level 2 maturity–to organizational wide process management that facilitates application of the organization’s best practices and lesson learned across all of its projects—CMMI Level 3 maturity.  Process asset repository system is an enterprise class application that manages all aspects—creation, storage, collaboration, consumption, appraisal–of the organizational process improvement needs.

Abstracted from the users, process object engine forms the core of process asset repository system. Other parts of the system, as well as, external applications interact with the process object engine through a set of web-services APIs. Process object engine provides the necessary infrastructure services including persistence, transaction support and change control.

Moreover, the organization’s process assets are granularly captured using an object model.  Process object model is an interesting topic and I will talk more about in future posts.

I just finished reading a white paper titled “Automating Processes for CMMI Maturity Level 3 and Beyond”. This paper argues that by using business process management (BPM) technologies you can achieve CMMI Maturity Level 3.
It is misleading and an over simplifing to state that BPM tools assist organizations in achieving CMMI Level 3.  Among other things, CMMI Level 3 requires implementation of Organizational Process Definition (OPD) and Organizational Process Focus (OPF) process areas. Both substantial organization wide undertakings and not addressed by BPM tools.
At best, BPM tools may help with some of the practices of CMMI Level 2 process areas, but they fall far short of satisfying even the CMMI Level 2 maturity or capability. As an example, these tools do not address Configuration Management (CM) process area at all. The best automation systems for CMMI Level 2 are ALM and process enactment tools.

I am working on a white paper about process asset repository systems. I should have an early draft of the paper by next week and will post it here soon.

I was trying to run a load test using Visual Studio Team Test Edition yesterday for a large data set and came across an error that said:

Error occurred running test. (Computer LOADTESTMACHINE) Could not access the load test results repository: The load test results repository is out of space. Allocate more space to the repository (if possible), or delete results of older load test runs.

Visual Studio dumps test results in a local instance of MS SQL Server Express and it was easy enough to guess that this was due to SQL Server Express exceeding the db size cap of 4GB (non-Express editions don’t have this cap). I have been running largish load tests on this machine for 8-9 months now and it made sense that I would run out of space.

I went looking for a solution and saw that Microsoft devs have suggested in forums and in blog posts that the DB be cleaned up via SQL to delete test results older than a time period of your choice.

Two things surprised me:

• There is no UI option to manage this in Visual Studio. Before I ran the sql commands, I tried deleting old test results via the “Test Results” window in VS. This apparently deletes exported test results - I am not sure what else it does but it didn’t seem to clean up the DB for the test results. So this means that if you want to clean up your DB when you run into these kind of issues, you need to talk dirty to SQL Server directly. Feels unclean. I Would like to know if I am missing something because this seems like something that shouldn’t require testers even going near a SQL Script.
• I tried and could not find any formal guidance or documentation on msdn to address this issue, even in Practices & Patterns. I may have missed it totally so I hope somebody corrects me if this is actually there. This would be a pretty common scenario I would think so it deserves better than users needing to search blogs and the forums for an answer.

The script I ran is included with this post. A few things to keep in mind:

1. This script cleans up only Load Test Results
2. If you are using a typical installation of Visual Studio Team Test Edition, you need to run this against the db named “LoadTest” on the locally installed instance of MS SQL Server Express installed during Visual Studio installation.
3. Change the value of the @DaysToKeep variable to a suitable value in days. I have set it to 30 days in the script so that results older than 30 days are deleted.
   --@DaysToKeep - indicates the number of previous days records to keep. For example "30" indicates that I want to delete test results older than 30 days
DECLARE @DaysToKeep int
Set @DaysToKeep = 30
4. This script may take a very long time to run - think in terms of hours rather than minutes. It took about 2-2.5 hours in my case. So, don’t abort the execution because you think the script is stuck.

The script (rename to .sql):
deleteoldloadtestresults.txt

Application Lifecycle Management (ALM) is often wrongly thought to only cover only the Software Development Life cycle (SDLC). David Chappell’s excellent and concise whitepaper focuses on this misconception and explains how ALM is more than just the development of the application though that is certainly an important part of it.

ALM is broken down into the Governance, Development and Operations aspects. More importantly Chappell continues the point I had made briefly in my previous post - that there are ALM tools out there which are largely concentrated on the development aspect but their true value can be achieved by integrating them with tools that cover other aspects of ALM - eg: CRM.

To quote the whitepaper:

The three aspects of ALM—governance, development, and operations—are tightly connected to one another. Doing all three well is a requirement for any organization that aspires to maximize the business value of custom software. But this isn’t an easy goal to achieve. Each of the three is challenging to get
right on its own, and so getting the combination right is even more challenging. The right tools can make this easier. A number of vendors today provide tools that are horizontally integrated, i.e., tools that work together well on one of the three lines. For example, Microsoft’s Visual Studio Team System brings together a range of tools supporting several aspects of the development process. Yet tools should be integrated not just horizontally but vertically as well, helping organizations make connections across the three lines. For instance, project management tools should be connected to development tools, which in turn should have connections to the tools used for operations.

These connections are beginning to appear. Visual Studio Team System, for example, can connect with Microsoft’s Project Server to help project managers get up-to-date information on what developers are doing. There’s still plenty of room for improvement, however, and no vendor today offers a set of ALM tools with full vertical integration across all three lines. Tools should be integrated not just horizontally but vertically too.

Read the complete white paper here.