I guess it has. And what a month it’s been. We’ve had the Services Leadership Summit, 2 operations reviews with Jonathan and staff for Software and Services respectively, a 2 day Johnny L offsite, multiple staff meetings, project reviews, demos, SunUp in Lisbon, new SPS deals, and a few customer briefings to boot. So I hope the lag in posting will be viewed through that lens…
I’ve got a bazillion things to write about, most of them important. Given that there are only a few minutes to write I’ll only hit one topic. (Guess this means you’ll see a few more entries as time emerges…)
Time to market. We’ve got to do things faster. How many of us have heard this? I know I have. Time to market is an outcome. What I want to talk about today is a mindset. The big elephant in the room is that we build monoliths. We deploy monoliths. We specify monoliths. We work hard (in truth, nearly kill ourselves) to produce these monoliths fast and with as high a quality as we can manage. It’s not a secret, and it’s largely why we can only release every six months.
We’re not lazy, stupid, or incompetent, but we never quite seem to hit the mark with what we’re doing. I’m hearing from a number of you in CNS in particular that you’re frustrated about being asked to do more faster. I’ve got breaking news, I’m frustrated too.
So, given the following context:
– Volume wins
– Our customer base is connected
– Content value leads to stickiness
We should consider the following hypothesis:
Maybe, just maybe, we shouldn’t specify, design, build, deploy, and operate monolithic software and services.
Time to market is an outcome. The method to get there is not to work harder or faster, it’s to work differently and smarter. It’s not to sacrifice quality, it’s to break the problem down and approach it a different way. I propose we use the context of connected volume desiring content as a lever to change our thinking.
For instance, shouldn’t we have a space where we deploy a new feature or function before production where a user/customer can kick the tires? Something like Google Labs?
Why should we have a PRD that specifies a perfect solution that all needs to be delivered on date X? Could we pull interesting features and functions in priority order and work on them as discreet components?
Shouldn’t we publish continuous realtime context relevant content?
I submit we’re doing what we’re doing because that’s how we’ve always done it. We’re trying to get our customers high quality software expressed as a service built on a train schedule like Solaris. Given that we’re connected, given that our customers are content hungry, given that we’re talking about volume (think 20M JRE downloads/month), we’re not working smarter. We’re working harder. There is a different way.
Here’s our challenge: We’ve got this project at Sun now called Red October (I’ll write more about this soon) that is really going to cause us to take a deep look at ourselves and deliver more to the company faster – let’s get to grips with the monolith problem. If you’ve got an idea about how we should attack and address this, I want to hear about it. Please leave a comment – I’ll respond. Meanwhile, think small, think simple, think flexible, think agile, more to the point, let’s all THINK our way forward.
