Have you noticed an increased presence of Apple products in public spaces and workspaces in the last few years? Turns out that 21% of information workers are using one or more Apple products for work. Almost half of enterprises (1000 employees or more) are issuing Macs to at least some employees – and they plan a 52% increase in the number of Macs they issue in 2012.

But that’s just Macs.  The numbers are actually more stark for iPads and iPhones. 11% of the workforce using iPhones, 9% using iPads, and 8% using Macs.  The trends are most highly supported by execs and managers – who use Apple products at twice the average rate (over 40%), and with the youngest workers, who also use Apple products at twice the rate.  Great trends for Apple products in the work place.  Think about that – you can reach the most influential members of business – 40% of them and growing – via Apple product-focus.

So the debate of which mobile OS to target first for your mobile app has been an interesting one.  Last year (actually late 2010) Fred Wilson came down on the side of Android first.  But while this might have been a good “by the numbers” recommendation, there are some subtleties that I would have argued made iOS still the place to start for most mobile apps:

• iOS device owners spend more money on apps (and content in general).
• iOS device owner demographics trend toward higher income brackets ( desirable demographics to sell to and advertise to )
• Apple’s iPhone and iPad had healthy halos around them that made them attractive “launch” vehicles for an app.  Wherever you look at ads for an institutions “mobile app” the premier imagery features a prominent iPhone.  Later on these institutions started including Android phones that look… well, they look just like iPhones anyway.

Finally, regardless of which OS you target first, or even if you’re cross-platform from the beginning, you might as well release on each platform one at a time – and get the press release mileage out of it.

Articles like the Forrester article, and of course Apple’s amazing Q4 performance, are reminders that the iOS platform is still the one with cachet, with the halo.

Related posts:

1. iPhone in the Enterprise
2. Six Barriers to BPM Adoption in the Enterprise
3. Fascinating TechCrunch Article on the New Enterprise Customer

Businesses all over the world need more programmers. Every company I know is hiring engineers (e.g. see this list of NY tech startups). Top programmers can make $100K+ right out of college. Yet there were only about 14,000 computer science (CS) majors last year. Meanwhile about 40,000 people got law degrees even though demand for lawyers has been shrinking. America is suffering from what economists call structural unemployment:  jobs are available but our labor force isn’t trained for those jobs.

Plentiful job opportunity is just one great reason for people to learn how to code (program).  Unfortunately, after the dot-com bust, the news media and many cynical people convinced many college students that software jobs were going overseas and never coming back.  It was a classic market-driven overreaction to a correction. In places where students have good data about market dynamics (e.g. Stanford) the number of computer science majors are up double-digit percentages each of the last 3-4 years.  Additionally, there’s been a big increase in software-related fields, not typically classified as Computer Science (like Symbolic Systems, electrical engineering, and certain types of engineering and product design).

Chris also points out that programming is a great foundation for starting a tech company.  Hard to argue with that.  If your goal is to start a company, knowing how to code will give you a much better chance of achieving that dream than just about any other skill.  Taking BP3 as an example-  a services company that you might not think requires programming skills to start: I have a computer science background, and Lance knows how to write code, though it isn’t part of his job description(!).  Knowing how to code and being able to do it were what allowed us to start BP3.  And those skills translate well to nearby fields like statistics, that require structured or algorithmic thinking.

Programming is good for your brain – to misquote (slightly) Steve Jobs, it is like a bicycle for the mind. You’ll be amazed at how well you can remember not only where specific lines of code are in your work, but by how long you can retain this knowledge, often even years later being able to trivially skim through your code to the right spot to fix a defect.

An even better point Chris brings up is this one:

  Programming is an important part of being “culturally literate.”

It is hard to underestimate this today.  I’m raising two children.  We’re exposing them to an immersion school that teaches them to speak fluent Spanish (as well as their native English).  But the school (and through some help from outside of school) we’re also teaching them Mandarin (and a little Cantonese).  If our children graduate from college fluent in English, Spanish, and Chinese – they’ll be able to do business almost anywhere in the world and converse with people from all over the world.  They’ll be much better off than their monolingual father, to face the challenges of the future.  But there are two more “languages” I will try my best to pass on to them:

