Category: design

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.

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.

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.

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.

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.

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.

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.

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.

Irreversibility breeds complexity

This is brilliant: an article by Martin Fowler in IEEE Software magazine from a few years back (via Julian On Software) really nails the issue of agility and complexity by referencing, oddly enough, a speech given by economist Enrico Zaninotto at the XP 2002 conference. Fowler says:

One aspect I found particularly interesting was his [Zaninotto’s] comment that irreversibility was one of the prime drivers of complexity. He saw agile methods, in manufacturing and software development, as a shift that seeks to contain complexity by reducing irreversibility — as opposed to tackling other complexity drivers. I think that one of an architect’s most important tasks is to remove architecture by finding ways to eliminate irreversibility in software designs.

Most of my customers are large financial and insurance organizations that still use very waterfall methods for development. The requirements and functional design take months to develop, and have concrete poured firmly over them as soon as they are complete. In other words, the irreversibility starts at the requirements stage, long before development even starts. Of course, since a technical design follows the requirements stage and in turn is solidified before development begins, the irreversibilty is built into this stage as well: any changes have to go back through (potentially) several layers of approval and redesign, which impacts project schedules and contracts.

Fowler referenced an example where a database administrator made it easy to change the database schema and migrate the data for a project; as Fowler put it, “the database schema is no longer architectural” since it could be changed on the fly to accommodate the requirements of the project, rather than being a pre-supposed part of the design.

When we used to do this, it was called “coding by the seat of our pants”; now it’s Agile!