This will help with pending research for 2013

NOTES:

Reasons behind going with the Xeon-E3 CPU (instead of Xeon-E5 or AMD-G34 ) :

1. Price… E5 CPUs are “premium” priced. The E5 did more than required (don’t need x16 PCI-e, nor 8 DIMM slots). Why pay the premium price for unused features? A fast E3 appeared to cover CPU/processing requirements. And, a good SuperMicro board provided sufficient PCIe slots (2 @ 8x and 2 @ 4x)
2. Following apparent standards. Though I wanted a AMD-G34… (quad memory channel, reasonably priced, etc.), most of my clients have Xeon servers. I needed something “standard” for testing/benchmarks.
3. Though preferring dual CPU server motherboards – the E3 doesn’t support 2x configuration. And, the 2  x E5 setup is too expensive given all that extra horsepower just sits idle most of the time. I also wanted something that doesn’t heat up the office during the summer.
4. Saving $$$ with the E3 supported rationalization for the more expensive RAID controller. The bottleneck on this server WILL NOT be I/O! The new RAID controller is fast. I’ll also be adding a 2x Intel Gigabit NIC for network pass-through (though motherboard does have two adapters).

Configuration

ESXi:
5.1.0

Motherboard:
Supermicro X9SCM-IIF-O
BIOS version: R 2.0a (shipped with current) – NOTE: VT-d is turned “off” by default (switched this “on” via BIOS-config)

CPU:
Xeon E3-1270 V2 3.5GHz

RAM:
4 x Samsung DDR3-1600 8GB/1Gx72 ECC M391B1G73BH0-CK0

RAID:
LSI 9260-8i

Hard Drives:
2 x WD VelociRaptor WD6000HLHX 600GB
2 x WD VelociRaptor WD5000HHTZ 500GB

Case:
LIAN LI PC-7HX Black Aluminum ATX Mid Tower

Bench-test
(notice that I missed 4 pins on the power connector? The board booted regardless…)

Installed

If you haven’t already done so I highly recommend you “tool up” for iOS (iPhone) or Android development. Speaking more on the Android platform with this point, but Android is based on Linux – meaning that the Android “smartphone” is a small, pocket-sized Linux computer. And, behind this tiny, touch-screen UI, we have an event-driven framework suited for wireless IO (communication) and  distributed client (end-user) services. This makes a good fit for BPM mobility as it applies focused, via platform constraints, user-to-process interaction.

So, in warming up to enterprise-scale BPM Mobility, I want to first walk through a few system architectures – this prior to diving into the details of Android computing. Goal being a build-up towards mobile device UI/IO requirements: from current state to future capabilities.

BPM Desktop Client: Web-portal, JSP Struts/Tiles

JSP Struts/Tiles Workhorse of BPM (Lombardi)

The portal has been with BPM practically from the very beginning and it exists today mostly in its original form as a jsp STRUTS/Tiles web-application.

Though somewhat dated in its technology, we must give credit as it has been and still is the BPM workhorse: delivering process execution, management, tracking, and reporting to our end-users. However, the portal leaves us wanting. Today’s users require a “rich web” experience – something beyond the reach of traditional architectures (form based: HTTP get/post). And, though the BPM Portal remains unsurpassed in features it simply cannot function as a mobile application.

For example, with the portal loaded into a 10″ tablet web-browser, there are just too many active features and UI elements for reasonable touch-screen interaction. I found myself constantly zooming in for navigation and then back out again to review effects and options. However, dashboard and charting elements do work well when broken out on their own as separate elements.

IBM-BPM v751 – Advanced: Dojo, Widgets, ReST API

With BPM 751-Advanced, we now have dojo v1.6, Business Space, and ReST APIs

Business Space enhances end-user experience with iWidgets and supporting dojo infrastructure.  Users now have rich web-applications without the downside of additional overhead costs required for custom in-house web development.

