Column 2 : Software design

{ Category Archives } Software design

Software AG partner frameworks

I had lunch today at Innovation World with a Software AG partner that will be releasing one of the industry vertical frameworks (I didn’t ask if I could use their name, so am withholding it for now). They see the frameworks as a necessity to even demonstrate BPM to a vertical business, as well as providing a base on which to create a custom solution. A few bits about the partner frameworks:

The partner that I spoke with does not plan to productize the framework; rather, it will be used as the starting point for a custom solution for a client. This is how I see most companies implementing frameworks on top of any BPMS, with a mixed degree of success: although it’s difficult to turn some or all of a framework into a product rather than a service, especially for the services companies who normally create them, a productized framework can have advantages when it comes to maintenance and support. Customers need to be aware that a non-productized framework is really just another piece of custom code, and the long-term maintenance costs will reflect that.
This partner plans to retain the intellectual property of the framework and any custom code that they build on it, allowing them to roll the code developed for any customer back into the framework for resale. This is great for the industry in general, and future customers in particular, but customers would need to ensure that they specify any processes to which they do not want to give up IP rights.
Software AG does not provide guidelines or rules for what should or should not be in a framework, or how to create one. In their online partner forum, however, they describe the existing frameworks so that partners can get an idea of what should be in one.
Software AG is not certifying the partner frameworks, so customers need to do their own due diligence on the strength of the solution. Some sort of certification program would likely improve customer confidence in the third-party frameworks.

Vertical industry frameworks are definitely the new black in BPM these days: in addition to Software AG’s program of mixed internal and third-party frameworks, Savvion announced a fairly ambitious framework program with one tier of components built by Savvion and one by their partners, and TIBCO provides some vertical frameworks as a vertical marketing tool.

I’m all for providing a leg up for customers to start working with a BPMS in their industry, but we need to be clear about whether something is a true framework or a set of unsupported templates, understand the value that a framework can bring, and know the pitfalls of a framework approach. I’ve seen some pretty big BPMS implementations that went totally off track because of the use of a non-productized framework: the framework became brittle legacy custom code before it was even in production, was seriously impacted by a minor upgrade to the underlying BPMS platform, and did not allow access to recent modeling and optimization functions provided in the BPMS since it was designed and built for a previous version.

In general, I think that most “frameworks” that overlay BPMS’ are actually templates, providing marketing and sales support for the underlying product in that vertical, but not providing a lot of value in terms of a code base. Those that do have a significant code base are usually not productized, hence need to be evaluated as a big chunk of custom code: although the initial purchase price is likely lower than having all that code written for you, you have to consider the ongoing maintenance costs.

2008 11 04 Sandy Kemsley BPM Comments (1)

Business Rules Forum: Pedram Abrari on MDA, SOA and rules

Pedram Abrari, founder and CTO of Corticon, did a breakout session on model-driven architecture, SOA, and the role that rules play in all of this. I’m also in the only room in conference center that’s close enough to the lobby to pick up the hotel wifi, and I found an electrical outlet, so I’m in blogger heaven.

It’s a day for analogies, and Abrari uses the analogy of car for a business application: the driver representing business, and the mechanic representing IT. A driver needs to have control over where he’s going and how he gets there, but doesn’t need to understand the details of how the car works. The mechanic, on the other hand, doesn’t need to understand where the driver is going, but keeps the car and its controls in good working order. Think of the shift from procedural to declarative development concepts, where we’ve moved from stating how to do something, to what needs to be done. A simple example: the difference between writing code to sum a series of numbers, and just selecting a range of cells in Excel and selecting the SUM function.

The utopia of model-driven architecture (MDA) is that business applications are modeled, not programmed; they’re abstract yet comprehensive, directly executable (or at least deployable to an execution environment without programming), the monitoring and analytics are tied directly to the model, and optimization is done directly on the model. The lack of programming required for creating an executable model is critical for keeping the development in the model, and not having it get sucked down into the morass of coding that often happens in environments that are round-trippable in theory, but end up with too much IT tweaking in the execution environment to ever return to the modeling environment.

He then moved on to define SOA: the concept of reusable software components that can be loosely coupled, and use a standard interface to allow for platform neutrality and design by contract. Compound/complex services can be built by assembling lower-level services in an orchestration, usually with BPM.

The key message here is that MDA and SOA fit together perfectly, as most of us are aware: those services that you create as part of your SOA initiative can be assembled directly by your modeling environment, since there is a standard interface for doing so, and services provide functionality without having to know how (or even where) that function is executed. When your MDA environment is a BPMS, this is a crystal-clear connection: every BPMS provides easy ways to interrogate and integrate web services directly into a process as a process step.

From all of this, it’s a simple step to see that a BRMS can provide rules/decisioning services directly to a process; essentially the same message that I discussed yesterday in my presentation, where decision services are no different than any other type of web services that you would call from a BPMS. Abrari stated, however, that the focus should not be on the rules themselves, but on the decision service that’s provided, where a decision is made up of a complete and consistent set of rules that addresses a specific business decision, within a reasonable timeframe, and with a full audit log of the rules fired to reach a specific decision in order to show the decision justification. The underlying rule set must be declarative to make it accessible to business people.

He ended up with a discussion of the necessity to extract rules out of your legacy systems and put them into a central rules repository, and a summary of the model-driven service-oriented world:

Applications are modeled rather than coded
Legacy applications are also available as web services
Business systems are agile and transparent
Enterprise knowledge assets (data, decisions, processes) are stored in a central repository
Management has full visibility into the past, present and future of the business
Enterprises are no longer held hostage by the inability of their systems to keep up with the business

Although the bits on MDA and SOA might have been new to some of the attendees, some of the rules content may have been a bit too basic for this audience, and/or already covered in the general keynotes. However, Abrari is trying to make that strong connection between MDA and rules for model-driven rules development, which is the approach that Corticon takes with their product.

PegaWorld: Paul Kompare on JPMorgan Chase’s agile methodology

