cascon2010 – Column 2

Smarter Infrastructure For A Smarter Planet

Kristof Kloeckner, IBM’s VP of Strategy & Enterprise Initiatives System and Software, & CTO of Cloud Computing, delivered today’s keynote on the theme of a smarter planet and IBM’s cloud computing strategy. Considering that this is the third IBM conference that I’ve been to in six months (Impact, IOD and now CASCON), there’s not a lot new here: people + process + information = smarter enterprise; increasing agility; connecting and empowering people; turning information into insights; driving effectiveness and efficiency; blah, blah, blah.

I found it particularly interesting that the person in charge of IBM’s cloud computing strategy would make a comment from the stage that he could see audience members “surreptitiously using their iPads”, as if those of us using an internet-connected device during his talk were not paying attention or connecting with his material. In actual fact, some of us (like me) are taking notes and blogging on his talk, tweeting about it, looking up references that he makes, and other functions that are more relevant to his presentation than he understands.

I like the slide that he had on the hype versus enterprise reality of IT trends, such as how the consumerization of IT hype is manifesting in industrialization of IT, or how the Big Switch is becoming reality through multiple deployment choices ranging from fully on-premise to fully virtualized public cloud infrastructure. I did have to laugh, however, when he showed a range of deployment models where he labeled the on-premise enterprise data center as a “private cloud”, as well as enterprise data centers that are on-premise but operated by a 3rd party, and enterprise infrastructure that is hosted and operated by a 3rd party for an organization’s exclusive use. It’s only when he gets into shared and public cloud services that he reaches what many of us consider to be “cloud”: the rest is just virtualization and/or managed hosting services where the customer organization still pays for the entire infrastructure.

It’s inevitable that larger (or more paranoid) organizations will continue to have on-premise systems, and might combine them with cloud infrastructure in a hybrid cloud model; there’s a need to have systems management that spans across these hybrid environments, and open standards are starting to emerge for cloud-to-enterprise communication and control.

Kloeckner feels that one of the first major multi-tenanted platforms to emerge(presumably amongst their large enterprise customers) will be databases; although it seems somewhat counterintuitive that organizations nervous about the security and privacy of shared services would use them for their data storage, in retrospect, he’s probably talking about multi-tenanted on-premise or private hosted systems, where the multiple tenants are parts of the same organization. I do agree with his concept of using cloud for development and test environments – I’m seeing this as a popular solution – but believe that the public cloud infrastructure will have the biggest impact in the near term on small and medium businesses by driving down their IT costs, and in cross-organization collaborative applications.

I’m done with CASCON 2010; none of the afternoon workshops piqued my interest, and tomorrow I’m presenting at a seminar hosted by Pegasystems in downtown Toronto. As always, CASCON has been a great conference on software research of all types.

Iterative Development in BPM Applications Using Traceability

The last speaker at the CASCON workshop is Sebastian Carbajales of the IBM Toronto Software Lab (on the WebSphere BPM team), on the interaction between a technical business analyst using WebSphere Business Modeler and an IT developer using WebSphere Integration Developer, particularly how changes made to the business-level model in WBM are reflected in WID. The business view is quite different from the IT view, and doesn’t necessarily directly represent the IT view; this is a common theme at this conference, and in general for vendors who don’t use a shared model approach but rely on some sort of model transformation. Given that there are two different models, then, how do business and IT collaborate in order to keep the models in sync?

They first looked at maintaining a separation of concerns between business and IT that would to minimize the need for changes by IT in response to a business change. This comes down to separating the business logic and rules from the implementation, and the separation of artifacts with well-defined logic from those with undefined logic. I’m not sure that I really get the distinction between the well-defined and undefined logic artifacts, or the benefits of separating them, although my instinct would be to externalize much of the business logic into a rules environment that the business analyst and/or business manager could manipulate directly.

They also looked at tool-assisted model merging to allow models to be compared in the specific user’s domain, then selectively apply and merge the changes into existing models. This would speed development as well as improve the model quality by reducing translation errors. There are some very similar concepts to those discussed in the previous paper on model change management, although with the added complexity of multiple modeling environments. A key goal is to improve the accuracy of model change detection, both to identify the objects in each model type as well as the relationships across the business-IT model transformation, and they used a traceability mechanism to do this. They generate a traceability map when the business to IT model transformation is originally done, capturing the identify of and the relationship between each object in the models, which allows traceability of changes on either model type.

