Rambling/Rumbling

Java is as Java does

When Oracle launched its Fusion Apps effort back in 2005 (yes, that’s 6+ years ago), it seems to follow the right idea of starting from scratch when building a next generation solution. Who wouldn’t want to have a megasuite of solutions that promises to encapsulate all the functionality of every ERP suite that Oracle has built or acquired?

Sounds great on the surface. Now that’s 2012 (or 4710 - Happy Lunar New Year) and, after a few left turns, we still only see a small subset of capabilities that were promised in the middle of the last decade.

Wait, you say. You said that people are now able to quickly create websites and applications with today’s tools.

That’s right — I did say that.

However, I don’t count Java as part of “today’s tools.”

It’s probably my baggage as a person starting in client-server way back when, but the enterprise solutions that have been successful in the past have always been based on a platform that allows the developer to stay at a high level and focus on the process, not the technology. There’s a reason why SAP developed ABAP, PeopleSoft had PeopleTools and Salesforce.com has APEX. And if you want to go way back, COBOL was so huge when Big Blue was really the only choice you had.

(Sidenote: I worked for a small consulting firm that did a lot of PowerBuilder client-server apps. I always thought it was a mistake for Sybase/PowerSoft to keep its focus on tools when it should have built a suite of enterprise apps based on its technology)

Java is definitely better than C and C++ in that respect. However, Java is too low level to be an effective development environment for business solutions. From what I’ve seen, it just takes too much work to get stuff done. The only reason why it became so popular during Web 0.9 is because it was really the only “blessed” platform that seemingly could scale to large websites and handle enterprise requirements.

Times have changed, and better tools have emerged from the FOSS world that come much closer (but not entirely) to meet the needs for developing business solutions quickly. You see that today with Coupa and Ruby and Expensify with PHP.

Yes, what platform and development environment is only a small part of whether or not a company will be successful. However, if you want fast innovation, I would look to see what’s coming up rather than just rely on the incumbents in the space that rely on an ossified platform.

I used to work at a company where the head guy kept deriding the concept of two guys in a garage when it came to business solutions. Funny how a small company of 15 (including non-engineers) has been able to innovate much more quickly than a team of 20+ engineers at his company that supposedly has a unique platform that is at the core of its competitive advantage.

If what we see with Fusion Apps is what we can get after 6+ years of development effort, that to me is either an indictment of Oracle’s Fusion approach or lack of ability to manage innovation while balancing the needs of its legacy suites.

Which is worse?

Kill Your Platform… Again and Again…

Okay, now that I’ve said that having a platform can stifle innovation, let’s talk more about the baggage that comes with one.

Like any legacy code, platforms can become “brittle” (a phrase I heard quite a bit in my last two stops) over time, which requires constant tinkering and patching to keep things moving forward. Platforms become even more exposed if they were repurposed mid-life to do something different, like, move from client-server to web, or on-premise to SaaS.

I understand the desire to migrate IP as paradigms shift - I even believed in this approach for a long time. 

I don’t anymore. 

There are a few things that have changed my mind.

I have seen the issues with leveraging a legacy platform that wasn’t designed from the very beginning to address today’s needs. Performance and scalability always seem to be a problem, which makes sense. What used to be the golden standard, “enterprise scale” of up-to hundreds of thousands of users is no match for what I’ve been calling “cloud scale” of millions of users in thousands of organizations.

Furthermore, architecture choices that made sense in the past don’t always work in today’s social and collaborative world. For example, the 2000-era architectural assumption of strict isolation of companies — whether you call it a partition, VPD or realm, it’s all the same — makes it difficult to collaborate and aggregate information across companies (it also was a way for engineering to cheat thinking through how to configure multiple business units or orgs within the same enterprise, but that’s for another post).

Finally, with the ability for good engineers to rapidly code applications with today’s open source tools and capabilities (Ruby-on-Rails, PHP, etc.), I am still amazed how quickly new, innovative apps can be built from scratch. And these tools continue to improve and mature, which makes leveraging your old hairball even less sense.

An interesting recent example of not leveraging a platform is Google+. Remember when it was first released? The only thing that really integrated G+ with the rest of the Google platform was its use of Google Accounts for identity (and that navigation bar — not sure if I like it even now). Everything else was standalone - at least it looks that way from the outside. Google was even mocked for rolling out G+ without search (and now that it has, the FTC is interested…), but they were able to get their social network out quickly and add integrations along the way.

I’ve also heard from various contacts and acquaintances at Google that they essentially have a new platform every 2-4 years, which allows them to take advantage of advances in programming, tools and approaches. 

Of course the counter-example to Google is Oracle and their Fusion Apps long march. That’s for later.

Pricing as a means to an end, not an end

Every so often, you see discussion about how pricing and packaging is so “unfair” to consumers, and how it needs to be more transparent, etc. The most recent posting is here:

Unlimited data is dead, so let’s fight a smarter fight

It is a fairly well-written manifesto on how consumers need to fight for transparency in data pricing. In general I agree with this sentiment as a consumer. However, there is a basic problem with taking a narrow or silo’d view of how data is priced without looking at the overall revenue model of a company.

Everyone is focused on the structure of the pricing - the buckets, the tiers and so forth. However, what really matters is the overall revenue to the company and the margins associated with it. The pricing is no more than a “calculator” to dial up the price you pay every month.