Paul Kompare, SVP of commercial banking technology at JPMorgan Chase discussed their Pega implementation of a straight-through processing infrastructure for commercial loans. He gave us a brief view of the current environment and the proposed solution, then moved on to discuss their agile implementation approach. Although they refer to this as Agile, it’s still a bit waterfall-like: the sprints don’t result in released code, but in checkpoint demos, and these are the points when the business representatives interact with the development team rather than being a co-located team (which likely would not have been possible since they rely heavily on offshore development resources). However, it’s a big improvement over their old waterfall methodology.

They delivered the project in two phases, each with three iterations:

Happy paths and primary flows
Exception paths and secondary flows
UI, integration and reports

In each iteration, they establish and sign off on the criteria, then use Pega to directly capture objectives and model the processes. With this relatively agile process, they improved project sponsorship as well as getting early buy-in from the business, since they were able to demonstrate something earlier and more frequently. Using PRPC also gives the business managers more visibility into the business processes and their underlying logic, rather than having those processes locked up inside opaque application code. They found that the tools gave them more agility and flexibility during implementation, greater reusability and faster time to market, as well as allowing potential changes to be identified earlier.

They did have some challenges with adapting to an agile approach: this type of approach assumes that changes to the design and functionality of the system will occur during development, and relies on rolling out a phased series of small, self-contained components. From a funding standpoint, it’s almost impossible to issue fixed-price contracts for agile development, since there is not a really fixed statement of work on which to base the proposed price. I’ve seen cases where a third-party services firm doesn’t really get agile methodology, and there is a huge amount of overhead as they attempt to shoehorn their waterfall deliverables into each iteration of the agile development, or they just abandon the agile approach and go back to waterfall.

There’s also major changes to roles and responsibilities: the business participants have much greater responsibility during design and as the system rolls out, and having them trained in the design tools is critical.

He concluded that adopting agile development methodologies has been a challenge for them, but that it’s definitely helping them to achieve shorter development cycles. There’s very little here that’s specific to commercial loans, Pega implementations, or even BPM; these same factors would be seen in any organization shifting to an agile approach. However, Kompare made the point that they were driven to consider an agile approach because the Pega tools tend to work better in that environment than with a traditional development methodology.

2008 10 21 Sandy Kemsley PegaWorld Comments (0)

PegaWorld: Meryl Stewart and Kelly Karlen on Business-IT Collaboration at BlueCross BlueShield

Last session of the day, and Meryl Stewart and Kelly Karlen of BlueCross BlueShield of Minnesota talked about maximizing BPM value through business and IT collaboration. They established a shared business-IT objective of enabling the business to manage their frequently-changing business rules to provide agility, while still maintaining environmental stability by following the necessary change management procedures.

They’ve wrapped some procedures around their projects to explicitly call this out, as well as explicit governance layers for processes and rules. Some of this — a big part — is about well-defined roles and responsibilities, such as a business rules steward. They categorize these procedures and methods by collection, execution and optimization stages, and walked us through each of the roles in each of the stages.

In the collection stage, they have a pretty structured way to create business rules and shore them in an enterprise repository; this is independent of their BPM technology, since not all processes end up being automated.

They wanted to make execution more efficient, so combined their RUP methodology with Pega’s RUP-like methodology and lightened it up to create a more agile “RUP Lite” (although as they walk through it, it doesn’t feel so light but it does have fairly frequent code releases). Within that methodology, they have a number of additional roles to work on the business to technology transformation of the execution phase, and definite rules about who can do what types of changes and who does the associated testing. There’s a level of semi-technical analyst who can do a lot of the non-coding changes.

The optimization stage is where business agility happens, but this was addressed pretty quickly and seemed to be some sort of standard change management procedure.

This definitely shows some good software development practices, but there’s nothing particularly innovative here that can’t be replicated elsewhere as long as you can get the collaboration part to work; collaboration is primarily a function of finding people on both sides of the business-IT divide who can see over the wall to the other side, and maybe even straddle the divide somewhat with their skills.

They’ve applied the methodology to a couple of projects and have seen positive ROI, and very few coding changes since most of the process tuning can be done by business users or the semi-technical analysts. In one process, they’ve had 11 rule changes in 4 months with resultant savings of $820k in the improved processes; if IT were to have been involved in these changes, only $126k of the savings could have been realized in the same timeframe due to IT project schedules — a good measure of the value of agility provided by allowing the business to change business rules. Fundamentally, they changed an 8-week IT build cycle to 10 days or less by allowing the business to change the rules, but still following a test and deploy cycle that keeps lT happy.

That’s it for today; there’s a reception, then dinner and a cruise on the Potomac to view the monuments by night. The esteemed Dr. Michael zur Muehlen will not be joining us in spite of being right across the river in Arlington; when I invited him, he gave some lame excuse about just getting back from Seoul.

2008 10 20 Sandy Kemsley BPM
PegaWorld Comments (0)

TUCON: Using BPM to Prioritize Service Creation

Immediately after the Spotfire-BPM session, I was up to talk about using BPM to drive top-down service discovery and definition. I would have posted my slides right away, but one of the audience members pointed out that the arrows in the two diagrams should be bidirectional (I begged forgiveness on the grounds that I’m an engineer, not a graphic artist), so I fixed that up before posting to Slideshare:

| View | Upload your own

My notes that I jotted down before the presentation included the following:

SOA should be business focused (even owned by the business): a top-down approach to service definition provides better alignment of services with business needs.
The key is to create business-granular services corresponding to business functions: a business abstraction of SOA. This requires business-IT collaboration.
Build thin applications/processes and fat services to enable agile business processes. Fat services may have multiple operations for different requirements, e.g., retrieving/updating just the customer name versus the full customer record in an underlying system.
Shared business semantics are key to identifying reusable business services: ensure that business analysts creating the process models are using the same terminology.
Seek services that have the greatest business value.
Use cases can be used to identify candidates for services, as can boundary crossings activity diagrams.
Process decomposition can help identify reusable services, but it’s not possible to decompose and reengineer every process: look for ineffective processes with high strategic value as targets for decomposition.
Build the SOA roadmap based on business value.
SOA isn’t (just) about creating services, it’s about building business processes and applications from services.
Services should be loosely-coupled and location-independent.