He walked through a typical scenario, where the BA creates a process model in WBM, then exports/publishes it, where it is then imported by IT into WID and enhanced with implementation artifacts. When a change is made by the BA to the original model, and re-exported, that modified model is compared to enhanced WID model to create a new, merged WID model. Then, the change report is exported from WID, and any business-level changes are compared and merged back into the WBM model. Yikes.

Having a traceability map allows an IT developer to filter changes based on the business or IT artifacts, do visual comparisons and selective merging of the models. On the return trip, the BA can view updates to the process model, business services and business service objects that might impact the business logic, and select to apply them to the business-level models. The traceability is the key to model governance when multiple model types undergo transformations as part of the modeling and implementation lifecycle.

Following Carbajales’ presentation, we had a round-table discussion on the two process modeling themes of collaboration and consistency management to finish up the workshop. Some good ideas on the reality of business-IT collaboration in process modeling.

Process Model Change Management

Jochen Küster of the IBM Research Zurich lab (where they do a lot of BPM research), was first after the morning break at our CASCON workshop on collaboration and consistency management in BPM, presenting on process model change management. This was more of a technical talk about the tools required. As motivation, process models are a key part of model-driven development, and become input to the IT process modeling efforts for SOA implementations. Multiple models of different types will be created at different points in the modeling lifecycle, but individual models will also go through multiple revisions that need to be compared and merged. This sort of version management – that allows models to be compared with differences highlighted, then selectively merged – doesn’t exist in most process modeling tools, and didn’t exist at all in the IBM process modeling tools when their research started. This is different from just keeping a copy of all revised process models, where any one can be selected and used.

In order to do this sort of comparison and selective merging, it’s necessary to generate a change log that can be used for this purpose, logging not only atomic activities, but have those rolled up to compound operations to denote an entire process fragment. Furthermore, the merged model generated by the selective application of the changes must still be valid, and must be checked for correctness: a resolution of the changes following a detection of the changes.

The solution starts with a tree-like decomposition of the process model into fragments, with correspondences being determined between model elements and fragments; this was the subject of research by the Zurich lab that I saw presented at BPM 2008 in Milan on parsing using a refined process structure tree (PST). A key part of this is to identify the compound operations that denote the insertion, movement or deletion of a process fragment. The current research is focused on computing a joint PST (J-PST) for the merged process, which is the combination of two PSTs determined by the earlier decomposition, based on the correspondences found between the two models. The dependencies are also computed, that is, which process fragments and activities need to be inserted, moved or deleted before others can be handled.

The results of this research has been integrated into WebSphere Business Modeler v7.0, although not clear if this is part of production code, or a prototype integration. In the future, they’re looking at improving usability particularly around model difference resolution, then integrate and extend these concepts of change management and consistency checking to other artifacts such as use cases and SCA component diagrams.

Why Applying Workflow Patterns is Hard

Janette Wong, a long-time IBMer who is now an independent consultant working as a solutions architect, discussed the use of workflow patterns in modeling business requirements and turning these into executable processes.

She used an example of an “authorization” business requirement, where manager can create confidential requests, and transfer those confidential requests to others. This can be matched to the standard role-based distribution pattern, which is fine for modeling, but then needs to be mapped to an implementation platform: in this case, some combination of WebSphere Process Server (WPS), LDAP or other directory service for user authentication and authorization, a workflow client application for human task management, and any other data sources that include user/role information. This multi-system implementation requires not only a conceptual mapping of the process and roles, but also actual integration between the systems that house the information. WPS provides instance-based authorization roles, then needs to bind that to the other sources at runtime in order to populate those roles; it doesn’t automate the solution, and in fact only provides a small amount of assistance in getting to that mapping. This is complicated further by role and authorization information that is spread out over multiple systems, particularly existing legacy systems; the business may think of the roles as being encapsulated in one of these other systems, which then needs to be mapped into the executing process.

