New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Boris Lublinsky on Jul 13, 2008
The debate about the future of BPMN 2.0 continues. Co-chair of the BMI task force in OMG (responsible for BPMN and other BPM standards) Fred Cummins, talks about one of the current BPMN submissions focusing on resolving differences between BPMN and BPDM and specifically concerns about BPDM complexity:
BPDM is a member of a suite of business modeling languages being developed by OMG. For example, SBVR (Semantics of Business Vocabulary and Rules) supports modeling the semantics of business concepts and the expression of business rules incorporating those semantics. BMM (Business Motivation Model) provides a framework for capturing strategic planning models. A strategic objective of the Business Modeling and Integration task force of OMG is to develop a full complement of business modeling standards that work together to support more effective enterprise planning, analysis, design and improvement. As a result, BPDM has a robust abstract metamodel supporting the BPMN modeling concepts. This abstract metamodel defines basic concepts, many of which will occur in other business models, but in different contexts
Within BPDM, these concepts provide a consistent foundation for modeling business processes regardless of the specific modeling tool. At first glance, Fred states that:
BPDM metamodel might look complex. However, it should be understood that this complexity provides precision in the definition of the concrete elements. The abstract concepts do not appear as additional BPMN graphics and they do not appear as additional concepts expressed in the XML ... In summary, the appearance of complexity of the BPDM metamodel makes the specification more precise and robust, and supports development of consistent, complementary business modeling capabilities in the future. The complexity does not make business process modeling more complex for users, and it does not unnecessarily constrain the implementations of tool vendors
In response to Fred, Bruce Silver notes:
I have to say that complexity of the metamodel would not rank at the top of my list of complaints about BPDM. More serious is the view that the notation is secondary to the metamodel, and that user-defined semantics are OK as long as the underlying metamodel can describe them.
Nick Malik discusses whether high level BPM languages/notations will allow one to completely automate creation/implementation of business processes:
According to the "true believers" we can give end users one of our pretty languages (BPMN or BPEL) and they will write their own software, and we can fire all the IT developers
Nick points out that although these languages can often simplify implementation,they can’t completely replace IT developers (and a proper development process) for business process implementation:
...BPM languages model HUMAN behavior. The things that "become code" are indicative of COMPUTER behavior. We have to be 1,000 times more explicit with computers than with humans. So we need to develop 1,000 times as much code for computers as we do for humans.
Unfortunately (although with the good intentions), Nick combines together both BPMN and BPEL - 2 languages serving completely different purposes, which immediately caused a reply from Bruce Silver, who points out the mistake, but agrees with the overall conclusion:
Let’s hypothesize that Nick has some clue about what BPM is, even though BPMN can not by itself generate implementation (it’s just activity flow modeling) - BPEL is definitely a developer language, not for ‘end users’. (Maybe Nick thinks that only Java programmers are "real" developers?) BPM Suites based on BPMN do provide a more agile implementation style in which business and developers collaborate on process automation
Based on these debates it is obvious that neither role nor direction of BPMN 2.0 is still not clear or completely agreed upon. This uncertainty can significantly impede progress of BPM design and development
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
No comments
Watch Thread Reply