There were some interesting questions arising from this, one being when to put service orchestration in the services layer (i.e., have one service call another) and when to put it in the process layer (i.e., have a process call the services). I see two facets to this: is this a business-level service, and do you want transparency into the service orchestration from the process level? If it’s not a business-level service, then you don’t want business analysts having to learn enough about it to use it in a process. You can still do orchestration of technical services into a business service using BPM, but do that as a subprocess, then expose the subprocess to the business analyst; or push that down to the service level. If you’re orchestration business-level services into coarser business-level services, then the decision whether to do this at the service or process level is about transparency: do you want the service orchestration to be visible at the process level for monitoring and process tracing?

This was the first time that I’ve given this presentation, but it was so easy because it came directly out of my experiences. Regardless, it’s good to have that behind me so that I can focus on the afternoon sessions.

2008 05 01 Sandy Kemsley BPM
SOA
TUCON Comments (0)

BPEL for Java Developers Webinar

Active Endpoints is hosting a webinar this Thursday on BPEL Basics for Java Developers, featuring Ron Romano, their principal consulting architect. From their information:

A high-level overview of BPEL and its importance in a web-services environment is presented, along with a brief discussion of the basic BPEL activities and how they relate to Java concepts. The following topics will be covered:

Parsing the Language of SOA with Java as a guide

Breaking out of the VM: evolving from RPC to Web Services

BPEL Activities – Receive, Reply, Invoke

BPEL Facilities – Fault Handling and Compensation (“Undo”)

The VP of Marketing assures me that he was allowed only two slides at the end of the presentation, and that otherwise this is focused on the technical goodies.

You need to register in advance at the link above.

Tagged BPEL

2008 04 15 Sandy Kemsley BPM standards
SOA Comments (1)

BPM and Model-Driven Development, SaaS and the economy

It’s been a slow week for blogging due to a lot of billable client work, which takes precedence, and I’ve also missed several webinars that I wanted to attend. However, an article that I wrote for Intelligent Enterprise was picked up on TechWeb and published on the Yahoo! News Tech page (thanks to Bruce Williams of Software AG for tipping me off), which has resulted in quite a bit of traffic this week. I wrote the article at the end of the Gartner BPM summit last month, sifting through the wide variety of information that I saw there and distilling out some common themes: model-driven architecture/development, BPM and software-as-a-service, and the impact of the slowing economy on BPM.

The part on BPM and model-driven development was written prior to the Great BPMN Debate, but there’s an obvious tie-in, since BPMN is the modeling language that’s typically used for MDD in BPM. One of the webinars that I missed, but have just played back, is one from PegaSystems and OMG on Five Principles for Success with Model Driven Development (playback available, registration required), which touches on a number of the ideas of using (usually graphical) models to express artifacts across the entire software development lifecycle. Richard Soley of OMG and Setrag Khoshafian of Pega went through these principles in detail:

Directly capture objectives through executable models and avoid complex mappings between tools
Make a BPM suite the core layer of your MDD: model-driven development is achieved through BPM
Build and manage an enterprise repository of your modeling assets using a complete BPM suite
Leverage the platform and architecture pattern independence
Adopt a BPM suite methodology, center of excellence, best practices and continuous improvement lifecycle

The principles presented by Khoshafian were rather suspiciously aligned with Pega’s way of doing things — I have the feeling that Soley would have produced a somewhat different list of principles on his own — but the entire webinar is still worth watching, especially if you’re trying to haul your organization out of a waterfall development model or trying to understand how BPM and MDD interrelate.

To my new visitors arriving here because of the TechWeb syndication of the article: browse the archives by month or category (including the conference subcategories), or use the search feature to find topics of interest. I have several mostly-finished blog posts waiting for some final touches, so stay tuned for more content.

2008 03 27 Sandy Kemsley BPM
SaaS Comments (4)

A chance encounter with jBPM

In one of those weird coincidences, JBoss World is happening simultaneously in the same conference center as ProcessWorld; Tom Baeyens noticed that I was blogging from ProcessWorld and contacted me, and we had a chance to meet up today.

We had a great discussion about model-driven applications, and finding the dividing line between what works and doesn’t work in a model-driven paradigm. Tom’s premise is that model-driven development can work in simple cases, but that it’s not possible to generalize: at some point, enough technical underpinnings need to be added to the model that it’s no longer understandable by a non-technical business analyst. Although the business analyst can still create a model and pass it for translation to a developer for augmentation, it’s going to be a one-way trip in most cases.

I definitely see some validity to this position; what typically ends up happening in today’s model-driven development in BPM is that either the developers just take over maintenance of the models at some point (even if the tool allows the models to be shared), or the business analysts learn enough of the technical side to be able to understand the fully-executable model which is, unfortunately, no longer really a business model.

jBPM is not at all about model-driven development, but provides a BPM engine that can be embedded directly in your Java code. Tom shared some of his vision of the future for the project with respect to expanding modeling capabilities and other areas; suffice it to say that total BPM world domination is on the plan.

2008 02 15 Sandy Kemsley BPM Comments (5)

Gartner BPM: The New Agile BPM Method, David Norton

This morning, I attended with David Norton’s session on integrating BPM and Agile software development methods. In BPM, we always talk about how BPM brings agility to business processes, but what facilitates that agility? Although a lot of this talk is about Agile, it’s definitely valid to look at how to apply Agile methods to BPM projects, since there’s still some amount of software development in almost every BPM project.

He started with a review of software development methods: architected model-driven (including BPM, where you draw an executable process model rather than writing code to handle work routing), architected RAD, and Agile. He then drilled in on Gartner’s 10 principles of NeoRAD (an example of Agile), such as close involvement of the customer, peer review and an iterative approach.