She also discussed the requirement of a multi-item Inquiry, where multiple sub-inquiries will be created from the main inquiry (such as fraud investigations), and the exact number is not know at design time. This matches to the multiple instances without a priori runtime knowledge pattern, where you have multiple parallel sub-tasks that start and end independently, although the master activity has to wait for all children to complete before proceeding. This is similar to what we are seeing emerging in many case management implementations, where the parent activity is really the case itself, and the child tasks are those activities that the case workers initiates in order to move towards case resolution.

Wong observes that in spite of the length of time that BPM systems have been around, the larger patterns are not well supported by many of the systems although they are prevalent in real-world situations. She talked about the need for better design in process modeling tools, so that it is more obvious how to use the tools to implement these common, but complex, workflow patterns.

Adopting BPM at Bank of Northeast of Brazil

Next in the workshop was Moises Branco from University of Waterloo; he previously worked with the Bank of Northeast of Brazil (BNB) and discussed his work there as well as his current research that resulted from some of the challenges identified there. Their motivation for BPM came from a revision of their IT processes in 2004 that exposed the inflexibility in the heterogeneous environment; they saw BPM as being important for modeling and optimization, but also for process execution. They graded all of their existing systems on scales of technical quality and functional quality, mapped onto four quadrants of substitute (both low), improve functionality (low functional, high technical), improve architecture (high functional, low technical) and maintain (both high), with a drive to move systems in the two “improve” quadrants into the “maintain” quadrant.

He showed their strategy for execution, which included a business specification in the form of a process model, then an executable process that was a transformation/refinement of that model, and used an ESB to call services layered over their legacy systems. Since they took an enterprise architecture approach, they considered the multiple interrelated artifacts produced, including process models at various levels, use cases, business rules and entity-relationship diagrams. With multiple artifacts, the concerns became traceability, consistency and impact analysis between the models. To complicate things further, some of the development was outsourced, meaning that the collaboration between business and IT that should occur during any model-driven development had to extends beyond the enterprise.

Unfortunately, just as we heard from BofA, much of the model translation and consistency management was manual, as well as the collaboration in terms of version management. They were able to semi-automate the establishment of traceability links and perform basic model consistency checking.

Their current research is on model consistency: defining it via traceability, and automating some of the traceability between models (e.g., business-level and executable) and consistency checking.

Maintaining Consistency Across BPM Initiatives’ Content

In a break from the usual lineup of academics and researches, Peter Braun of Bank of America was up next in the collaboration and consistency management workshop to present on maintaining consistency across BPM initiatives’ content. They use IBM’s WebSphere Business Modeler (WBM), Information Framework (IFW, effectively a set of reference models in an enterprise architecture framework) and m1 (the modeling tool on which IFW sits), but have many other tools that have been implemented independently – mostly due to acquisitions – and need to be unified in a consistent environment as part of their latest transformation initiative. He gave some background on model-driven development, business process modeling (what I would consider BPA, although he called it BPMo) and IFW.

Braun comes from the business side, and he has a keen focus on the adoption of collaborative model-driven development: they use an agile approach that greatly reduces the need for written requirements through the involvement of the subject matter experts at all phases of process modeling. I’ve worked at introducing this in several of my financial services clients, and the culture shift is significant, since business analysts (and their managers) find it hard to imagine a project without a 100+ page text-only requirements document containing disconnected lists of desired features and actual requirements. Also, the expectation of ongoing involvement, not just the up-front requirements development that is thrown over the wall to the development, then forgotten until delivery.

They also have to deal with model governance to keep the WBM and IFW models in sync: each are used for different types of models at different points in the modeling lifecycle, and have specific strengths such that they want to continue using both tools. Because there are multiple non-integrated tools, they need to do model management to consider the interactions between model types, and there is a great deal of manual work to be done when a model is exported between the two environments. After the initial export/import, any changes in a model in one environment have to be manually made to match in the other modeling environment. They have issues with version management, since there is no proper repository being used for the models, and the modelers can end up overwriting each other’s efforts in a shared area on a server. They’ve also looked at ILOG, and have further issues with managing consistency between the rules designed in WBM – which map to the process server – and when those rules are rewritten in ILOG in order to externalize them.