• programming.  If our children learn how to write software, it will open up vast opportunities to them.  It isn’t about how many software languages they learn – even one will be a big head start heading into college.
• product design.  I don’t think it matters if it is physical design or software design, but I want to impart to the kids something of the language of design – the terminology, the flavor, the subtlety of how you talk about it.  I once compared “design language literacy” to the way chefs talk about food and cooking.  If you want to communicate with a chef (or a foodie) about food, you need to learn their language and vocabulary.  Similarly, for design, we need to learn the vocabulary and thought processes to communicate effectively – even if we don’t intend to become a designer.

These programming and product design skills are “meta” languages in a sense.  They transcend national borders and historical language affiliation.

The comment section of Chris Dixon’s blog puts the exclamation point on the value of this post to the general school of thought about coding.

So who should learn how to write code?  You should.  Your children should.

Related posts:

1. Alain Breillatt: You Can’t Innovate Like Apple. (But You Can Learn a LOT)
2. Don’t Learn the Wrong Lesson from Zappos
3. All #BPM Asks You to Do

Q. Other than Apple, which stores do you admire?
A. I admire lots of stores. Whole Foods is a great store. I just like their passion for food. It shows up in everything they do. It shows up in their packaging, their presentation and their employees. Starbucks. It truly has created a community. As I travel around the world, I just know that if I go to Starbucks I will have a great experience.

He’s right -Whole Foods is almost the sale of groceries art form.  Starbucks has an incredibly consistent experience.  These are two companies with a very strong process culture.  Ron focuses on the end result (the store experience), but it is deeper than that -  these companies also go deep into their supply chain and understand the origins of everything they’re selling (and then use their buying power to influence the supply chain).  When you motivate that process-focus with a passion for the product (organic food, or coffee), the results seem to be much better than passion without process, or process without passion.  It is almost impossible to tell whether process-focus led to a designed-in passion for food and coffee (to achieve the desired result) or whether passion for the food/coffee drove the focus on process in order to achieve the goal.  But the two together are a powerful tool for a big company to drive excellence.

Another part got my attention:

Q. What ideals have you embraced from Steve Jobs?

A. The importance of doing everything you do to your very best. And that the journey is the reward. If you do things well one at a time, you end up in a really good place. Don’t get ahead of yourself. Control the things you can.

The Apple approach to building a relationship with the customer starts with doing each of the little things really well.  Being a retailer, perhaps “each of the little things” doesn’t start with designing product, but for sure JC Penney has to be looking at design of stores, pricing, brand presentation, and customer service.  I have such a negative opinion of the JC Penney brand, that it is hard for me to imagine shopping there for any reason, for any product.  Literally, it is hard to conceive.

Yet reading this interview, I’m rooting for Ron.  He gets it.  If anyone can turn this around, he can.  But I’d be more inclined to shop there if the name were changed to “Ron Johnson’s” instead of JC Penney.

Getting introspective for a moment – is your organization getting better, one thing at a time?  Are you prioritizing to address the most important things first – but without forgetting about the little things?  Are you distracted by trying to do or change too many things at once? Are you marrying passion and process and following where that leads you in your business?

Related posts:

1. Who Shall Champion Process Management?

Appian reported “record growth in 2011″ the other day with some key statistics:

• 90 new-name customers
• 219% YoY license order increase for Appian BPM Software
• Appian Cloud represented 37% of their total license orders in 2011
• Highlighted new customers include several government agencies.

The press release goes on to describe Appian’s mobile BPM offering and several industry awards they won over the course of 2011.  Appian’s press release and blog certainly support the thesis that BPM still has room to grow.

But what I find interesting is the wordsmithing of what seem like otherwise healthy numbers:

• “90 new-name customers”  – how is a customer defined, then? As a department, subsidiary, purchasing group, or corporate entity?  (the use of new-name rather than just “new customers” makes one wonder what the caveat is).
• 219% year-over-year license growth sounds fantastic. But then they added another word – they didn’t actually say license dollars, they said “license order increase”.  An increase in orders could happen if you lowered the price to free, which isn’t nearly as interesting as a 219% year-over-year revenue increase in license dollars.
• I’m surprised the 37% cloud customers is as low as it is.