BPM needs to be a mix of agility and discipline, but not a waterfall methodology that we so often see used by old-style development teams when they take on a BPM project; BPM is predominantly architected model-driven because of the executable process models, but also uses some aspects of architected RAD and Agile since there are integration and UI components that require development beyond just the process modeling stage.

He described the principles of Extreme Programming as a coding methodology, and Scrum as a way to manage agile development projects; Scrum, in particular, has a lot of useful concepts that could be applied to BPM projects. He also covered Dynamic Systems Development Method, a type of RAD framework that includes the concept of turning an operational prototype into the end product to reduce waste and time in the development cycle, and Lean Software Development, focused on reducing waste and defects in the same sort of way as Lean works in the manufacturing sector.

He then looked at how BPM release cycles — continuous cycle of design and optimization, iterations of under six weeks, new policies and rules in a day — and how they are much more aligned with Agile methodologies than the traditional waterfall approach, which typically sees the first release in 4-6 months (in the best possible case). Unfortunately, most development teams inside organizations are still stuck in waterfall methodologies, and third-party professional services firms are more motivated to suggest long development cycles with large development teams. That means that even though the process model might be done as zero-code architected model-driven, the (often excessive) customization that happens in the component/service layer and the user interface drags down the project schedule.

This presentation was really much more about Agile than BPM — sometimes Gartner makes a bit of a stretch when bringing in their analysts from other areas and trying to make them BPM-ish — but if you’re not already looking at Agile development for any BPM-related project, you definitely should be.

2008 02 07 Sandy Kemsley Gartner BPM Comments (4)

Business analyst mindmap

This is my day for having friends post amazing business-related graphics. This one (you’ll need to click through to the full-size version in order to see the detail) is by Bryce Johnson:

2008 01 29 Sandy Kemsley Comments (2)

Forrester Day 1: Packaged Applications panel

We finished up the day with a panel of Forrester analysts addressing the issue of whether packaged applications (i.e., ERP software) will ever be designed for people and built for change — that is, can these apps ever be agile. This was structured as a debate monitored by Merv Adrian, pitting Sharyn Leaver on the business side against John Rymer on the IT development side.

Adrian started by repeating the four principles of dynamic business applications that Connie Moore discussed this morning, then framed some questions for the packaged application version:

Will packaged applications contextualize work using unitary but dynamic workplaces?
Will packaged applications enable up-front customization to meet unique customer needs? (The feeling is that apps will be customizable “at the edges” only in order to allow for future upgrades/agility)
Will packaged applications enable ongoing adaptation for continuous business evolution? (Yeah, right)
Will packaged applications allow development and change by business people and IT professionals in cooperation?

Leaver and Rymer duked it out over each question, providing some really interesting viewpoints. It wasn’t exactly impromptu; each question had at least one backup presentation slide from one of them to make their point. They ended up with a slide comparing the four application biggies: Oracle, SAP, Microsoft and IBM.

From my standpoint, this was the least interesting presentation of the day, since I don’t focus on packaged applications, although it was an interesting “he said, she said” debate format. The general agreement is that the gap is narrowing between build and buy+customize, but that most customers will still require customization for competitive differentiation.

Tom Pohlmann popped back up at the end of the day with some closing remarks, then directed us off to the vendor showcase reception and the pool party. Given that it’s only 21C here in Carlsbad — compared to a balmy 28C back in Toronto (even though it’s already after dark there) — I don’t think that anyone’s going swimming tonight. Since I’m still on Eastern time, I’ll probably be asleep by 9pm again tonight.

2007 09 25 Sandy Kemsley ForresterITLeadership Comments (0)

Generalists and specialists

Great graphic by Dave Gray of XPLANE, showing the difference between generalists and specialists. Click through on the image to his Flickr page to see in full resolution, or view it directly on his blog, there’s a lot of other great material there.

His key point: generalists are best at defining the problem or goal, while specialists are best at solving the problem or executing the plan.

I met Dave at VizThink3 in Toronto this summer, where he led us through some exercises in visual thinking; I’m more of a written word sort of person, so these exercises were good at stretching my brain a bit; I even drew a visual representation of crowdsourcing. I think that my drawing skills need a bit of work.

BPM is one of those areas where a structured type of visual thinking is used: most often, people draw a process flow to represent their business process, and that visual representation (now standardized in BPMN) has become the primary way for specifying processes for automation. Although Dave’s work focusses in a great part on visuals for marketing and training communications, process visualization is part of what they do; check out their website for the Standard & Poor’s example, where the process map looks like a subway route map.

2007 08 20 Sandy Kemsley BPA Comments (0)

BEAParticipate: Building your own UI

First session of the last morning, Eduardo Chiocconi of BEA and Rob Wald of JPMorgan Chase talked about the ALBPM UI: what comes out of the box, and what you can build yourself.

Out of the box, ALBPM has three user interfaces alternatives:

HiPer WorkSpace, a full user workspace with menus based on their permissions, a view of their inbox, and views of any instances that the user opens. It uses CSS if you want to change styles, and can be customized further in terms of removing buttons and other controls.
JSR-168 portlets for any standard portal environment, such as WebLogic.
WorkSpace Extensions WorkList Portlets that can be plugged into ALI and provide additional integration functionality over the standard portal interface, such as integration with the ALI Collaboration environment.

They’re working on consolidating these interfaces in order to reduce the user learning curve.

If those don’t work for you, then you can create your own user interface, either browser-based or rich client, using the available APIs. For building web clients, many of their customers have used JSP to re-code the entire user interface, then used servlets to access the engine. Alternatively, you can use Struts or JSF/AJAX. All of these can use their Java-based process API, PAPI, or the web services version, PAPI-WS, to retrieve instances from the engine, or WAPI (a servlet-based API) to execute interactive activities such as screen flows.