Their biggest challenges include consistent adoption by all stakeholders, and what he refers to as tool/data integration, but is mostly about model governance and using “smarter tools”. It’s just not clear to me that their current combination of Visio, WBM and IFW is going to get very much smarter.

Effective Collaboration and Consistency Management in Process Modeling

Krzysztof Czarnecki of the University of Waterloo introduced this morning’s workshop on Effective Collaboration and Consistency Management in Business Process Modeling, starting with a discussion of consistency management in modeling: within versions of the same model type, but also between models of different types, such as sequence diagrams and state charts, where there may be overlap of information representation. This theme of model interrelationship and translation has come up a couple of times this week at CASCON, and the need to manage the consistency between these artifacts through understanding the relationships and usages. He discussed some of the techniques for determining model overlap/relationship and checking consistency, including overlap and merging, and how these might differ depending on whether there is a 1:1, 1:many or many:many mapping between the different models. He also introduced modeling collaboration concepts, including methods of communication, terminology and awareness, in order to set the stage for the remainder of the workshop.

I’m going to break this post by the individual speakers since these are really independent presentations, and it will get way too long otherwise.

Real Time Monitoring & Simulation of Business Processes

My last session for the day at CASCON is to hear Alex Lau of IBM, and Andrei Solomon and Marin Litoiu of York University discuss their research project on real time monitoring and simulation of business processes (they also presented a related paper this morning, although I missed the session). This is one of the CAS Innovation Impact sessions, which are based on fellowship projects that are “ready for harvesting”, which I think means that they’re ready to move towards productization. These projects involve one student (Solomon) and one professor (Litoiu) from a university, then one person from CAS (Lau) and one from IBM development (Jay Benayon, also credited on the research). In this case, the need for the research was identified by IBM development; I’m not sure if this is the usual method, although it seems logical that these projects act as mini research teams for work that is beyond the scope of production development.

In addition to their research, they’ve prototyped a system that integrates with WebSphere Process Modeler that can use the monitoring data from an in-flight process in order to feedback to a simulation model of the process to improve what-if scenario analysis and process KPI forecasting. The key research challenge was the use of the monitoring data, because that data is typically quite noisy since it could include hidden overhead such as queuing, and tended to skew results to make task durations appear to be longer than they actually were. This noise can’t be measured directly, but they’ve attempted to filter it out of the monitoring data using a particle filter prior to feeding into the simulation model.

Their proof of concept prototype linked together three IBM products, and could either change automated decisions in the runtime process or suggest alternatives to a human participant, based on the near-past performance of that process instance and any approaching SLA deadlines. One caveat is that they didn’t use real-world (e.g., customer) business processes for this, but created their own processes and ran them to generate their results.

They see this research as applicable to any process modeling tools where processes can be simulated against a set of metrics, KPIs can be forecasted, and simulation parameters are entered at modeling time and remain static until explicitly updated. They have the potential to extend their technique, for example, by providing better trend predictions based on regression techniques. There are other vendors working on research like this, and I think that we’ll see a lot more of this sort of functionality in BPM solutions in the future, where users are presented with suggestions (or automated decisions made) based on a prediction of how well a process instance is likely to meet its KPIs.

That’s it for me today, but I’ll be back here tomorrow morning for the workshop on practical ontologies, the women in technology lunch panel, and the afternoon keynote.

Enabling Smarter BPM through Business Entities with Lifecycles

Today’s keynote was by Richard Hull, Research Manager at the T.J. Watson Research Center, on business entities with lifecycles. He started by describing the process of process: how business strategy maps to business goals which maps to business operations, that is, the multiple conceptual models involved in BPM design and implementation. He stated that today’s approach to BPM environments is fundamentally disjointed: there’s one conceptual model for rules and policies, another for analytics and dashboards, and another core business process model based on activity flows, while the data being manipulated is often not related to the conceptual models but is more of an afterthought in the design.