My beef isn’t that the numbers are good – they’re great numbers, but part of the value of a number is the context.  If Appian grew license revenue 219% why didn’t they just say so?  So if they didn’t just say so, then why did they feel the need to trump up the numbers by obscuring which metric they’re really reporting? It just isn’t necessary.

This isn’t a problem unique to small private companies though.  Just the other day Google reported some misleading vanity metrics about Google+.  The effect of using these misleading figures though was to undermine their credibility rather than enhance it.

This odd cherry picking of metrics isn’t new however, 6 months ago Appian reported “Sales orders for the Appian BPM Suite grew 158%” – again, orders, not revenue.

Of course, as a private firm, they don’t have to report anything, but if your business is growing it is hard to resist crowing about it at least a little! But I would encourage private companies reporting metrics to use plain words in what ever language you need to get through to your audience.  Finessing the terminology only undermines credibility.

No related posts.

Leveraging the success of that forum, SXSW has created the Startup Village this year.  The 4th floor of the Hilton will be converted to startup mecca.  I thought the “Lean Startup SXSW” track might have gone away in favor of this modified (and bigger billing) approach.  Apparently not so.  Today SXSW.com announces that they’re bringing Lean Startup SXSW back – and some of the chief instigators are involved again – Eric Ries, Dave McClure, Steve Blank, 500 Startups, et al:

The Lean Startup SXSW will take place on Saturday, March 10th from 9:30am – 6:00pm at the Downtown Hilton (across from the Convention Center), and the most up-to-date agenda can be found here.

So, more central location, same Saturday location in the schedule (good call).  The agenda already has enough speakers identified for me to plan my Saturday schedule.

Once again, good evidence of how SXSW adapts and co-opts good ideas from the outside.  Congrats to the organizers, I’m looking forward to it.

Related posts:

1. SXSW 2011 day 2. The Lean Startup Phenomenon
2. Lean Startup SXSW: Introduction
3. What BPM Can Learn from the Lean Startup

Forward

If you haven’t already done so I highly recommend you “tool up” for iOS (iPhone) or Android development. Speaking more on the Android platform with this point, but Android is based on Linux – meaning that the Android “smartphone” is a small, pocket-sized Linux computer. And, behind this tiny, touch-screen UI, we have an event-driven framework suited for wireless IO (communication) and  distributed client (end-user) services. This makes a good fit for BPM mobility as it applies focused, via platform constraints, user-to-process interaction.

So, in warming up to enterprise-scale BPM Mobility, I want to first walk through a few system architectures – this prior to diving into the details of Android computing. Goal being a build-up towards mobile device UI/IO requirements: from current state to future capabilities.

BPM Desktop Client: Web-portal, JSP Struts/Tiles

The portal has been with BPM practically from the very beginning and it exists today mostly in its original form as a JSP STRUTS/Tiles web-application.

Though somewhat dated in its technology, we must give credit as it has been and still is the BPM workhorse: delivering process execution, management, tracking, and reporting to our end-users. However, the portal leaves us wanting. Today’s users require a “rich web” experience – something beyond the reach of traditional architectures (form based: HTTP get/post). And, though the BPM Portal remains unsurpassed in features it simply cannot function as a mobile application.

For example, with the portal loaded into a 10″ tablet web-browser, there are just too many active features and UI elements for reasonable touch-screen interaction. I found myself constantly zooming in for navigation and then back out again to review effects and options. However, dashboard and charting elements do work well when broken out on their own as separate elements.

IBM-BPM v751 – Advanced: Dojo, Widgets, ReST API

Business Space enhances end-user experience with iWidgets and supporting dojo infrastructure.  Users now have rich web-applications without the downside of additional overhead costs required for custom in-house web development.

New BPM ReST APIs also opens the door to previously unattainable (within reason) web capabilities. Fully in-browser, JavaScript libraries now have direct access to process management. This leads to better performing web applications with reduced UI-interrupting side-effects caused by (legacy) HTML “post” and “get” operations.

Though very close, I’m not sure that we’re at mobile computing. I need to qualify this however because Business Space runs well on Tablets. The catch is that it requires screen real-estate, network bandwidth, and additional CPU. Honestly, these are negligible on today’s desktop/laptop computers. Even reasonably powerful tablets are fully capable of running Business Space over WIFI.