For rich clients, they’re seeing a lot of .Net development that uses PAPI-WS to retrieve instances, then create the UI. It’s also possible to use Eclipse or Swing to build rich user interfaces that call PAPI directly. This is more complex for interactive activities, but there are ways to work around that.

To sum up, there are three public APIs:

PAPI (process API), which is a Java implementation. If you’re working in a Java environment, this provides the tightest integration and best functionality. It manages multiple process engines transparently, and does instance caching on the client side to reduce latency in connecting to the engine — a critical performance factor.
PAPI-WS is a subset of PAPI that operates as web services (SOAP), although this is being extended in the near future to provide the full functionality of PAPI. There may be a .Net version of PAPI in the future, but for now you have to use PAPI-WS if you’re developing in .Net (e.g., ASP.Net), and can also be used from any web service client. Right now, PAPI-WS is part of the HiPer WorkSpace, but will be decoupled as a self-contained web application in the future. It’s also possible to expose processes directly as web services, as we heard in an earlier session, which provides another point of integration from a web service or .Net development environment.
WAPI, which is a servlet API that can be used to launch the UI of an interactive activity at a point in the process, which can’t be done in PAPI or PAPI-WS.

With any custom UI, there’s always the question of single sign-on. With the WorkSpace Extensions WorkList Portlets in ALI, that’s handled natively; in the HiPer WorkSpace and JSR-168 portlet implementations it requires some customization, although there is a single sign-on login servlet provided with the JSR-168 portlets to make this easier.

Getting to the specific JPMorgan case study, they created a custom user interface since, like many large companies, they want integration with other applications in their environment and want more control over the look and feel of the interface. It’s possible to just create custom JSPs and use them in the standard work portal framework, which provides a great deal of control over the UI without completely rewriting it, but this wasn’t sufficient for many of their applications. What they ended up doing was creating a completely custom inbox using Struts/JSP/GWT with PAPI: one example that he showed was using Struts and AJAX via the Google Web Toolkit to manage financial reconciliation processes. They’re also using IceFaces, an open source RenderKit implementation of JSF (as a replacement for Struts) that supports AJAX to create a visual drag-and-drop components for use in an IDE such as Eclipse. Since JPMorgan is dedicated to the use of open source, they’re doing some innovative development that’s not seen in most corporate environments, but maybe should be. They’re also using the JSR-168 portlets in a more standard portal implementation, and building rich clients with Eclipse.

On the back end of their implementation, they’ve found that some of the PAPI protocols don’t work well over wide-area networks, such as between their US and Japan operations, so they do quite a bit of preloading of the PAPI cache.

JPMorgan has implemented ALBPM as a centralized shared service in order to provide efficient use of both human and server resources: centralized code and best practices on the human side, and a single ALBPM server handling 10 applications without difficulty.

2007 05 09 Sandy Kemsley BEAparticipate
BPM Comments (0)

BEAParticipate: Best Practices for Succeeding with BPM

I’m jumping around between tracks (and hence rooms): I started the afternoon in the ALUI Experience track, then on to the ALBPM Technical/Developer track, and now I’m in the ALBPM Experience track for a discussion of best practices for managing BPM projects with Dan Atwood of BEA (another former Fuego employee) and Karl Djernal of Citigroup. It’s a bit difficult to pick and choose sessions when you’re interested in multiple tracks: this session and the one after it in the same track are both around best practices, although appear to cover different aspects of BPM implementations and I’d like to sit through both. This one is categorized as “beginner” and the next as “intermediate”, so I’m hoping that someone’s actually checked to ensure that there’s not too much overlap between them. I’d also like to see the next technical track on how BPM and ESB work together, but think that I can probably get a briefing on that directly from BEA as required.

Atwood started the session with seven key practices for BPM success:

Fundamentals of process-based competition: understanding the competitive advantage of being a process-oriented company, and the business case for BPM.
BPM and its value to the corporation: understanding what BPM is and how it differs from other management and technology approaches.
From functional management to process-oriented thinking: how the shift from functional management must permeate through the ranks of middle management in order to disperse the fiefdoms within an organization.
Getting hands-on BPM experience, with the help of mentors.
Foundations for process practitioners: BPM as the capability for implementing and extending other management practices such as Six Sigma.
Business process modelling and methods: learn about process-oriented architectures and development methods, and how they differ from traditional approaches.
Human interactions and their roles within BPM: while system-to-system automation is often a BPM focus, the human-facing parts of the process are critical. In other words, you can’t think of these as being “human-interrupted” processes, as a customer of mine did long ago.

Obviously a big fan of BPM books, Atwood references Peter Fingar, Howard Smith, Andrew Spanyi, John Jeston, Mike Jacka, Paulette Kellerin and Keith Harrison-Broninski, as well as a raft of BPM-related sites (although not, unfortunately, www.column2.com). Also a fan of lists, he finishes up with his top five success factors:

Executive sponsorship
Correct scoping
Start with the end in mind
Framework
Engage stakeholders

Hmmm, that seems to make 12 best practices in total…

Djernal then discussed the Agile methodology that they used for BPM implementation at Citigroup, starting with a description of Agile and Scrum as the anti-waterfall approach: providing incremental deliveries based on changing, just-in-time requirements, and involving the end users closely during the development cycle to provide feedback on each iteration. Just as important as delivery mechanisms is the Agile team structure: the team’s not managed in the traditional sense, but works closely with the customer/end-user to create what they want. There’s a 15-minute team meeting every day, and a delivery (sprint) every 30 days. Many teams vary the sprint length slightly while sticking to the Agile methodology, although there’s danger in increasing it too much or you slip back to months-long delivery cycles. Initiated by the original prioritized set of product features, the user feedback on each iteration can impact both the features and the priorities. There’s basically three roles in Agile: a product owner who represents the stakeholders, the team that implement everything, and the ScrumMaster who provides mentoring on the Agile process and helps to sort out external roadblocks.