New BPM ReST APIs also opens the door to previously unattainable (within reason) web capabilities. Fully in-browser, JavaScript libraries now have direct access to process management. This leads to better performing web applications with reduced UI-interrupting side-effects caused by (legacy) HTML “post” and “get” operations.

Though very close, I’m not sure that we’re at mobile computing. I need to qualify this however because Business Space runs well on Tablets. The catch is that it requires screen real-estate, network bandwidth, and additional CPU. Honestly, these are negligible on today’s desktop/laptop computers. Even reasonably powerful tablets are fully capable of running Business Space over wifi.

Business Space on a smart-phone though does spot-light a few problems.

Screen real-estate is tight on smart-phones! Slow performance is also noticeable as the phone’s CPU just doesn’t seem to keep up and deliver on the same snappy performance previously experienced on both desktop and tablet execution.

Phones require their own native BPM application.

Mobile Applications for Mobile Process Management

With Android hosting activity services, external BPM requests flow through ReST APIs

Writing native applications feels counter-intuitive but it’s our only alternative given the constraints and limitations for mobile computing. Moving task services to Android (for example) significantly improves performance. Execution latency and UI “lag” disappear as timings drop into sub-second range.

With local execution, we’re looking at:

• Reduced IO traffic via local application loading
• Discrete JSON server requests via ReST APIs.
• Native (java) run-time execution
• Local device data-storage. For example, Android includes a database usable for both caching and offline process execution.
• Local application services. These include: notification, document viewers, contacts, identity, and geo/mapping.

Conclusion

In working towards an architecture suitable for mobile BPM we take into account accompanying constraints and capabilities. We’re on a different path in that we’ve re-focused on building native phone applications.

BPM Task List on Samsung Galaxy S II, Android v2.3.6 (Gingerbread), Dual Core Qualcomm CPU – 1.5GHz

Smartphones require discrete UIs, optimized coding techniques, and light-weight network IO. These challenges though are well worth the investment as mobility advances user-to-process interaction to near-personal proximity.

Acknowledging the tens of millions of new users purchasing smartphones, new expectations are set/re-set on almost a daily basis. Now’s the time to revisit our architecture and build-in these future capabilities.

Laptop: ASUS N53 Series N53SV-XV1 Intel Core i7 2630QM

• Win7-64 Professional, SP1 (Host Operating System)
• Crucial M4 256GB SATA III Solid State Drive (SSD)
• 4 x G.SKILL 4GB 204-Pin DDR3 SO-DIMM DDR3 1333 (16GB total)
• VMWARE: v8
• Guest OS: RHEL 5.5.x (RedHat Enterprise v5.5x)

NOTES:

This laptop is easily 2x faster than my previous ASUS  i7 620M(2.66GHz). Key differences are 4 vs 2 core i7 and the new Crucial SSD. The new SSD reads at 415MB/s (average… peaks at 500BM/s) and writes at 260MB/s. This means that, for instance, I installed a local copy of Websphere 7 in less than 2 minutes! I didn’t time profile creation but it took much less than than anticipated. Installation and profile creation were so fast that had I though they exited early with an exception.

VM RHEL is also easly 2x faster on this laptop. Instance start/stop/pause executes much more quickly. The next key test is to see how the batteries hold-out during air-travel.

How do we stay on path?

Process Modeling versus Software Development

Avoid Blindly Following Software Development Life-Cycle (SDLC) Best Practices

Use only those practices which  deliver on increased efficiencies. Process development is not software development. Process development, though thoroughly taking full advantage of the various components and services flowing out of SDLC, does NOT do SDLC. Process is exempt – reason is that once a process requires, for example, full QA support, it’s slipped into application “mode”. Meaning that your team has fallen into the practice of building-out point solutions as apposed to business process models. A process is not an application.

Measure Process Construction On Its Own Terms

Best example is “on time delivery” and “completeness”. If the BPM team falls behind on delivery, the WORST follow-up is corrective action on old-school software project management (PM) reporting. Seems obvious, from above, not following PM reporting methods on a project not… following SDLC. This is a common experience though – pushing the BPM team into wrong methods and practice via non-sequitur measurements and reporting.