Business Space on a smart-phone though does spot-light a few problems.

Screen real estate is tight on smart-phones! Slow performance is also noticeable as the phone’s CPU just doesn’t seem to keep up and deliver on the same snappy performance previously experienced on both desktop and tablet execution.

Phones require their own native BPM application.

Mobile Applications for Mobile Process Management

Writing native applications feels counter-intuitive but it’s our only alternative given the constraints and limitations for mobile computing. Moving task services to Android (for example) significantly improves performance. Execution latency and UI “lag” disappear as timings drop into sub-second range.

With local execution, we’re looking at:

Reduced IO traffic via local application loading

• Discrete JSON server requests via ReST APIs.
• Native (java) run-time execution
• Local device data-storage. For example, Android includes a database usable for both caching and offline process execution.
• Local application services. These include: notification, document viewers, contacts, identity, and geo/mapping.

Conclusion

In working towards an architecture suitable for mobile BPM we take into account accompanying constraints and capabilities. We’re on a different path in that we’ve re-focused on building native phone applications.

Smartphones require discrete UIs, optimized coding techniques, and light-weight network IO. These challenges though are well worth the investment as mobility advances user-to-process interaction to near-personal proximity.

Acknowledging the tens of millions of new users purchasing smartphones, new expectations are set/re-set on almost a daily basis. Now’s the time to revisit our architecture and build-in these future capabilities.

Related posts:

1. Server Side Javascript
2. With Competitors Like These…
3. App(le) or Website?

Ben Horowitz’ post on Management Debt is a good read, but one thing that separates it from technical debt or process debt is that it seems to my own naivete that it almost never pays to pick up the management debt if you can avoid it, as described by Ben:

Like technical debt, management debt is incurred when you make an expedient, short-term management decision with an expensive, long-term consequence. Also like technical debt, the trade-off sometimes makes sense, but often does not. More importantly, if you incur the management debt without accounting for it, then you will eventually go management bankrupt.

He gives three tough examples – two in a box, overcompensation, and no feedback loop.

In the end, it comes down to leadership even more than management.  In each of his scenarios, good leadership cuts through the problems or is willing to pay the debt now rather than later.

No related posts.

The relationship between the Great Man theory and Entrepreneur is a bit of a quandary in the lean startup community.  On the one hand, many people in the startup business contend, paraphrased, that “entrepreneurs are born rather than made.”  But the lean startup seems to say that entrepreneurship can be taught, learned, rather than born inside you.

The “born with it” argument, to me, seems to be in alignment with the idea of building companies around Great Men (very Ayn Rand, in my humble opinion).  But that doesn’t make it correct.  In my experience, these things aren’t mutually exclusive.

I’d put it this way.  For some people, being a good entrepreneur *appears* to be innate.  We don’t know the person well enough to know how this talent developed, and what their experiences were – they’re a black box. To us, as if by magic, they are really good at entrepreneurship (and leading).  For others, it is more obviously a learned, thoughtfully acquired skill.

But I would argue that for literally everyone – born with it or not – if you decide to begin the journey of entrepreneurship, you can improve your chances if you learn.  And learning what Lean Startup has to offer is clearly a benefit- even if you choose not to apply lean startup methods to your efforts, at least you’re making an informed decision.  If you do apply lean startup, then of course the goal is that you also learn about your potential market and customers faster as well.

One thing clear to me is that lean startup (any startup) still requires leadership.  It’s hard to imagine any other possibility.  Critical decisions, pivots, and hires have to be made.  I just don’t see how you do that without good leadership.

And of course the other wrinkle is that not all leadership looks the same.  Contrast Tony Hsieh‘s style with Steve Jobs for example…

Related posts:

1. SXSW: Startup Village + Lean Startup SXSW = Value
2. What BPM Can Learn from the Lean Startup
3. Lean Startup SXSW: Introduction

Freelance Web designers and developers need a tool to collaborate with clients and to manage projects. They simply can’t afford to pay much for it but there are thousands of them. Basecamp pretty much plays perfectly to this market. It’s SaaS delivery model and freemium pricing makes it easy for users to get started quickly.