Consequently, you can’t just focus on the data plan - you need to look at the entire picture, including SMS/voice/handset subsidy, and understand that if you want to pay less for one thing, you may end up having to pay more for something else. The cost to service a customer doesn’t necessarily change at the same rate as customer usage behavior. Therefore, the company needs to figure out how to either maintain (or raise) it’s revenue or reduce its costs, which is much harder.

You see this issue anywhere there is bundling. Cable is yet another example of this. People want choice - the want to pick only the channels they watch and skip the rest. From a consumer’s perspective it seems that all they would have to do is this:

• I pay for 50 channels for $75 bucks
• I only want 5
• Therefore I should only pay $7.50 for those five channels ($75/50 = $1.50 per channel)

Of course, it doesn’t work that way - there’s a lot of fixed cost associated with delivering content that somehow needs to be paid. There’s no way that Comcast or Time Warner could deliver just Travel Channel to you for $1.50.

(I’m not justifying cable’s pricing levels - I think it’s essentially monopoly pricing. I’m just using it to illustrate a point)

Let’s look at an offline example of this. One part of the completely awful Dodd-Frank (yes, Chris Dodd, who currently chairs the MPAA, drove this POS through) bill is the Durbin Amendment, which capped swipe fees for debit cards. Well, guess what - Financial Services companies were using that revenue to “subsidize” things like free checking accounts and no annual fee credit cards.  Maintenance fees for all types of accounts went up.

The bill was supposed to help the people it ended up hurting. Oops.

That’s why it’s important to look at the big picture when thinking about a company’s pricing. You need to step back and understand how the company and its shareholders expect to make money and how it impacts the other offerings it has.

In the end, the real way to change pricing is for a new entrant to be able to deliver these desirable individual services in a profitable way that competes with the incumbents, not mandating more and more rules that may have unintended market consequences.

Competitive Market > More Government Mandates

Platform as a Boat Anchor

As a veteran in the enterprise business applications space, it is interesting to see the long-held paradigms of software development being blown up with the commoditization of infrastructure and development tools. Many of the traditional views of optimizing R&D investment no longer hold true, yet I see technology organizations continuing to cling to creaking platforms and wondering why they can’t hire the best engineers out there.

On a conceptual level, platforms provide a way to scale up engineering resources, allowing engineering teams to leverage shared capabilities and resources for greater productivity. It should also make it easier to integrate processes and data. 

That’s all great - motherhood and apple pie kind of stuff.  

However, from what I’ve seen, it’s very hard to execute well. If not managed properly, a platform team becomes more of a shared service team where any little piece of functionality that could be shared, whether it is or isn’t, ends up being pushed to this team. Soon, the platform team is the largest R&D team in the whole company.

Okay, fine, so it’s the largest team — that in itself isn’t a problem. However, what can spiral out of control is the increasing reliance on this team to build out some missing part of the platform to enable new functionality. These dependencies kill the ability for product teams to innovate quickly. 

Why does that happen? 

Since platform isn’t always considered a “real product,” the proper packaging of platform capabilities is often the first to go when it is time to cut scope. No proper documentation resources allocated. Inadequate or missing APIs/services for other teams to leverage.

The end-result is that all innovation becomes dependent on engineers on the platform team to do their part to make things work.

Furthermore, platform always has the image of doing the “cool/difficult/innovative stuff,” and the best engineers often end up joining the platform team. Capabilities that are on the fringe of being platform migrate with those engineers to the platform team. The platform becomes one big hairball of functionality that only platform engineers can decipher.

Consequently, roadmaps become blocked on “required” platform work. The platform team becomes the arbiter of all development for the entire organization. Great for the owners of platform, but not so great for the rest of the company.

That’s why I always say “a platform that requires platform engineers is not a platform at all”

How can an R&D team ensure that development work doesn’t get sucked into the Platform Black Hole?

Platform as a product. Ensure that the proper packaging is done so that capabilities by platform can be consumed by other engineering teams efficiently. If these capabilities aren’t fit for customer consumption, why would it be ok to send it off to the engineer in the next cube?

This focus is especially important if your technology organization is, say, a cloud/SaaS provider that is reliant of internal services to get customers up-and-running. I don’t know how many times I debated with engineers who just said “let’s just let the services guys configure it.”

Strict definition of platform. Does it really need to be in platform? For example, given how much closer the app teams are to customers, it makes sense for those teams to own business-related objects and processes, even if they are shared among multiple solutions.

Of all the technology companies I’ve worked, I have to say that PeopleSoft had this part nailed. It wasn’t entirely perfect, but it was more clear here than anywhere else what belong to PeopleTools and what needed to be in my products in SCM/SRM.

Innovation at the edges. From my experience on both the app side and platform, a lot more innovation happens on the app side. Give the freedom (and architecture) to app teams to innovate and do interesting things without being shackled to the legacy way of doing things.

Again, I speak from my experience trying to build and innovate an employee-facing app in a back-office focused company. The engineering team ended up having to do a bit of hacking of the platform to incorporate better UI elements and create our own workflow engine. Yes, my counterpart in engineering made sure it was sanctioned by the platform team, but we did all the work.

In the end, having an effective platform is as much a management priority as it is a technology one. 

Hello World

Let me the 9,432,152,438th blog to start with a “Hello World” entry. In fact, it’s probably my third time if you count the corporate blogs that I’ve started….

Anyway, welcome to my little corner of the net. Nothing fancy here - just a bunch of (mostly) unfiltered opinions. Stay tuned!