Skip to content

{ Category Archives } Software design

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:

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 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.

2008 04 15 BPEL
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 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 BPM Comments (4)

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 Gartner BPM Comments (1)

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:

Business Analyist, User Experience, Front-End Architecture Practice MindMap

2008 01 29 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 ForresterITLeadership Comments (0)

Generalists and specialists

Specialist or generalist?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.

Wisdom of the crowdI 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 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 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:

  1. Fundamentals of process-based competition: understanding the competitive advantage of being a process-oriented company, and the business case for BPM.
  2. BPM and its value to the corporation: understanding what BPM is and how it differs from other management and technology approaches.
  3. 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.
  4. Getting hands-on BPM experience, with the help of mentors.
  5. Foundations for process practitioners: BPM as the capability for implementing and extending other management practices such as Six Sigma.
  6. Business process modelling and methods: learn about process-oriented architectures and development methods, and how they differ from traditional approaches.
  7. 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 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 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 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 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 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 Comments (0)

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 BPM
business Comments (5)

Extra chunky user experience

I was on the treadmill this morning with Malcolm Gladwell. Actually, he was on my iPod, and I was watching his talk from TED 2004, which was posted recently on the TEDTalks site (not sure if the timing is correct — although the website claims that this was recorded in February 2004, Gladwell mentions his book Blink, which wasn’t published until January 2005).

The topic of his talk was spaghetti sauce, and although the words “long tail” are never mentioned, the story that he tells is about, to some degree, the lengthening of the spaghetti sauce tail: how a single style of tomato sauce in the 70’s became the myriad styles that you find on your supermarket shelf today. This came about not by asking people what style of sauce that they wanted, since many had only ever been exposed to one type of sauce, but by offering them a huge variety of sauce styles and plotting the clusters of preferences, which turned out to be plain, spicy, and extra chunky. This in turn led to the explosion of styles of vinegars, mustards, coffees and many other food products, as the food industry learned a couple of valuable lessons:

Lesson #1: The way to find out what people want is not to ask them, since we can’t always explain what we want, especially if we are completely unaware of what alternatives are possible.

Lesson #2: Different styles of products are not better or worse, just different. This democratized what might previously have been considered a hierarchy of product styles.

Although Gladwell’s discussion about sauces convinced me that he has never had a “culturally authentic” Italian pasta sauce (my favourite is a pureed tomato and red pepper sauce that I learned to make at cooking school in Tuscany), he makes an excellent point about how the food industry was trying to treat us all the same, when we really wanted variability. As he summed up, “in embracing the diversity of human beings, we will find a sure way to true happiness.“

All that I could think of as I listened was that the lessons learned by the food industry could be well applied in software design (you knew that I’d be getting around to something relevant soon). One of the major causes of bad system implementations is to allow the users to design the system based on their current knowledge, through a misguided notion of what a JAD session is supposed to achieve. I’ve had this experience many times over when introducing new technology such as BPM into an enterprise: the business users have no idea what such technology can do, since they’ve never used it or probably even seen it before, so it’s foolish to expect that they are going to be able to tell you what they want the new system to do. Instead, they need to be presented with a vision of the future, or rather, several alternative visions, and be allowed to get their heads around what’s possible in the new world that includes that technology. I’m not suggesting that the technology should reshape the business process to fit its limitations, but that the business processes can radically change — for the better — with the advent of the technology, if they are allowed to do so.

The lesson about variability is a good one to take to heart as well. Many implementation “experts” have a set of templates that they seek to apply to every implementation in which they are involved; this maximizes their profitability since they don’t need to do much original design work for each project, but ultimately leads to unhappy users since it’s not so easy — or smart — to make one organization’s processes identical to another’s. The diversity of processes both within and across organizations is part of what makes an organization unique, and their ability to create that diversity easily while maintaining a common business goal is what makes for an agile company.

2006 09 28 BPM Comments (2)

Spectrum Radio on the FBI case file debacle

I’ve been a member of IEEE for over 20 years, and browse the periodicals that arrive at my door monthly, but have just become aware of the content that they offer to members and non-members on Spectrum Online. I’ve downloaded a number of the podcasts from Spectrum Radio and thoroughly enjoyed the two-parter about the enormously expensive and unsuccessful FBI case file project (I’d love to link to it directly, but they have a stupid Flash interface that doesn’t allow that, so you’ll just have to find it on the Radio page).

IEEE actually had to litigate to have the report about this project released under freedom of information laws, and the software experts in discussion on the podcast dissect the report and talk about what went wrong as well as lessons that can be learned for any large software project. Interesting that a company that has CMM level 5 certification can end up developing a $170M project with no proper requirements, no enterprise architecture, and a number of other things that seem like no-brainers for any large software project. Worth listening.

2006 08 20 EA Comments (0)

UI coolness

I’ve been watching the TED videos recently, and there’s some very interesting stuff (who knew Al Gore could be that funny?), but this one of Jeff Han displaying a new type of user interface is amazing. If you’re interested in data visualization, check out the Hans Rosling one as well.

2006 08 02 Comments (2)

Mashup Camp 2 Day 1: AJAX design patterns

Veneer was great, but short, so I’m on to Sarah Harmer’s You Were Here. I’m starting to slow down — it’s was a long day of travel yesterday and a long day of idea generation today — so may not finish up all my posts today.

The next session for me was AJAX design patterns, which was good although focussed a bit too much on security issues for what I was looking for. Some great stuff on UI and performance issues. The wiki page has all the technical details, includes references to further JSON reading, so I’ll just touch on some of the things that stuck in my mind during the session about AJAX UI design:

  • Action of the back button: was the last user activity a navigation or an action? Can it be “undone” by navigating back, or is it appropriate to return to a higher level/home page?
  • Action of the refresh button.
  • URL and permalinks: appended # arguments that don’t hit the server but are pure client processes to make the AJAX calls. Implications for search engines (agents can’t index pages directly and would require an alternative representation to be referenced by robots.txt, but doesn’t handle issues of relevancy through links), emailing permalink references.
  • Tradeoffs between user experience and technical issues.
  • Some actions need to be synchronous (e.g., “buy it” and other transactions), requires forcing synchronicity in AJAX or breaking out of AJAX for that part of the transaction.
2006 07 12 mashupcamp Comments (1)