On the other side is the hard place: difficult integrations that must be completed before something like ACM or BPM can be successfully implemented…

If your target market is hospitals or insurance companies then just setting up the integrations and data migration is a massive upfront investment. The promised business agility depends on getting the set-up right and the compelling difference with other case management and BPM technologies is less.

And in this latter market, you find yourself up against established technology companies with robust BPM and separately, robust integration offerings (often well-integrated into a single suite).

This doesn’t shoot holes in the “methodology” side of the ACM pitch, but it sure points out a problem for the technology side of the house.  And there is some market evidence to support this view.  A few of the “ACM” vendors have run into the reefs – e.g. ActionBase (which I still think had the best articulation of a product that reflects ACM values, and yet was clearly not a BPMS).

Related posts:

1. Good Advice for a Tough Job Market
2. #IBMImpact: Damion Heredia and the Lombardi Product Roadmap
3. Is Process Everybody’s Product?

Since I mostly agree with his post I’ll just focus on a few of my nitpicks:

“We cannot conclude that if a management style is good for physical production that it is good for brain work as well.”  We also can’t conclude that if a management style is good for physical production it is NOT good for brain work as well.  Or vice versa.  That requires more data and analysis than has been discussed on the blog posts linked above.

Kraft goes on to say that we should use “the right type of tool for the right type of work.”  To my mind, BPM has always been about that.  In my experience it includes mind maps, BPMN, BPEL, interaction diagrams, Failure Mode Effects Analysis, and other tools of the trade.  Not to mention the data analysis, simulation, optimization side of things.   Most of what I hear about ACM sounds like tools of the trade people have been using in BPM projects for quite some time (which is why, to me, they aren’t that differentiated).

He also has a nifty graphic:

And he’s right, when he makes the point that the arguments about BPM and ACM often sound like mutual exclusivity – only one can be right.  But I think the argument between these advocates is more along these lines:

• ACM proponents: ACM is different and separable from BPM as a method, and (less consensus) a tool set. Corollary: the language used often implies it is just better and more important than BPM.
• BPM proponents:  ACM is fine. But it is clearly one of the tools in your BPM tool belt, rather than its own distinct and separate market (tooling), and methodology.

It is easy to mistake the first group’s arguments as saying BPM doesn’t matter, or that ACM is “the only thing”.  Clearly it does matter, and the staunchest proponents of ACM will also say and write that.  It is easy to read the second group’s arguments as saying “BPM is the only thing.”  But the argument is a bit more subtle, it is just that BPM is the umbrella in these advocates minds.  Maybe this is consistent with “BPM is the only thing” – but only because the BPM proponents likely have a more flexible notion of “what is BPM” than the ACM group.

Finally, we see this from Kraft:

And – what we need is a “process funnel” – as I tried to depict in the diagram. That is – a process that today is a completely unmanaged process (only by email) should become an ACM managed process. After a while – if it is a mature process – it can become a BPM managed process (for example by exporting it from an ACM system and importing it into a BPM system). After a while – if the process has further matured – it may become part of an ERP system.

I think Mr. Kraft is essentially correct, and most people would benefit from adopting some kind of funnel, just as he describes.  However, there are two small issues, which don’t detract from the main point he’s making – but the inconsistencies between these layers may not be obvious in a casual read, while they do affect how you approach the funnel:

1. ERP is a tooling (or software package), without a methodology.  In essence, the “methodology” is to standardize on a big software package.  That may also include giving up on differentiation, but it doesn’t have to.
2. ACM and BPM “methodologies” can both be accomplished with the same tool sets (software packages), even if you accept that the methodologies are distinct.
3. As a result, the transitions from one layer to the next have different degrees of friction with your IT and Business groups.

The funnel itself makes perfect sense.  In fact some of the customers and IT staff we’ve worked with prioritize their process work this way: by forcing new project ideas to go into the funnel starting with a fairly loose “ad-hoc” definition, and only with volume does it move into the more structured definitions more commonly considered “BPM”.

As usual, a strong contribution to the body of thought from Mr. Kraft, around ACM, BPM, and Taylorism.

No related posts.