limited set of options are baked in by the product vendor.
Creating an application for users to process their work (see Figure 3) that is
. For the toolsetto be considered a
toolset, the user interfaceshould be a byproduct of the application deﬁnition pro-cess – a declarative process rather than a programmingexercise. While it is important to automatically generatethe user interface, it is also important to provide cus-tomization hooks needed to tweek the interface, sincerarely is the one-size-ﬁts-all approach adequate.III. A
The primary purpose of process automation is process im-provement. Complex business processes are constantly chang-ing – with or without explicit direction. Factors such aschanging business environments, government regulation, andcompetition are major drivers of these changes, necessitatingchanges in the support systems.The traditional life-cycle development approaches to cus-tom development are seriously challenged to support thesedynamics.
Historically, requirements documentation, detailedsystems design, development, and implementation could easilytake 12 to 18 months to deliver a complex solution, duringwhich time the business requirements may have changedsigniﬁcantly enough to require additional iterations prior toimplementation.
has become a popular term for describing the ﬂexi-bility needed by organizations to operate in today’s dynamicenvironments. Agility is a natural by-product of
toolsets. Agility is a critical feature of
products.Agility in the
context is similar to, but not the same asthe agile software development methodology, typically usedin an iterative process for creating custom software. Agility inthe
space is more about using the built-in capabilitiesof the
having to write custom software.Custom software is needed as part of the creation processfor most
solutions, but whenever it can be avoided, theresulting solution is less expensive and has fewer defects andlower risk. In order to differentiate this process from rapidapplications development (
) approaches, I have coined theterm “
.”Another related software engineering concept is model-driven development. These techniques often include a frame-work in which software is developed, providing a powerfulfacility for leveraging the assets within the framework forreuse.The concept of ‘models’ is critical to
products wherethe software architecture creates models of the organization’sbusiness operations – a key example being the model of theoperational aspects of the business being encapsulated in thegraphical process map. But as in the agile space, the model-driven development space is critically different from
in one respect: it is meant to either generate source code or
provide a framework within which source code is written.
models are run-time models as well as design-timemodels and are designed to reduce the need to write customsoftware.So how are
tools different? For agile or model-driven development, source code must be recompiled andredeployed when changes are made. Although this might bedone automatically, it does not produce a clean transitionin production environments; i.e., it is not seemless to anoperating business process.
products, however, storethe semantics of process deﬁnitions in a repository – oftena relational database – and execution engines dynamicallydrive production instances from this repository. Changes to therepository using the
tools directly effect operationalchanges.Another key distinction between frameworks and
tools is that frameworks require skilled software developersto “wire up” the framework in order to achieve the beneﬁts.Frameworks are analogous to e.POWER’s
’s plus oursolution paradigm, but in e.POWER our framework has beenpre-wired so that many of the technical requirements havealready been resolved, allowing less skilled staff, or in somecases such as our process designer, non-technical staff, tocontribute to solution development. Frameworks also requirethat individual wires be “soldered” into the solution.
tools eliminate the need to do so and eliminate the possibilityof
to do so, insuring that critical functionality suchas auditability, searchability, etc., mentioned in the ObjectTypes section of this paper, is included automatically.In a very real sense,
tools are pre-wired, or pre-compiled frameworks.IV. O
Similar approaches have arisen over the years in other busi-ness software categories. Typically packaged as products tooffset the increased cost of producing these solution sets, theseproducts consist of design tools that are largely conﬁguration-driven and produce robust implementations. Such solution setsexist in the enterprise resource planning (
) space, customerresource management space (
), as well as the
space.Each of the design-time toolsets has unique characteristics.One of the key differentiators is how much functionality isdelivered “out-of-the-box” and how much requires customsoftware development.This “out-of-the-boxness” has signiﬁcant beneﬁts beyondthe obvious advantage of creating solutions quickly. Successful
solutions must be customizable to each organization’sunique requirements. Gathering those requirements throughtraditional documentation approaches can be cumbersomeand slow and produces paper-based models to validate therequirements – an imperfect model at best.
tools provide working models of the solutionin days rather than weeks or months. The signiﬁcant userinterfaces and workﬂow needed for requirements validationcan be mocked up very quickly, providing a signiﬁcant portionof the solution in a totally objective fashion – via working
(IJCSIS) International Journal of Computer Science and Information Security,Vol. 8, No. 4, July 2010300http://sites.google.com/site/ijcsis/ISSN 1947-5500