Process and data are two sides of the same coin (as Clay Richardson stated at BPM 2010, and many of us have been saying for a while), and Hull thinks that we need to change the way that we model data to account for the fact that it is being used to support process, and change the way that we model processes to account for the tight linkage between process and data. This has led to a new way to model and implement business processes and operations: business entities with lifecycles (BEL). He defined a BEL as a key conceptual dynamic entity/object that is used in guiding the operation of a business, such as a FedEx package delivery that includes all data and processing steps from pickup through delivery and payment. This is an integrated view of the process and data, with different views according to the lifecycle of the entity. That means that it needs to include an information model containing the relevant data, and a lifecycle model to show the possible lifecycles. There’s been a couple of papers published by this research group, and they’ve integrated this into IBM GBS both in terms of a methodology and some tools.

He presented BEL as a new way of thinking – like the shift to OOP – that we need to get our head around in order to understand the methodology and the benefits. He walked through the characteristics of the first generation of BEL, starting with the end-to-end process visibility across multiple silos and their interactions. The example was an automotive engineering/manufacturing process, where they defined business entities for an engineering change, an engineering work order and a part, each of which has an information (data) model and a lifecycle (process, represented as a finite state machine) model that may span the engineering, purchasing and manufacturing silos. Each task in the process, which is likely executed within a single silo, relates to a view on the information model. He sees this as coming before requirements: once the information and lifecycle models are created, then the requirements can be created based on those.

He described BEL as “upper middleware”, since BELs can be used as an upper layer to control legacy applications via their services wrappers. The business entity approach relies on identifying things that matter to define the objects; he discussed a banking example, where those things included customer, campaign, product, element (product building block) and deal. He showed the lifecycle for the deal entity, where the information model was represented alongside the process model. Although BPMN 2.0 now has the ability to represent data models, BPEL does not, and it’s probably safe to say that most process modeling is still done fairly separate from data modeling. However, BPM tools are changing to provide better linkages between process and data models, and I think that we’ll start to see full integration between process modeling tools and master data management tools in the next year or so.

By bringing together the data and process models, BELs now have all the structure required to automatically generate user interface screens for the human activities in the process; this is something that we’ve been seeing in BPM tools for a number of years, based on the process instance data model as defined in the process. Although you typically can’t just use those auto-generated screens as is, the BEL models and tooling along with the UI auto-gen provides a significant accelerator for creating process applications.

Maybe I’ve just seen too many leading-edge products and methods, but I don’t find anything here that new. Yes, it’s nice to have more formalized models and methodologies around this, but the idea of linking business object and process models, and auto-generating user interface screens from them, isn’t cutting edge. He positions this as not really competitive to WebSphere (process modeler), but being for cases when BPMN just doesn’t cut it. He described the differentiator as that of disaggregating operations into chunks that are meaningful to the business, then modeling the lifecycle of those chunks relative to a more global information model.

There’s more research being done on this, including moving to a more declarative style; I’d be interested in seeing more about this to understand the benefits over the current crop of BPM products that allow for a more integrated business object/process modeling environment.

Towards Workflow Verification

Continuing on with the CASCON technical papers session focused on service oriented systems, we saw a paper on Towards Workflow Verification by Leyla Naiza, Ahmed Mashiyat, Hao Wang and MacCaull Wendy of St. Francis Xavier University in Nova Scotia. The basis of this research is on model verification to ensure that the model matches the specification properties and doesn’t produce undesirable effects at runtime. The problem with testing any sort of real process model (i.e., one with more than the 5 steps that you see in a demo) is that it’s difficult to check the model for all possible states.

Their research looks at this by decomposing the process models to fundamental workflow patterns (e.g., synchronization, sequence), then translate these into DVE, the input language for DiVinE, a distributed and parallel model checker. They can then verify specific properties in the model specification, such as their example in clinical trials, “the end of the workflow (patient release) cannot be reached without 5 drug tests”. They switched from using Petri Nets to YAWL for process modeling in order to make the automated translation to DVE possible, and built the automated translator to test this model verification method. They also introduced a time extension to the translation, allowing verification of time-related properties of the process model.

I see the biggest challenge in mapping the businesses’ view of their rules onto specific properties to be tested; this linkage between business requirements and technical implementation has been with us since the beginning of systems, and it’s not clear that this research does any validation on those rules and properties themselves, making verification against them less meaningful. Furthermore, these properties are really business rules, and imply that the rules are encoded within the process model rather than externalized in a business rules system. Nonetheless, automating verification of process models is a step in the right direction for improving the quality complex process models.