The solution is to track/measure towards (reporting on) alignment to business value and vision. This requires the process model be “played back” (demonstrated) before a live business audience (this is not your QA team). The question is asked and answered, “is this the model you asked for and does it help our business?” Simple measurement on value – we only care about value. And, more importantly, the path towards good process construction demands the capability to discover, deviate, and remain on target – no exceptions to this rule! Success is business value.

Cut Unnecessary Complexity

A tight balancing act in that system architecture and user interface is important… to whom? This is hindsight. I’ve fallen into the trap more often than I care to admit. Situation is that key stakeholders often lack understanding on the problem-at-hand. In lacking clarity the “light” only shines on familiar items and patterns, though with reasonable history, lack application on BPM projects.

Examples are the fancy, if not beautiful user interface (UI), and wonderfully elegant system architecture. This is like speaking Latin. As the tribe (organization) hears what’s understood. And this understanding is unfortunately bound to irrelevant complexity.

There is no solution here – no courseware training, presentations, discussion…

I recommend the BPM team work in isolation and report only to key, knowledgeable business stakeholders. And, if discussion drifts, quickly rein the team – remind them of alignment, vision, and business value. You may need to drop and replace participants – better shift distractions out early rather than bog the project down on irrelevant complexities.

• Project Management
• Requirements
• Architecture
• Design
• Patterns for Reuse
• Infrastructure
• Integration
• Durability, Robustness, and Security
• Life-cycle and Operations
• Others, etc.

Forward

As with relatively new technologies and methods, discovery is a significant part of the learning process. And, notwithstanding misconceptions, some lessons will be learned from trial-and-error.

It’s my attempt here, via these chapters, to share a few of my own experiences. Many of these lessons were learned the hard way. You’ll find, as I did, that classic and modern software development techniques do not apply without adjustment. This new “process oriented” way of thinking requires change in both philosophy and approach – as some paths will lead to a rocky experience, we’ll learn to backup and adjust our approach.

Assuming others will take the same road – I’ll start my series from a look-ahead perspective, where otherwise good software practice leads to BPM project troubles. In-other-words, the “hows” and “whys” we call BPM methods “process oriented” as apposed to (for example) “object oriented” techniques.

Process Management versus Software Development

Departmentalized IT Stovepipes

BPM projects require a new approach as their work extends beyond traditional IT boundaries. For example, topics like business strategy and departmental alignment.

In taking on this work, our methodologies require adjustment and tolerance as what was once a typically predictable path now leads us wandering through a seaming maze of new discoveries, obstacles, and political minefields.

First change on the agenda is institutionalized dogma (or, departmental habits die hard).

A Change in Methods

The corporate IT organization casts a long, deep shadow of institutionalized thinking (or dogma) across projects. Institutional thinking and approach, which ordinarily works well on “standard” efforts, will interfere and harm BPM projects – usually leading to failure on initial attempts. Though good intentions in mind, the old way of doing things must end if we’re to succeed on our next effort.

One Project Plan and Synchronized Software Development (project versus team milestones). It’s a dangerous practice attempting to share deadlines on otherwise naturally distributed, asynchronous work efforts. In contrast to a drum’s dancing rhythm,  forced synchronicity for BPM work has the opposite effect on enterprise projects. Cross-project milestone alignment will lead to a grinding loss of productivity.

Architecting Process as a Single Software Point-solution. Process is not “architected”. The methods of architecting a process assumes that we already understand – that the process itself is known and ready for refinement into something expressed via technologies as systems. This isn’t the case with BPM which defines itself as a means towards providing evolutionary process – a perfection intended to match against our changing business environment. Something gained, and then lost, given that business itself is evolutionary. As innovation is one of our key desires behind the process-oriented methodology,  a static system is not an achievement. However, we shouldn’t confuse this argument with architecture’s place in: patterns, SDLC, components, and service construction (etc.).
[To be continued...]