The interesting thing is how they brought together BPM and Agile, since I’m convinced that these are two things that belong together. Process diagrams fill in a lot of the documentation gap and are a naturally agile form of creating a functional specification; they form a good basis for communication between the business and IT. Changes in requirements that cause changes to the business process can be done easily in a graphical process modelling environment. In fact, in many BPM environments, the processes can be prototyped and an initial executable version developed in a matter of days without writing any code, which in turn helps to set priorities on the functions that do require coding, such as developing web services wrappers around legacy systems.

They’ve learned some things from their experiences so far:

Get training on using the BPM products, and on BPM in general.
Use some external resources (like me) to help you get started.
Since BPM involves integration, setting up the development, testing and production environments can be time-consuming and require specialized resources.
Spend some time up front putting together a good test environment, including automated testing tools.
Create a centre of excellence for BPM.
Start something small for your first BPM project.

There’s a lot of arguments about how Agile can’t really handle large-scale development projects, but it’s my belief that most BPM projects lend themselves well to Agile. The worst disasters that I’ve seen in BPM implementation have been the product of the most non-Agile development processes imaginable, with months of requirements writing followed by many more months of development, all of which resulted in something that didn’t match the users’ requirements and was much too costly to change. As I’ve said many times before, if you can’t get something up and running in BPM in a matter of a couple of months, then you’re doing something really wrong.

2007 05 07 Sandy Kemsley BEAparticipate
BPM Comments (0)

The New Software Industry: David Messerschmitt

David Messerschmitt, a prof at UC Berkeley and the Helsinki University of Technology, finished the formal presentations for the day with a talk on how inter-firm cooperation can be improved in the software industry. This is an interesting wrap-up, since we’ve been hearing about technology, applications and business opportunities all day, and this takes a look at how all these new software industry companies can cooperate to the benefit of all parties.

He started out by proposing a mission statement: focus the software industry’s attention and resources on providing greater value to the user and consumer. This has two aspects: do less harm, and do more direct provision of value to the customer rather than the computational equivalent of administrivia.

In general the software industry has a fairly low customer satisfaction rate of around 75%, whereas specific software sectors such as internet travel and brokerage rank significantly higher. In general, services provided by people have a lower satisfaction rate (likely due to the variability of service levels), and the satisfaction rates are decreasing each year. Complaints are focussed on gratuitous change (change due to platform changes rather than anything that enhances user value) and security, and to some extent on having to change business processes to match an application’s process rather than having the system adapt to their business process. Certainly, there are lessons here for BPM implementations.

Messerschmitt raised the issue of declining enrolment of women in computer science, which he thinks is in part due to the perception that computer science is more about heads-down programming rather than about dealing with users’ requirements. He sees this as a bit of a canary in a coal mine, indicating some sort of upcoming problem for the computing industry in general if it is driving away those who want to deal with the user-facing side of software development. Related to that, he recommends the book Democratizing Innovation by Eric von Hippel, for its study of how customers are providing innovation that feeds back into product design and development, not just in software but in many areas of products.

He ended up by discussing various ways to improve inter-firm cooperation, such as the Global Environment for Networking Innovations (GENI) initiative, ways to accomplish seamless operation of enterprise systems, and referring to a paper that he recently wrote and will be published in July’s IEEE Proceedings, Rethinking Components: From Hardware and Software to Systems. He then listed elements of collective action that can be pursued by industry players, academia and professional organizations to help achieve this end:

Systematically look at knowledge gaps and ensure that the research is addressing those gaps
Create/educate the human resources that are needed by the industry
Understand and encourage complementarities, like broadband and certain types of software
Structures and processes: capture end-user innovations for incorporation into a product, and achieve a more orderly evolution of technology with the goal of leaving behind many fewer legacies in the future

He’s definitely of the “a rising tide lifts all boats” mindset.

2007 04 30 Sandy Kemsley NewSoftwareIndustry Comments (0)

The New Software Industry: Bob Glushko and Shelley Evenson

Bob Glushko, a prof at UC Berkeley, and Shelley Evenson, a prof at CMU, discussed different views on bridging the front stage and back stage in service system design. As a side note, I have to say that it’s fun to be back (temporarily) in an academic environment: many of these presentations are much more like grad school lectures than standard conference presentations. And like university lectures, they cover way too much material in a very short time by speaking at light speed and flipping slides so fast that there’s no time to even read what’s on the slide, much less absorb or document it. If I had a nickel for every time that a presenter today said “I don’t have time to go into this but it’s an important concept” while flipping past an interesting-looking slide, I could probably buy myself the drink that I need to calm myself after the information overload.

Glushko posits that greater predictability produces a better experience, even if the average level of service is lower, using the example of a self-service hotel check-in versus the variability of dealing with a reception clerk. Although he doesn’t mention it, this is exactly the point of Six Sigma: reducing variability, not necessarily improving service quality.

He goes on to discuss the front stage of services, which is the interaction of the customer or other services with the services, and the back stage, which is the execution of the underlying services themselves. I love his examples: he uses an analogy of a restaurant, with the front stage being the dining room, and the back stage being the kitchen. Front stage designers focus on usability and other user interface factors, whereas the back stage designers focus on efficiency, standardization, data models and the like. This tends to create a tension between the two design perspectives, and begs the question if these are intrinsic or avoidable.

From a design standpoint, he feels that it’s essential to create information flow and process models that span both the back and front stages. The focus of back stage design is to design modular and configurable services that enable flexibility and customization in the front stage, and to determine which back stage services you will perform and which you will outsource/reuse from other service providers. Front stage design, on the other hand, is focussed on designing the level of service intensity (the intensity of information exchange between the customer and the service, whether the service is human or automated), and to implement model-based user interfaces and use these models to generate/configure/specify the APIs of user interfaces for the services. By exposing back stage information in front stage design, more back stage information can improve the immediate experience for a specific customer, and can improve subsequent experiences. Data mining and business intelligence can also improve service for future customers.

Evenson, who specializes in interaction design, has a very different perspective than Glushko, who focusses on the back stage design, but rather than being opposing views, they’re just different perspectives on the same issues of designing service systems.

She started out with a hilarious re-rendering of Glushko’s restaurant example by making the point that she applied colour to make the division of the co-production between front and back stage more visible.

Her slides really went by so fast that I was only able to capture a few snippets: sensors will improve the degree of interaction and usefulness of web-based services; technology influences our sense of self; services are activities or events that form a product through interaction with a customer; services are performances: choreographed interactions manufactured at the point of delivery; services are the visible front end of a process that co-produces value. A service system is a framework that connects service touchpoints so that they can sense, respond and reinforce one another. The system must be dynamic enough to be able to efficiently reflect the expectations people bring to the experience at any given moment. Service systems enable people to have experiences and achieve goals.

She discussed the difficulties of designing a service system, such as the difficulty of prototyping and the difficulty of representing the experience, and pointed out that it requires combining aspects of business, technology and experience. She feels that it’s helpful to create an integrated service design language: systems of elements with meanings (that designers use to communicate and users “read”) plus sets of organizing principles.

2007 04 30 Sandy Kemsley NewSoftwareIndustry
SOA Comments (0)

The New Software Industry: Martin Griss and Adam Blum

Martin Griss of CMU West and Adam Blum of Mobio Networks had a fairly interactive discussion about integrating traditional software engineering practices into modern service oriented development.

Griss is a big proponent of agile development, and believes that the traditional software development process is too ponderous; Blum admits to benefits from smaller teams and lightweight process for faster delivery, but he believes that some of the artifacts of traditional development methods provide value to the process.

Griss’ problems with traditional development are:

Too many large documents
It’s too hard to keep the documents in synch with each other and the development
People spend too much time in document reviews
Use cases are too complex
Can’t react well to changes in requirements
Schedule and features become omnipotent, rather than actual user requirements

In response, Blum had his list of problems with agile development:

Some things really do need upfront analysis/architecture to create requirements and specification, particularly the lower layers in the stack
Team management needs to be more complex on larger projects
Many agile artifacts are simply “old wine in new bottles”, and it’ simply a matter of determining the right level of detail
If you have a team that’s currently delivering well, the introduction of agile processes can disrupt the team and impact productivity — if it’s not broke, don’t fix it
Some of the time-boxing of agile development (e.g., SCRUM monthly sprints, daily 10-minute meetings) creates artificial schedule constraints
Agile development theory is mostly pseudo-science without many facts to back it up
Modern tools can make older artifacts lighter-weight and more usable

Writing requirements and specifications is something that I’ve spent probably 1000’s of hours doing over the years, and many of my customers still require this methodology, so I’m sympathetic to Blum’s viewpoint: sometimes it’s not appropriate or not possible to go agile.

An interesting point emerged from the back-and-forth discussion: it may not be possible to build the development platforms and frameworks themselves (such as what Mobio builds) in an agile fashion, but the applications built on those high-level platforms lend themselves well to agile development. Features to be added to the platform are effectively prototyped in an agile way in applications built on the platform, then are handed off to the more traditional, structured development cycle of the platform itself.

Griss, who was partially looking to just stir up discussion earlier, pointed out that it’s necessary to take the best parts of both ends of the software development methodology spectrum. At the end, it appears that they agree that there are methodologies and artifacts that are important, it’s just a matter of the degree of ceremony to use on any given part of the software development process.

2007 04 30 Sandy Kemsley NewSoftwareIndustry Comments (0)

The New Software Industry: Michael Cusumano

Michael Cusumano is with the MIT Sloan School of Management, and has written several books on the changing software industry; he spoke today about the changing business of software.

In general, there is a decline of new enterprise software product revenues, and growth in services and maintenance sales. There are a number of new business models, including SaaS and ad-supported software.

Software companies tend to move from being product companies to services or hybrid product/services companies (maintenance revenue is usually included in services). However, there’s a different evolution curve that shows where companies focus on product innovation, then on process innovation (e.g., making the product more efficiently), then on services innovation.

The number of publicly-owned software companies peaked in 1997 at around 400 companies. IT services firms peaked in 1999 at around 500 companies. Web companies, which can be launched with significantly less capital (due to distribution mechanisms and development tools/methodologies), had a peak in 1999 before dropping in the crash, but are now climbing to an even higher peak.

Cusumano showed a graph of three business model dimensions: revenue model, delivery model, and customers, with traditional software product vendors at the origin of the graph, and various other models scattered throughout the cube. He also asked the question, is the rise in services and new business models temporary or permanent? The “temporary” argument says that we’re in a transition phase between platform and business model innovations; the “permanent” argument (with which I agree) says that software is now commoditized and prices will fall to close to zero as we embrace SaaS and ad-supported models.

Being an MIT geek, Cusumano had slide after slide of data analysis about his research on software product companies. For example, average product company revenue crossed over in 2002 so that services revenue was larger than product revenue; also, firms at 24+ years of age have more services than product revenue. The age phenomena contributes to the date-based phenomena, since many of the large enterprise product vendors are reaching this level of age maturity now. There’s an interesting cycle where services are very attractive for revenue generation, but then reach a point (in terms of % of revenue) where they are performed relatively inefficiently and, due to lower profit margins, are not as profitable as product; eventually, as companies become better at providing services (e.g., reusability), it swings to a more positive contributor to profitability. Market cap follows a similar pattern, although the centre (when services are undesirable) portion of the graph is broader.

Similar things are happening with hardware companies: more than 50% of IBM’s revenue, for example, is from services.

He had some interesting comments on the way that software product companies should incorporate services into their business model: it should be planned and exploited as opposed to just happening by accident, as it does with many product companies.

He ended up with some key questions:

How to manage the mix of products, services and maintenance efforts and revenue within a product company.
How to “servitize” products, to make them less generic and more customizable.
How to productize services; a great point that he made here is that it’s best served by creating two professional services organizations with different mandates.

2007 04 30 Sandy Kemsley Enterprise 2.0
NewSoftwareIndustry Comments (0)

CMU Masters in Software Management

Often, when I receive a request for a meeting on something that’s far outside of my usual BPM/Enterprise 2.0 interests, I’ll turn it down. However, when the meeting is with various deans and professors at Carnegie Mellon University West about their new Masters in Software Management program (press release here), I’m happy to make an exception. I graduated as an engineer over 20 years ago, and programs like this just weren’t available then; I was curious to see how engineering education has advanced. I had a call with Dr. Jim Morris, dean of the CMU west coast campus, Dr. Martin Griss, associate dean for education and director of the software engineering program, and Tony Wasserman, executive director of the Center for Open Source Investigation. Of course, they’re all professors at CMU as well, at the relatively new campus in Silicon Valley.

The Masters in Software Management is like a software engineering equivalent to an executive MBA: it’s intended for people who are already experienced practitioners but want to improve their management skills in a big way, and do so part-time while they continue to work so that they can start to see immediate application and benefit. It grew out of the high level of interest in the management courses offered as part of the Masters in Software Engineering program that’s been running since 2002, as well as interest from employers in the marketplace for the skills that they plan to teach. The Masters in Software Management is less technical than the Masters in Software Engineering, but offers some amazing courses that I think should work their way into any senior software engineering or computer science curriculum: open source, enterprise architecture, managing distributed teams, outsourcing, and many others. Since these are presented in a current business context, using long-running teams and simulating a small company experience, the goal is to produce the next generation of software leaders.

The program doesn’t kick off until later this year, so they don’t know the demographics of the student population yet, but are expecting that most will have a technical computer science/software engineering background, and that there will be a mix of those from small companies who want to improve their skills and build the next Google, and some from large companies who are either closet entrepreneurs or are serious about software management within their organization. About 1/3 of the Masters in Software Engineering program attendees are women, and they expect the percentage to be higher in the Software Management program. As in the Software Engineering program (where about 30% of the students are offsite), they’ll allow remote students, although they need to be onsite for the 4-day kickoff and a few more times during the 2-year program.

2007 03 05 Sandy Kemsley Comments (2)

How things go ’round and ’round

I had an email yesterday from my friend Robb, which I have his permission to publish here. Robb used to work for me — in fact, I think that I hired him a total of three times — and whenever a company seeking to hire him calls me for a reference, I always tell them that the only negative thing about hiring him is that when I’m ready to start another company, I’ll be hiring Robb away from them. Robb has four essential qualities when it comes to working: he’s smart, he’ll do anything to get the job done for the customer, he always has my back, and he’s funny. His email yesterday, as usual, showed off the smart and funny bits:

Below is a newly formed company called Miria Systems. I give a history how this company came into being. Imagine how some things never actually die off:

1998 – A company named Application Partners was founded around an insurance/finance product and named it Sequis– because apparently the English language is short of meaningful words

2000 – FileNet bought Application Partners and renamed it PeBA (standing for Panagon eBusiness Application) shortly after that they got bored with the name PeBA and renamed the product Acenza

2003 – After some successes the Acenza FileNet stalled the product program (to make way for BrightSpire) and effectively sold Acenza to a company called Endymion

2004 – Endymion changed the name from Acenza to (drumroll) Acenza for Payables

2003/2004 – Not satisfied with a simple named change Endymion completely re-wrote Acenza for Payables and changed the name to ManagedPay

2004 – Endymion apparently used up a lot of their budget on the name changes (and even more on re-write) because they were forced into a merger with Software Consulting Group (SCG) — the two companies formed Soluziona USA

2005 – Not satisfied with a single re-write was good enough to keep their engineers happy Soluziona USA again decided to re-write ManagedPay but decided that the name should stay the same

2006 – Soluziona USA sold their ManagedPay product to a group of investors who formed a new company around this three-times-rewritten-and-five-times renamed product, keeping with tradition they gave the company a name with equally little English meaning as anything else in this brief history — Miria Systems, below is the link

www.miriasystems.com

The interesting thing here to me here, besides the obvious snide comments around product/company naming exercises, is that the functionality of this product lives on despite name changes, rewrites, etc etc. That the market still has the (relatively) same problems almost ten years later makes me think that there is a disruptive or revolutionary solution waiting to happen.

No doubt you will recognize all of those companies and product names, most of which (except for Miria) I have been either directly or indirectly involved with.

Just some thoughts….

/rr

What Robb didn’t mention is that PricewaterhouseCoopers also took the Acenza code base and rewrote it in J2EE around the time that they were purchased by IBM, to create a case-based application framework targeted at insurance customers. Once part of IBM Global Services, it was further rewritten to make it “vendor independent”, meaning that the underlying content and process management could be either IBM or FileNet products, hence serving up the least common denominator of functionality and completely obviating proper use of the underlying product. I had the unhappy job of doing a review of an installation of this on behalf of the customer, and it’s unbelievable how little of the FileNet product capability was actually exposed or used.

Although I agree with Robb that the market need for systems like this remains, I’m not sure at all that Sequis/PeBA/Acenza/ManagedPay/Miria product remains a viable solution. I haven’t seen it in a while, but last time that I did look at it, it was too heavy and rigid, too old-school, and had the same problem as the IBM version that I mentioned above in that it completely hid the underlying capability of the BPM system below it: you might as well be using records in a database table for queue entries rather than a BPM system like FileNet.

I’ve talked about this problem of hiding the very nature and capabilities of a BPM product behind a rigidly-structured custom system in the past, and discussed it briefly on my Web 2.0 and BPM podcast, and I feel that it’s a significant contributor to the lack of acceptance of BPM in many organizations.

I believe that the new world of enterprise software is less customization and more customizability: give the users the raw product and let them do what they need with it.

2006 11 16 Sandy Kemsley BPM
business Comments (5)

Column 2